From coffeys at openjdk.org  Fri Mar  1 15:19:06 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 1 Mar 2024 15:19:06 GMT
Subject: RFR: 8051959: Option to print thread information in
 java.security.debug output
Message-ID: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>

Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.

examples:
format without patch :


properties: Initial security property: package.definition=sun.misc.,sun.reflect.
properties: Initial security property: krb5.kdc.bad.policy=tryLast 
keystore: Creating a new keystore in PKCS12 format


format with thread info included:


properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format


format with thread info and timestamp:


properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast


It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use

current proposal is to keep the thread and timestamp information off (make it opt in)

The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.

e.g 

`-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info

-Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.

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

Commit messages:
 - static dateTimeFormatInitialized
 - Merge branch 'master' into 8051959-tracing
 - Holder class idiom
 - Merge branch 'master' into 8051959-tracing
 - 8051959

Changes: https://git.openjdk.org/jdk/pull/18084/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8051959
  Stats: 234 lines in 2 files changed: 228 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18084/head:pull/18084

PR: https://git.openjdk.org/jdk/pull/18084


From alanb at openjdk.org  Fri Mar  1 15:28:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Mar 2024 15:28:52 GMT
Subject: RFR: 8051959: Option to print thread information in
 java.security.debug output
In-Reply-To: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
Message-ID: <_1TPuT-kRBpCXxgDfqUL376R44eoTEZhwQJjeawdu6k=.e11738ee-f115-4bd8-9d2c-e049d0f11e7f@github.com>

On Fri, 1 Mar 2024 15:13:49 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
> 
> examples:
> format without patch :
> 
> 
> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info included:
> 
> 
> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info and timestamp:
> 
> 
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
> 
> 
> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
> 
> current proposal is to keep the thread and timestamp information off (make it opt in)
> 
> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
> 
> e.g 
> 
> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
> 
> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.

src/java.base/share/classes/sun/security/util/Debug.java line 294:

> 292:         if (printThreadDetails) {
> 293:             retString = toHexString(Thread.currentThread().threadId()) + "|" +
> 294:                     Thread.currentThread().getName() + "|" + formatCaller();

The thread ID is in decimal in the default string representation of thread, also other diagnostic features such as the new thread dump. So I think you want to change this to "#" + Thread.currentThread().threadId().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1509156817


From dfuchs at openjdk.org  Fri Mar  1 17:58:51 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 1 Mar 2024 17:58:51 GMT
Subject: RFR: 8312444: Unused parameter 'defval' in
 SocketPermission.initEphemeralPorts could be removed
In-Reply-To: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
Message-ID: <pxzf4OMjXq5sinopM4QUNUyTERC0GHJcTTpue3mjYiw=.a99e2284-3af2-4cf8-89a0-a9f4b4373d08@github.com>

On Fri, 1 Mar 2024 17:35:35 GMT, Korov <duke at openjdk.org> wrote:

> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
> 
> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
> 
> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.

The proposed cleanup looks OK and reduces potential confusion - since the removed parameters were actually not used. However I wonder if we want to change this class at this time. I added the label `security` to get some input from security libs maintainers.

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1973636828


From duke at openjdk.org  Fri Mar  1 18:05:51 2024
From: duke at openjdk.org (Korov)
Date: Fri, 1 Mar 2024 18:05:51 GMT
Subject: RFR: 8312444: Unused parameter 'defval' in
 SocketPermission.initEphemeralPorts could be removed
In-Reply-To: <pxzf4OMjXq5sinopM4QUNUyTERC0GHJcTTpue3mjYiw=.a99e2284-3af2-4cf8-89a0-a9f4b4373d08@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <pxzf4OMjXq5sinopM4QUNUyTERC0GHJcTTpue3mjYiw=.a99e2284-3af2-4cf8-89a0-a9f4b4373d08@github.com>
Message-ID: <23gPxOWdugs_PPnhQUhFswp5XB9GmP0iFwOObqY3kKQ=.e6754efc-860e-4b0d-b254-dfe6e3e493f1@github.com>

On Fri, 1 Mar 2024 17:56:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The proposed cleanup looks OK and reduces potential confusion - since the removed parameters were actually not used. However I wonder if we want to change this class at this time. I added the label `security` to get some input from security libs maintainers.

Thanks @dfuch , If some modifications need to be deleted, I will delete them immediately.

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1973651725


From kevin.driver at oracle.com  Fri Mar  1 21:08:55 2024
From: kevin.driver at oracle.com (Kevin Driver)
Date: Fri, 1 Mar 2024 21:08:55 +0000
Subject: New Draft of the KDF JEP for the Java Platform
In-Reply-To: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
References: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
Message-ID: <BD91A6D7-EEFC-44ED-A713-DA9AAEBC9413@oracle.com>

Hi All,

As discussed a few months ago [1], we are working on providing a new API for KDF (Key Derivation Functions). There will be a KDF class for users, a KDFSpi class for security providers, and several other parameter classes. We plan to add support for HKDF (RFC-5869).

For more details, see the updated draft JEP at: https://openjdk.org/jeps/8189808

As before, we look forward to your feedback on the proposal.

[1] https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html

Thanks,

[image001.png]
Kevin Driver
Java Security Libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240301/201dcca7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6771 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240301/201dcca7/image001.png>

From gli at openjdk.org  Sat Mar  2 08:57:56 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 2 Mar 2024 08:57:56 GMT
Subject: RFR: 8312444: Unused parameter 'defval' in
 SocketPermission.initEphemeralPorts could be removed
In-Reply-To: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
Message-ID: <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>

On Fri, 1 Mar 2024 17:35:35 GMT, Korov <duke at openjdk.org> wrote:

> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
> 
> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
> 
> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.

The patch looks good. But the title of this issue may need to be adjusted, because you not only change the `SocketPermission.initEphemeralPorts` but also change other code. Or you can separate the unrelated code to another issue.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18086#pullrequestreview-1912616977


From duke at openjdk.org  Sat Mar  2 09:44:54 2024
From: duke at openjdk.org (Korov)
Date: Sat, 2 Mar 2024 09:44:54 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission
In-Reply-To: <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>
Message-ID: <-ZZjmFejati594dC5HjCf-NMDLKhGrthyqONIr6wC1A=.675e65c4-861b-4d95-9dd3-6916db3e129b@github.com>

On Sat, 2 Mar 2024 08:54:44 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> The patch looks good. But the title of this issue may need to be adjusted, because you not only change the `SocketPermission.initEphemeralPorts` but also change other code. Or you can separate the unrelated code to another issue.

Hello @lgxbslgx , the title has been changed, Can you check if it's suitable?

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1974748025


From gli at openjdk.org  Sat Mar  2 11:37:51 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 2 Mar 2024 11:37:51 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission
In-Reply-To: <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>
Message-ID: <s3O_-Igct9FVE_H8czPXtGJpT7HcWkV4Zq_32cG1Zls=.4ee3a5de-31a2-4c05-90ce-6bc04f4076ee@github.com>

On Sat, 2 Mar 2024 08:54:44 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
>> 
>> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
>> 
>> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.
>
> The patch looks good. But the title of this issue may need to be adjusted, because you not only change the `SocketPermission.initEphemeralPorts` but also change other code. Or you can separate the unrelated code to another issue.

> Hello @lgxbslgx , the title has been changed, Can you check if it's suitable?

Seems good. If nobody disagrees such mixed patch, I will help you change the title and content of the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1974771937


From duke at openjdk.org  Sat Mar  2 11:45:51 2024
From: duke at openjdk.org (Korov)
Date: Sat, 2 Mar 2024 11:45:51 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission
In-Reply-To: <s3O_-Igct9FVE_H8czPXtGJpT7HcWkV4Zq_32cG1Zls=.4ee3a5de-31a2-4c05-90ce-6bc04f4076ee@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>
 <s3O_-Igct9FVE_H8czPXtGJpT7HcWkV4Zq_32cG1Zls=.4ee3a5de-31a2-4c05-90ce-6bc04f4076ee@github.com>
Message-ID: <V_uDmQqbi0jB73dnwWo3KnfxRdRvl-ZqJ2PHacJ7YpY=.35d76a3e-2d30-4562-86df-d2a95ce5a00b@github.com>

On Sat, 2 Mar 2024 11:35:29 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> > Hello @lgxbslgx , the title has been changed, Can you check if it's suitable?
> 
> Seems good. If nobody disagrees such mixed patch, I will help you change the title and content of the issue.

Thanks so much.

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1974773534


From aturbanov at openjdk.org  Sat Mar  2 13:05:51 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 2 Mar 2024 13:05:51 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission
In-Reply-To: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
Message-ID: <WOS9gOG5oJgrUZGyaeGoKirdaJd-wtHjIhlsGGDRYEA=.bb944e64-27fc-418b-972b-7737a5f1964d@github.com>

On Fri, 1 Mar 2024 17:35:35 GMT, Korov <duke at openjdk.org> wrote:

> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
> 
> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
> 
> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.

Let's align declaration of `java.net.SocketPermission#NONE` field

Can we drop `java.net.SocketPermission#defaultDeny` field? It seems it's always has `false` value (`setDeny` is never called)

src/java.base/share/classes/java/net/SocketPermission.java line 707:

> 705:     }
> 706: 
> 707:     private boolean authorized(String cname, byte[] addr) {

now `cname` parameter is unused in this method

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1974791236
PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1974791645
PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1509962901


From duke at openjdk.org  Sat Mar  2 13:51:04 2024
From: duke at openjdk.org (Korov)
Date: Sat, 2 Mar 2024 13:51:04 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v2]
In-Reply-To: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
Message-ID: <qZT8DM9L1qa1D5rjytsaM_DHvcwDxBF6nASsf4tP5-s=.33bcdec4-3247-425c-af95-3242e52315ed@github.com>

> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
> 
> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
> 
> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.

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

  Modiy the code accordingto the review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18086/files
  - new: https://git.openjdk.org/jdk/pull/18086/files/a07280d4..9ebd6e12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18086&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18086&range=00-01

  Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18086.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18086/head:pull/18086

PR: https://git.openjdk.org/jdk/pull/18086


From duke at openjdk.org  Sat Mar  2 13:51:04 2024
From: duke at openjdk.org (Korov)
Date: Sat, 2 Mar 2024 13:51:04 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v2]
In-Reply-To: <WOS9gOG5oJgrUZGyaeGoKirdaJd-wtHjIhlsGGDRYEA=.bb944e64-27fc-418b-972b-7737a5f1964d@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <WOS9gOG5oJgrUZGyaeGoKirdaJd-wtHjIhlsGGDRYEA=.bb944e64-27fc-418b-972b-7737a5f1964d@github.com>
Message-ID: <zTZvtOhXb55eM-dX0AOuj9IEnyT-qx4TI-7M5r-VZQE=.a4087b81-22f7-41d1-b66d-19c0fec80888@github.com>

On Sat, 2 Mar 2024 13:00:21 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Korov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modiy the code accordingto the review
>
> src/java.base/share/classes/java/net/SocketPermission.java line 707:
> 
>> 705:     }
>> 706: 
>> 707:     private boolean authorized(String cname, byte[] addr) {
> 
> now `cname` parameter is unused in this method

`cname` has been deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1509968951


From duke at openjdk.org  Sat Mar  2 13:54:42 2024
From: duke at openjdk.org (Korov)
Date: Sat, 2 Mar 2024 13:54:42 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission
In-Reply-To: <WOS9gOG5oJgrUZGyaeGoKirdaJd-wtHjIhlsGGDRYEA=.bb944e64-27fc-418b-972b-7737a5f1964d@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <WOS9gOG5oJgrUZGyaeGoKirdaJd-wtHjIhlsGGDRYEA=.bb944e64-27fc-418b-972b-7737a5f1964d@github.com>
Message-ID: <OKxTKvwr6c93bPmgqXuu5jB5nI6Fn7BsJfeEiq9qiOU=.181d9432-42b9-4de9-9c58-893e71cac8f1@github.com>

On Sat, 2 Mar 2024 13:02:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
>> 
>> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
>> 
>> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.
>
> Can we drop `java.net.SocketPermission#defaultDeny` field? It seems it's always has `false` value (`setDeny` is never called)

Hello @turbanoff , The code has been modified based on the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1974802160


From jjiang at openjdk.org  Mon Mar  4 04:03:08 2024
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 4 Mar 2024 04:03:08 GMT
Subject: RFR: 8327182: Move serverAlias into the loop
Message-ID: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>

In method `X509Authentication::createServerPossession`, it looks unnecessary to define variable `serverAlias` out of the for-loop.
It may be better to move `serverAlias` into that loop to narrow down the scope.

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

Commit messages:
 - 8327182: Move serverAlias into the loop

Changes: https://git.openjdk.org/jdk/pull/18100/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18100&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327182
  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18100/head:pull/18100

PR: https://git.openjdk.org/jdk/pull/18100


From gli at openjdk.org  Mon Mar  4 05:06:52 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 4 Mar 2024 05:06:52 GMT
Subject: RFR: 8327182: Move serverAlias into the loop
In-Reply-To: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
Message-ID: <i0si2ncO1dvXq8XuCRIak2DO8kk5fjJdMR1-FdHatC4=.57a19856-5482-47bc-94f3-f89c5ae75d80@github.com>

On Mon, 4 Mar 2024 03:58:18 GMT, John Jiang <jjiang at openjdk.org> wrote:

> In method `X509Authentication::createServerPossession`, it looks unnecessary to define variable `serverAlias` out of the for-loop.
> It may be better to move `serverAlias` into that loop to narrow down the scope.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 274:

> 272:         X509ExtendedKeyManager km = shc.sslContext.getX509KeyManager();
> 273:         for (String keyType : keyTypes) {
> 274:             String serverAlias = null;

It seems not a simple cleanup. If you move the `serverAlias` definition into the loop, it means everytime entering into loop, the `serverAlias` will be `null`. But the previous code can keep the `serverAlias` value to the next iteration. So the meaning of the code has been changed. I don't know which meanings is right because I don't have a deep understanding of SSL now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18100#discussion_r1510591899


From jjiang at openjdk.org  Mon Mar  4 06:59:52 2024
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 4 Mar 2024 06:59:52 GMT
Subject: RFR: 8327182: Move serverAlias into the loop
In-Reply-To: <i0si2ncO1dvXq8XuCRIak2DO8kk5fjJdMR1-FdHatC4=.57a19856-5482-47bc-94f3-f89c5ae75d80@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
 <i0si2ncO1dvXq8XuCRIak2DO8kk5fjJdMR1-FdHatC4=.57a19856-5482-47bc-94f3-f89c5ae75d80@github.com>
Message-ID: <43qXuMeOtjp7nLsbSjKK92lRF7jQ5GRPP59px3eQkBI=.38cbf0a5-5287-47ae-b22f-c299c4515931@github.com>

On Mon, 4 Mar 2024 05:04:13 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> In method `X509Authentication::createServerPossession`, it looks unnecessary to define variable `serverAlias` out of the for-loop.
>> It may be better to move `serverAlias` into that loop to narrow down the scope.
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 274:
> 
>> 272:         X509ExtendedKeyManager km = shc.sslContext.getX509KeyManager();
>> 273:         for (String keyType : keyTypes) {
>> 274:             String serverAlias = null;
> 
> It seems not a simple cleanup. If you move the `serverAlias` definition into the loop, it means everytime entering into loop, the `serverAlias` will be `null`. But the previous code can keep the `serverAlias` value to the next iteration. So the meaning of the code has been changed. I don't know which meanings is right because I don't have a deep understanding of SSL now.

With my understanding, in each iteration, firstly choose an alias from key manager with a key type, and then try to get the keys and certificates associated with this alias.
If an alias or its associated keys and certificates have something wrong, it should try other aliases associated with the key types in the remaining iterations.

If an alias can be used by the subsequent iterations, that looks a bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18100#discussion_r1510666303


From gli at openjdk.org  Mon Mar  4 08:28:52 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 4 Mar 2024 08:28:52 GMT
Subject: RFR: 8327182: Move serverAlias into the loop
In-Reply-To: <43qXuMeOtjp7nLsbSjKK92lRF7jQ5GRPP59px3eQkBI=.38cbf0a5-5287-47ae-b22f-c299c4515931@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
 <i0si2ncO1dvXq8XuCRIak2DO8kk5fjJdMR1-FdHatC4=.57a19856-5482-47bc-94f3-f89c5ae75d80@github.com>
 <43qXuMeOtjp7nLsbSjKK92lRF7jQ5GRPP59px3eQkBI=.38cbf0a5-5287-47ae-b22f-c299c4515931@github.com>
Message-ID: <ECAWIAPmt1px0MXUBZ77J_z4k4BsaeZKEp9MLwWYEUI=.2c16ab27-4353-406f-aec4-b5b6984ab3ee@github.com>

On Mon, 4 Mar 2024 06:57:23 GMT, John Jiang <jjiang at openjdk.org> wrote:

> If an alias can be used by the subsequent iterations, that looks a bug.

Looks like a bug. So your patch is a bug fix instead of simple cleanup. Should we change the title of this issue or/and provide a test case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18100#discussion_r1510754496


From jjiang at openjdk.org  Mon Mar  4 08:45:52 2024
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 4 Mar 2024 08:45:52 GMT
Subject: RFR: 8327182: Move serverAlias into the loop
In-Reply-To: <ECAWIAPmt1px0MXUBZ77J_z4k4BsaeZKEp9MLwWYEUI=.2c16ab27-4353-406f-aec4-b5b6984ab3ee@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
 <i0si2ncO1dvXq8XuCRIak2DO8kk5fjJdMR1-FdHatC4=.57a19856-5482-47bc-94f3-f89c5ae75d80@github.com>
 <43qXuMeOtjp7nLsbSjKK92lRF7jQ5GRPP59px3eQkBI=.38cbf0a5-5287-47ae-b22f-c299c4515931@github.com>
 <ECAWIAPmt1px0MXUBZ77J_z4k4BsaeZKEp9MLwWYEUI=.2c16ab27-4353-406f-aec4-b5b6984ab3ee@github.com>
Message-ID: <Zji77OofMGtlU1eS8a3_9RC-unMNXcX80I8cfFQI6P8=.b91b0cad-733d-4c49-8ef9-8280b2eaaa6c@github.com>

On Mon, 4 Mar 2024 08:26:28 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> With my understanding, in each iteration, firstly choose an alias from key manager with a key type, and then try to get the keys and certificates associated with this alias.
>> If an alias or its associated keys and certificates have something wrong, it should try other aliases associated with the key types in the remaining iterations.
>> 
>> If an alias can be used by the subsequent iterations, that looks a bug.
>
>> If an alias can be used by the subsequent iterations, that looks a bug.
> 
> Looks like a bug. So your patch is a bug fix instead of simple cleanup. Should we change the title of this issue or/and provide a test case?

At the beginning of a iteration, `km.chooseServerAlias` or `km.chooseEngineServerAlias` tries to find an alias. Then, `serverAlias` should be `null` or an existing alias in the key manager.
The `serverAlias` assigned by the last iteration should not used by the current iteration.
So, I don't see a bug at the moment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18100#discussion_r1510776791


From gli at openjdk.org  Mon Mar  4 09:17:52 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 4 Mar 2024 09:17:52 GMT
Subject: RFR: 8327182: Move serverAlias into the loop
In-Reply-To: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
Message-ID: <JVvGvrQW4TCMewfHAc2i7EGbxxFjtjmzSiQTkdsJnCg=.71deb0ff-bf87-498c-8bf9-bc33d6379526@github.com>

On Mon, 4 Mar 2024 03:58:18 GMT, John Jiang <jjiang at openjdk.org> wrote:

> In method `X509Authentication::createServerPossession`, it looks unnecessary to define variable `serverAlias` out of the for-loop.
> It may be better to move `serverAlias` into that loop to narrow down the scope.

Marked as reviewed by gli (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18100#pullrequestreview-1913794194


From gli at openjdk.org  Mon Mar  4 09:17:52 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 4 Mar 2024 09:17:52 GMT
Subject: RFR: 8327182: Move serverAlias into the loop
In-Reply-To: <Zji77OofMGtlU1eS8a3_9RC-unMNXcX80I8cfFQI6P8=.b91b0cad-733d-4c49-8ef9-8280b2eaaa6c@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
 <i0si2ncO1dvXq8XuCRIak2DO8kk5fjJdMR1-FdHatC4=.57a19856-5482-47bc-94f3-f89c5ae75d80@github.com>
 <43qXuMeOtjp7nLsbSjKK92lRF7jQ5GRPP59px3eQkBI=.38cbf0a5-5287-47ae-b22f-c299c4515931@github.com>
 <ECAWIAPmt1px0MXUBZ77J_z4k4BsaeZKEp9MLwWYEUI=.2c16ab27-4353-406f-aec4-b5b6984ab3ee@github.com>
 <Zji77OofMGtlU1eS8a3_9RC-unMNXcX80I8cfFQI6P8=.b91b0cad-733d-4c49-8ef9-8280b2eaaa6c@github.com>
Message-ID: <9NCkcb2YnqfnEc757_Ie2IQH2UynuKmWzcFnJ_dAMDM=.f8cdd7c9-5876-419f-ac59-92a140678f7f@github.com>

On Mon, 4 Mar 2024 08:43:33 GMT, John Jiang <jjiang at openjdk.org> wrote:

>>> If an alias can be used by the subsequent iterations, that looks a bug.
>> 
>> Looks like a bug. So your patch is a bug fix instead of simple cleanup. Should we change the title of this issue or/and provide a test case?
>
> At the beginning of a iteration, `km.chooseServerAlias` or `km.chooseEngineServerAlias` tries to find an alias. Then, `serverAlias` should be `null` or an existing alias in the key manager.
> The `serverAlias` assigned by the last iteration should not used by the current iteration.
> So, I don't see a bug at the moment.

I know what I missed now. The interface `SSLTransport` only has two implementations `SSLSocketImpl` and `SSLEngineImpl`, so the `serverAlias` is always set at the beginning of the loop. Thanks for your kindly explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18100#discussion_r1510830428


From eirbjo at openjdk.org  Mon Mar  4 10:05:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 4 Mar 2024 10:05:03 GMT
Subject: RFR: 8327208: Remove unused method java.util.jar.Manifest.make72Safe
Message-ID: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>

Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.

This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.

Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.

This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

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

Commit messages:
 - Update copyright years
 - Remove the internal, unused method Manifest.make72Safe. Update tests to not reference this legacy method.

Changes: https://git.openjdk.org/jdk/pull/18104/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327208
  Stats: 33 lines in 3 files changed: 2 ins; 21 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18104/head:pull/18104

PR: https://git.openjdk.org/jdk/pull/18104


From jlahoda at openjdk.org  Mon Mar  4 13:56:12 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Mar 2024 13:56:12 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled
Message-ID: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>

Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.

This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

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

Commit messages:
 - Explicitly listing the modules that should get native access.
 - Native access modules-1

Changes: https://git.openjdk.org/jdk/pull/18106/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18106&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327218
  Stats: 120 lines in 9 files changed: 103 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18106.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18106/head:pull/18106

PR: https://git.openjdk.org/jdk/pull/18106


From mcimadamore at openjdk.org  Mon Mar  4 14:14:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 4 Mar 2024 14:14:43 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <qFF0WMBrjUKykQUct5LCzfkye5jUQbTGInkefWzsWQw=.07a21123-f748-4000-8f17-da2a860b6702@github.com>

On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

Looks good.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 273:

> 271: 
> 272:     /**
> 273:      * Updates module named name in layer layer to allow access to restricted methods.

Suggestion:

     * Updates module named {@code name} in layer {@code layer} to allow access to restricted methods.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 806:

> 804:     /**
> 805:      * Process the --enable-native-access option to grant access to restricted methods to selected modules.
> 806:      * Also add Enable native access from JDK modules.

I don't think this extra comment is needed.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1914419463
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1511226929
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1511223692


From erikj at openjdk.org  Mon Mar  4 14:20:52 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 4 Mar 2024 14:20:52 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <jXtp1UbhG1JNxBdlENDq_XdxvRooGN0c4i5pADXz6a4=.4921f077-c5be-4898-867b-8e9129dd6b68@github.com>

On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1914434715


From mullan at openjdk.org  Mon Mar  4 15:18:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:18:59 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:

> 67:         }
> 68:         private void setPrincipal() {
> 69:             Subject subject = Subject.current();

Why change this to `Subject.current()` if you are requiring the SM to be allowed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511332276


From mullan at openjdk.org  Mon Mar  4 15:30:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:30:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:

> 307:         final Subject s;
> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
> 309:             s = Subject.current();

We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511351340


From mullan at openjdk.org  Mon Mar  4 15:35:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:35:48 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <2ScdK8KcKlERkLJo7THfkI6UloVwIfWKn-sWF7ZzJsg=.5634f7e1-a6c2-4b19-9829-2fb1129a65c9@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

test/jdk/javax/security/auth/Subject/doAs/NestedActions.java line 283:

> 281:     static void readFile(String filename) {
> 282:         System.out.println("ReadFromFileAction: try to read " + filename);
> 283:         Subject subject = Subject.current();

Couldn't we have just left these calling `Subject.getSubject` for now since these tests run with an SM enabled?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511358336


From fferrari at openjdk.org  Mon Mar  4 15:50:00 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 4 Mar 2024 15:50:00 GMT
Subject: RFR: 8319332: Security properties files inclusion [v5]
In-Reply-To: <QhHCuxOWJ7sZSTGiamjVRv1CBE3IESgc049oZ9Kt-uc=.aa4a1f16-0654-4eb3-83be-9fdeb72fc68f@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <QhHCuxOWJ7sZSTGiamjVRv1CBE3IESgc049oZ9Kt-uc=.aa4a1f16-0654-4eb3-83be-9fdeb72fc68f@github.com>
Message-ID: <l3_lkCTyWmVhMul5ZRiN8j-QPn0FwVlNZsJSlJEFLgY=.248f698b-1363-4470-9af7-c10f143bae79@github.com>

On Mon, 8 Jan 2024 18:59:54 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> The implementation of this proposal is based on the requirements, specification and design choices described in the [JDK-8319332] ticket and its respective CSR [JDK-8319333]. What follows are implementation notes organized per functional component, with the purpose of assisting to navigate the code changes in this pull-request.
>> 
>> ## Security properties loading (overview)
>> 
>> A new static class named `SecPropLoader` (nested within `java.security.Security`) is introduced to handle the loading of all security properties. Its method `loadAll` is the first one to be called, at `java.security.Security` static class initialization. The master security properties file is then loaded by `loadMaster`. When additional security properties files are allowed (the security property `security.overridePropertiesFile` is set to `true`) and the `java.security.properties` system property is passed, the method `loadExtra` handles the extra load.
>> 
>> The master properties file is loaded in `OVERRIDE` mode, meaning that the map of properties is originally empty. Any failure occurred while loading these properties is considered fatal. The extra properties file (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. Any failure in this case is ignored. This behavior maintains compatibility with the previous implementation.
>> 
>> While the `java.security.properties` system property is documented to accept an URL type of value, filesystem path values are supported in the same way that they were prior to this enhancement. Values are then interpreted as paths and, only if that fails, are considered URLs. In the latter case, there is one more attempt after opening the stream to check if there is a local file path underneath (e.g. the URL has the form of `file:///path/to/a/local/file`). The reason for preferring paths over URLs is to support relative path file inclusion in properties files.
>> 
>> ## Loading security properties from paths (`loadFromPath` method)
>> 
>> When loading a properties file from a path, the normalized file location is stored in the static field `currentPath`. This value is the current base to resolve any relative path encountered while handling an _include_ definition. Normalized paths are also saved in the `activePaths` set to detect recursive cycles. As we move down or up in the _includes_ stack, `currentPath` and `activePaths` values are updated.
>> 
>> ## Loading security properties from URLs (`loadFromUrl` method)
>> 
>> The extra properti...
>
> Francisco Ferrari Bihurriet 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 seven additional commits since the last revision:
> 
>  - Merge 'openjdk/master' into JDK-8319332
>  - 8319332: Fix corner-case regression with bash pipe
>    
>    Extra properties files provided through bash pipes used to work before
>    this enhancement, restore their behaviour.
>    
>    Also take advantage to use Files::isRegularFile, Files::isDirectory and
>    Files::exists APIs instead of converting from Path to File.
>    
>    Linux reproducers (sub-shell, stdin, and combination of both):
>    
>    java -XshowSettings:security:properties                      \
>         -Djava.security.properties==<(echo name=value)          \
>         -Djava.security.debug=properties -version
>    
>    echo name=value | java -XshowSettings:security:properties    \
>         -Djava.security.properties==/dev/stdin                  \
>         -Djava.security.debug=properties -version
>    
>    echo name=value | java -XshowSettings:security:properties    \
>         -Djava.security.properties==<(echo include /dev/stdin)  \
>         -Djava.security.debug=properties -version
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>  - 8319332: Remove wildcard imports, adjust test case
>    
>    Test case adjustments: add missing check in PropsFile::assertApplied(),
>    and fix typo in FilesManager::handleRequest() method name.
>    
>    Also, add clarifying comments to Executor::assertSuccess() explaining
>    how we use the special properties to make the assertion. Make 'lastFile'
>    assignation latter, so it's separated from the first group of asserts.
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>  - 8319332: use Path::of(URI) to deal with file URLs
>    
>    Instead of the previously introduced FileURLConnection::getFile(), use
>    Path::of(URI), leaving some file URL corner-cases without relative
>    imports support.
>    
>    Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>  - 8319332: Implement security properties 'include'
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Fr...

Since this pull request is still waiting for a review, we will merge `openjdk/master` to keep the branch up to date. Before that, we will make some little changes including a `ConfigFileTest.java` update with [JDK-8319673](https://bugs.openjdk.org/browse/JDK-8319673 "Few security tests ignore VM flags") equivalent code. During the merge, the conflict will be resolved by ignoring 430290066c23d09166a84f2f6f89e770c6ba04ff changes in `ConfigFileTest.java`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1976885448


From mullan at openjdk.org  Mon Mar  4 16:22:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 16:22:51 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

src/java.base/share/classes/javax/security/auth/Subject.java line 112:

> 110:  *
> 111:  * <p><b><a id="sm-allowed">These methods behave differently depending on
> 112:  * whether a security manager is allowed or disallowed</a></b>:

Suggest linking "a security manager is allowed or disallowed" to `SecurityManager.html#set-security-manager`.

src/java.base/share/classes/javax/security/auth/Subject.java line 120:

> 118:  * {@code getSubject(AccessControlContext)} method.
> 119: *  <li>If a security manager is not allowed, which means it
> 120:  * {@linkplain System#setSecurityManager is not set and not allowed to be set

I think `SecurityManager.html#set-security-manager` is a better (more informative) link. Also, not sure why it is linked here but not in the "If a security manager is allowed" paragraph. If you link it in the first sentence ("These methods behave differently ...) then you probably only need one link and don't need this link.

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 27:

> 25:  * @test
> 26:  * @bug 8296244
> 27:  * @enablePreview

Can you add a comment as to why `enablePreview` is needed? (Assume it is for `StructuredTaskScope`.)

test/jdk/javax/security/auth/Subject/Compat.java line 34:

> 32: /*
> 33:  * @test
> 34:  * @run main/othervm -Djava.security.manager=allow Compat

Missing `@summary` and `@bug`.

test/jdk/javax/security/auth/Subject/UnsupportedSV.java line 59:

> 57: 
> 58:         // TODO: Still has no way to reject the following code.
> 59:         // Here, AccessController::getContext returns a plan ACC without

typo: s/plan/plain/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511419716
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511424024
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511380094
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511393254
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511366395


From fferrari at openjdk.org  Mon Mar  4 17:20:16 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 4 Mar 2024 17:20:16 GMT
Subject: RFR: 8319332: Security properties files inclusion [v6]
In-Reply-To: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
Message-ID: <rqK3UZdlTl1xbbRPPDHiBIO51tAaJpbF_eVdwK_dH6w=.3bae5867-35f0-48f1-a6bd-22e69c832d23@github.com>

> The implementation of this proposal is based on the requirements, specification and design choices described in the [JDK-8319332] ticket and its respective CSR [JDK-8319333]. What follows are implementation notes organized per functional component, with the purpose of assisting to navigate the code changes in this pull-request.
> 
> ## Security properties loading (overview)
> 
> A new static class named `SecPropLoader` (nested within `java.security.Security`) is introduced to handle the loading of all security properties. Its method `loadAll` is the first one to be called, at `java.security.Security` static class initialization. The master security properties file is then loaded by `loadMaster`. When additional security properties files are allowed (the security property `security.overridePropertiesFile` is set to `true`) and the `java.security.properties` system property is passed, the method `loadExtra` handles the extra load.
> 
> The master properties file is loaded in `OVERRIDE` mode, meaning that the map of properties is originally empty. Any failure occurred while loading these properties is considered fatal. The extra properties file (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. Any failure in this case is ignored. This behavior maintains compatibility with the previous implementation.
> 
> While the `java.security.properties` system property is documented to accept an URL type of value, filesystem path values are supported in the same way that they were prior to this enhancement. Values are then interpreted as paths and, only if that fails, are considered URLs. In the latter case, there is one more attempt after opening the stream to check if there is a local file path underneath (e.g. the URL has the form of `file:///path/to/a/local/file`). The reason for preferring paths over URLs is to support relative path file inclusion in properties files.
> 
> ## Loading security properties from paths (`loadFromPath` method)
> 
> When loading a properties file from a path, the normalized file location is stored in the static field `currentPath`. This value is the current base to resolve any relative path encountered while handling an _include_ definition. Normalized paths are also saved in the `activePaths` set to detect recursive cycles. As we move down or up in the _includes_ stack, `currentPath` and `activePaths` values are updated.
> 
> ## Loading security properties from URLs (`loadFromUrl` method)
> 
> The extra properties file can be loaded from a URL. ...

Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge 'openjdk/master' into JDK-8319332
   
   Conflict in ConfigFileTest.java solved by keeping our file, which had
   been previously adjusted.
   
   Commands:
     git merge upstream/master
     git restore --ours -- test/jdk/java/security/Security/ConfigFileTest.java
     git add test/jdk/java/security/Security/ConfigFileTest.java
     git merge --continue
 - 8319332: Adjust code for JDK-8319673 changes
   
   JDK-8319673: Few security tests ignore VM flags
   
   Next, we will merge the openjdk/master branch and ignore the conflict in
   this file.
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Update copyright and ConfigFileTest.java.
   
   Bump copyright year to 2024 in all the modified files.
   
   Remove leaked host name from children JVMs debug command.
   
   Extract Executor::addSystemPropertiesAsJvmArgs from Executor::execute
   and rename 'allJvmArgs' to 'command'. Also split class name and
   RUNNER_ARG addition to 'command' as two separated command.add() calls.
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - Merge 'openjdk/master' into JDK-8319332
 - 8319332: Fix corner-case regression with bash pipe
   
   Extra properties files provided through bash pipes used to work before
   this enhancement, restore their behaviour.
   
   Also take advantage to use Files::isRegularFile, Files::isDirectory and
   Files::exists APIs instead of converting from Path to File.
   
   Linux reproducers (sub-shell, stdin, and combination of both):
   
   java -XshowSettings:security:properties                      \
        -Djava.security.properties==<(echo name=value)          \
        -Djava.security.debug=properties -version
   
   echo name=value | java -XshowSettings:security:properties    \
        -Djava.security.properties==/dev/stdin                  \
        -Djava.security.debug=properties -version
   
   echo name=value | java -XshowSettings:security:properties    \
        -Djava.security.properties==<(echo include /dev/stdin)  \
        -Djava.security.debug=properties -version
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Remove wildcard imports, adjust test case
   
   Test case adjustments: add missing check in PropsFile::assertApplied(),
   and fix typo in FilesManager::handleRequest() method name.
   
   Also, add clarifying comments to Executor::assertSuccess() explaining
   how we use the special properties to make the assertion. Make 'lastFile'
   assignation latter, so it's separated from the first group of asserts.
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: use Path::of(URI) to deal with file URLs
   
   Instead of the previously introduced FileURLConnection::getFile(), use
   Path::of(URI), leaving some file URL corner-cases without relative
   imports support.
   
   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Implement security properties 'include'
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Refactor security properties file test
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Refactor properties file loading code
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

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

Changes: https://git.openjdk.org/jdk/pull/16483/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16483&range=05
  Stats: 1201 lines in 6 files changed: 965 ins; 165 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/16483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16483/head:pull/16483

PR: https://git.openjdk.org/jdk/pull/16483


From duke at openjdk.org  Mon Mar  4 17:57:53 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 4 Mar 2024 17:57:53 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <qAg9sBkhBX3Tz-u_j8AcEtfnaW5WifKDfFN168_uyTo=.ad5198d5-03f3-4f09-8af7-f89a1157bb75@github.com>

On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

src/java.base/share/classes/java/lang/ModuleLayer.java line 885:

> 883: 
> 884:     /**
> 885:      * Returns the module with the given name in this later only.

Suggestion:

     * Returns the module with the given name in this layer only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1511542904


From weijun at openjdk.org  Mon Mar  4 19:54:45 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 19:54:45 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
Message-ID: <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>

On Mon, 4 Mar 2024 15:28:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:
> 
>> 307:         final Subject s;
>> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>> 309:             s = Subject.current();
> 
> We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.

I was not exactly sure if we will support this functionality. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511716084


From mullan at openjdk.org  Mon Mar  4 19:59:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 19:59:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
Message-ID: <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>

On Mon, 4 Mar 2024 19:51:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:
>> 
>>> 307:         final Subject s;
>>> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>>> 309:             s = Subject.current();
>> 
>> We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.
>
> I was not exactly sure if we will support this functionality. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.

I think we need @kevinjwalls or @dfuch to help advise on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511721920


From lancea at openjdk.org  Mon Mar  4 20:16:51 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 4 Mar 2024 20:16:51 GMT
Subject: RFR: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <LJLqwhot1za0zlfVK9C4Z6R40Ltr3biGjl17zNB1UII=.ed3dc386-a010-4d88-a5c9-570240cbefb6@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18104#pullrequestreview-1915256398


From iris at openjdk.org  Mon Mar  4 20:26:43 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 4 Mar 2024 20:26:43 GMT
Subject: RFR: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <84pJEELHzfdC6V0_t5n1IQlpmTD7BXoNWqun2tb5xtk=.a1b24c6b-17a2-47ac-9cd8-8b12dca077a3@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18104#pullrequestreview-1915271908


From weijun at openjdk.org  Mon Mar  4 20:33:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:33:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
Message-ID: <e65Omm5EaxnZ_Q4ymvpwK0kafK6AWDhLAJDUqPzhEvc=.a8badc5d-0ce1-4302-94bc-f03e9920326d@github.com>

On Mon, 4 Mar 2024 15:15:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:
> 
>> 67:         }
>> 68:         private void setPrincipal() {
>> 69:             Subject subject = Subject.current();
> 
> Why change this to `Subject.current()` if you are requiring the SM to be allowed?

When SM is allowed, `Subject.current()` is equivalent to `Subject.getSubject(AccessController.getContext())`. I can revert the change.

> test/jdk/javax/security/auth/Subject/UnsupportedSV.java line 59:
> 
>> 57: 
>> 58:         // TODO: Still has no way to reject the following code.
>> 59:         // Here, AccessController::getContext returns a plan ACC without
> 
> typo: s/plan/plain/

Yes.

> test/jdk/javax/security/auth/Subject/doAs/NestedActions.java line 283:
> 
>> 281:     static void readFile(String filename) {
>> 282:         System.out.println("ReadFromFileAction: try to read " + filename);
>> 283:         Subject subject = Subject.current();
> 
> Couldn't we have just left these calling `Subject.getSubject` for now since these tests run with an SM enabled?

Yes, we can.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511755373
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511756265
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511755860


From weijun at openjdk.org  Mon Mar  4 20:39:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:39:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
Message-ID: <AWOnbHXGoCGZKp0Ecva-eQU-Yf9hn6mdPmp1qVThatU=.dfb9494c-31fb-410b-bab5-d27e314144eb@github.com>

On Mon, 4 Mar 2024 15:47:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8296244
>> 27:  * @enablePreview
> 
> Can you add a comment as to why `enablePreview` is needed? (Assume it is for `StructuredTaskScope`.)

OK.

> test/jdk/javax/security/auth/Subject/Compat.java line 34:
> 
>> 32: /*
>> 33:  * @test
>> 34:  * @run main/othervm -Djava.security.manager=allow Compat
> 
> Missing `@summary` and `@bug`.

Will Add.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511760021
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511761591


From weijun at openjdk.org  Mon Mar  4 20:49:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:49:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
Message-ID: <xQbhbPkhHusDyyQ8zlwv0Xr3CZvYyP5aKVWOR4llj4s=.9bcccc3f-b7c7-4b59-b7b9-b8bd2427af9e@github.com>

On Mon, 4 Mar 2024 16:17:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 120:
> 
>> 118:  * {@code getSubject(AccessControlContext)} method.
>> 119: *  <li>If a security manager is not allowed, which means it
>> 120:  * {@linkplain System#setSecurityManager is not set and not allowed to be set
> 
> I think `SecurityManager.html#set-security-manager` is a better (more informative) link. Also, not sure why it is linked here but not in the "If a security manager is allowed" paragraph. If you link it in the first sentence ("These methods behave differently ...) then you probably only need one link and don't need this link.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511771517


From weijun at openjdk.org  Mon Mar  4 21:54:13 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 21:54:13 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v4]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <9_c9PpQBHzo6FdR5aaSQ_qCCwrd2yGr1CNsGdj6HDjk=.84620353-2d09-4599-8a05-b3b2f08ab855@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

  revert some test changes, spec change for subject

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/8f270d09..e57f7250

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=02-03

  Stats: 44 lines in 6 files changed: 18 ins; 3 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472


From duke at openjdk.org  Mon Mar  4 21:58:53 2024
From: duke at openjdk.org (MustavData)
Date: Mon, 4 Mar 2024 21:58:53 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <2TJXIkiCq7uhYixL4X2_Kqz0xbrcy0fcpkrUiyhA2vo=.cfaf77ea-66db-4b0c-b48b-881c56c9433c@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <2TJXIkiCq7uhYixL4X2_Kqz0xbrcy0fcpkrUiyhA2vo=.cfaf77ea-66db-4b0c-b48b-881c56c9433c@github.com>
Message-ID: <WhOm5sbqspQT3k9uKh41ofXQC2Gx-TQyh14OgQZDl8U=.a46e6a79-a676-4e7c-840c-37da0ade821c@github.com>

On Wed, 24 Jan 2024 00:41:15 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> Please enable github actions so that minimal tier1 jtreg tests are run; as you're changing the behavior of KeyStore.load (for SunMSCAPI) you should really test that all available write operations fail as expected (as they did before this change).

@macarte :  In your [comment on JDK-8313367](https://bugs.openjdk.org/browse/JDK-8313367?focusedId=14643246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14643246), you suggest that perhaps "this is a feature request".   What do you mean by that?  

[JDK-6782021](https://bugs.openjdk.org/browse/JDK-6782021) provides the Microsoft CNG interface for an OpenJDK application, such as jarsigner.exe, to function as a native Windows application when integrated with something like [Azure Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/).   On a secure system, by the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege), the following accesses would inhibit a bad actor from committing code signing forgery:

  1)  Builder user access:
        a)  Code signing authorization
        b)  Read-only access to the Local Computer keystore.
        c)  No membership in the local Administrators group.

  2)  System admin access:
        a)  No code signing authorization
        b)  Read-write access to the Local Computer keystore.
        c)  Membership in the local Administrators group

These accesses provide complete, unambiguous separation of roles.  A user with dual roles must remain vigilant to accurately simulate a production environment when verifying this fix.  Code signing authorization would be assigned, for example, by a key vault admin.  A system admin privilege is not also needed.   So, for this test, an elevation prompt should be seen as a red flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1977530357


From weijun at openjdk.org  Mon Mar  4 22:31:52 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 22:31:52 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <WM7SFh2Q7hvTx7Fs_wiqoag3550W902BdDf8ALAcXUw=.6a004177-0b42-439d-8c7c-2bc33074b5e9@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

For "this is a feature request", I think Mat means the type of this JBS issue should be an "Enhancement" instead of a "Bug".

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1977579741


From macarte at openjdk.org  Mon Mar  4 23:58:52 2024
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 4 Mar 2024 23:58:52 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <m4XUgexOnhJwQn-SNIxYIYr-DV1ouwzLqAa96cUTjL0=.5fc1f78a-5e50-46c7-8148-58514f4fd726@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

For clarification I've edited the comment in the JBS issue, replacing "feature request" with "enhancement" so that it properly matches the terminology used in JBS.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1977691948


From jpai at openjdk.org  Tue Mar  5 04:28:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 04:28:44 GMT
Subject: RFR: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <fRItNcOqp860rtjDFnxsG6OGTGZRNOgx9jE97dcrH08=.1caf787d-467b-4aa3-8087-1d1ec765b227@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

Hello Eirik, the removal of this internal unused package private method and the updated comments in the tests look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18104#pullrequestreview-1915846886


From aturbanov at openjdk.org  Tue Mar  5 07:12:47 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 5 Mar 2024 07:12:47 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v2]
In-Reply-To: <qZT8DM9L1qa1D5rjytsaM_DHvcwDxBF6nASsf4tP5-s=.33bcdec4-3247-425c-af95-3242e52315ed@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <qZT8DM9L1qa1D5rjytsaM_DHvcwDxBF6nASsf4tP5-s=.33bcdec4-3247-425c-af95-3242e52315ed@github.com>
Message-ID: <EM75skJFTexhpfITKRH7YePtnN-P_7V_OEUADb-adto=.020f569a-685e-40c5-9689-b9e340ea45ba@github.com>

On Sat, 2 Mar 2024 13:51:04 GMT, Korov <duke at openjdk.org> wrote:

>> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
>> 
>> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
>> 
>> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.
>
> Korov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modiy the code accordingto the review

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18086#pullrequestreview-1916019640


From eirbjo at openjdk.org  Tue Mar  5 08:41:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 5 Mar 2024 08:41:55 GMT
Subject: RFR: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <nl4Rjy6FqsKKJBBUCdZngbYTx2_o91uYFlnfT7ACwV8=.ea7cd02f-5c2d-4e99-a7a9-4d70c7fb6c34@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

Thanks for reviewing, Lance, Iris & Jai!

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

PR Comment: https://git.openjdk.org/jdk/pull/18104#issuecomment-1978224550


From eirbjo at openjdk.org  Tue Mar  5 08:41:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 5 Mar 2024 08:41:55 GMT
Subject: Integrated: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <XvEZAWuRwR5yf90CW3PvhzdK_-ZEyXnZcQZodosZGgw=.489c378f-0b53-424a-8c19-84049cdd0a20@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

This pull request has now been integrated.

Changeset: e9adceba
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9adcebaf242843fe2004b01747b5a930b62b291
Stats:     33 lines in 3 files changed: 2 ins; 21 del; 10 mod

8327208: Remove unused method java.util.jar.Manifest.make72Safe

Reviewed-by: lancea, iris, jpai

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

PR: https://git.openjdk.org/jdk/pull/18104


From kevinw at openjdk.org  Tue Mar  5 11:39:48 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 11:39:48 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
Message-ID: <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>

On Mon, 4 Mar 2024 19:57:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I was not exactly sure if we will support this functionality when there is no SM. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.
>
> I think we need @kevinjwalls or @dfuch to help advise on this.

Right, this does not depend on the SM.   All we need to do is get the Subject.
This method implements the basic monitor (readonly) and control (readwrite) access.
accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1512676642


From gli at openjdk.org  Tue Mar  5 12:03:45 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 5 Mar 2024 12:03:45 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v2]
In-Reply-To: <V_uDmQqbi0jB73dnwWo3KnfxRdRvl-ZqJ2PHacJ7YpY=.35d76a3e-2d30-4562-86df-d2a95ce5a00b@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>
 <s3O_-Igct9FVE_H8czPXtGJpT7HcWkV4Zq_32cG1Zls=.4ee3a5de-31a2-4c05-90ce-6bc04f4076ee@github.com>
 <V_uDmQqbi0jB73dnwWo3KnfxRdRvl-ZqJ2PHacJ7YpY=.35d76a3e-2d30-4562-86df-d2a95ce5a00b@github.com>
Message-ID: <iwkZNLvBPCT95X26xLY-a1JyQtlBhjJF57_ggFAncZI=.ac819afc-7141-41b9-aa78-63cd663c6c87@github.com>

On Sat, 2 Mar 2024 11:43:27 GMT, Korov <duke at openjdk.org> wrote:

> Seems good. If nobody disagrees such mixed patch, I will help you change the title and content of the issue.

Have changed just now! And please wait for a formal reviewer to review this path.

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1978603310


From jlahoda at openjdk.org  Tue Mar  5 12:44:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Mar 2024 12:44:10 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18106/files
  - new: https://git.openjdk.org/jdk/pull/18106/files/924e1aa0..6127044d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18106&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18106&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18106.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18106/head:pull/18106

PR: https://git.openjdk.org/jdk/pull/18106


From jlahoda at openjdk.org  Tue Mar  5 12:44:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Mar 2024 12:44:10 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <XHuh25R9QzUR6dEzXvV1dN_29eVRempkb1qPsDQvTrk=.86e9f3f0-a94d-45db-a5fc-00d6db0c6f84@github.com>

On Tue, 5 Mar 2024 12:41:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 806:

> 804:     /**
> 805:      * Process the --enable-native-access option to grant access to restricted methods to selected modules.
> 806:      * Also add Enable native access from JDK modules.

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512761636


From duke at openjdk.org  Tue Mar  5 13:39:50 2024
From: duke at openjdk.org (Korov)
Date: Tue, 5 Mar 2024 13:39:50 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v2]
In-Reply-To: <iwkZNLvBPCT95X26xLY-a1JyQtlBhjJF57_ggFAncZI=.ac819afc-7141-41b9-aa78-63cd663c6c87@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>
 <s3O_-Igct9FVE_H8czPXtGJpT7HcWkV4Zq_32cG1Zls=.4ee3a5de-31a2-4c05-90ce-6bc04f4076ee@github.com>
 <V_uDmQqbi0jB73dnwWo3KnfxRdRvl-ZqJ2PHacJ7YpY=.35d76a3e-2d30-4562-86df-d2a95ce5a00b@github.com>
 <iwkZNLvBPCT95X26xLY-a1JyQtlBhjJF57_ggFAncZI=.ac819afc-7141-41b9-aa78-63cd663c6c87@github.com>
Message-ID: <XiuAe_ZZsvyhrZwq_JC37YMi-beIi6lNXURM2-PBf7c=.4cdee03e-8fce-4072-89d8-79410fc11619@github.com>

On Tue, 5 Mar 2024 12:01:38 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> > Seems good. If nobody disagrees such mixed patch, I will help you change the title and content of the issue.
> 
> Have changed just now! And please wait for a formal reviewer to review this path.

Thanks so much!!!

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1978794261


From jpai at openjdk.org  Tue Mar  5 13:51:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 13:51:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>

On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

make/conf/module-loader-map.conf line 95:

> 93:     #
> 94: 
> 95: NATIVE_ACCESS_MODULES= \

Hello Jan, does this make configuration allow for something like:


NATIVE_ACCESS_MODULES= ${BOOT_MODULES} \
${PLATFORM_MODULES} \
foo.bar.additional.module

(please ignore any syntax issues in that snippet)

to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512845758


From jpai at openjdk.org  Tue Mar  5 14:04:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 14:04:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <CQCdfDP6785EDomU2zdtqsi6DpyHYpnHo20Sucs7xPc=.58038e72-419c-40a5-a378-a7bd6b766809@github.com>

On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Some of the files updated in this PR need a copyright year update.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 817:

> 815:                 JLA.addEnableNativeAccessToAllUnnamed();
> 816:             } else if (!JLA.addEnableNativeAccess(layer, name) && shouldWarn) {
> 817:                 warnUnknownModule(ENABLE_NATIVE_ACCESS, name);

Should we instead warn irrespective of whether or not it's user configured native access module name or a module name configured in JDK's build configuration? Or are the build misconfiguration in the `NATIVE_ACCESS_MODULES` expected to be caught much earlier in some other place?

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

PR Comment: https://git.openjdk.org/jdk/pull/18106#issuecomment-1978836356
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512869279


From alanb at openjdk.org  Tue Mar  5 14:04:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Mar 2024 14:04:48 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
Message-ID: <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>

On Tue, 5 Mar 2024 13:42:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?

The list to be be granted native access is a subset, it shouldn't be granted all modules mapped to the boot or platform class loaders.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512873855


From jpai at openjdk.org  Tue Mar  5 14:16:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 14:16:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
 <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
Message-ID: <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>

On Tue, 5 Mar 2024 14:01:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> make/conf/module-loader-map.conf line 95:
>> 
>>> 93:     #
>>> 94: 
>>> 95: NATIVE_ACCESS_MODULES= \
>> 
>> Hello Jan, does this make configuration allow for something like:
>> 
>> 
>> NATIVE_ACCESS_MODULES= ${BOOT_MODULES} \
>> ${PLATFORM_MODULES} \
>> foo.bar.additional.module
>> 
>> (please ignore any syntax issues in that snippet)
>> 
>> to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?
>
>> to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?
> 
> The list to be be granted native access is a subset, it shouldn't be granted all modules mapped to the boot or platform class loaders.

I see. I then misunderstood a part of the PR description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512894628


From mullan at openjdk.org  Tue Mar  5 14:26:47 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Mar 2024 14:26:47 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
 [v3]
In-Reply-To: <mgpIEOJk9SB4HS1I1lwAC4VFPmVU0pkvyE7OPovczlE=.2e972411-1014-4c89-8065-fbb3328705a7@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
 <mgpIEOJk9SB4HS1I1lwAC4VFPmVU0pkvyE7OPovczlE=.2e972411-1014-4c89-8065-fbb3328705a7@github.com>
Message-ID: <v5I_yucA1eBJIxRj1x44izPI-hJF958MTNfrEV-2aWM=.236e1a58-5f0e-48d8-9235-2534904514aa@github.com>

On Fri, 12 Jan 2024 18:06:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Re-implement it as an `Iterator` to make sure it can only be iterated once and make debugger happy.
>> 
>> No regression, just a refactoring.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use consistent names

src/java.base/share/classes/sun/security/jca/ProviderList.java line 429:

> 427:      * Not thread safe.
> 428:      */
> 429:     private final class ServiceList implements Iterator<Service> {

Wouldn't it make more sense to change the name to `ServiceIterator`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1512913289


From nicolas at simide.fr  Tue Mar  5 14:26:57 2024
From: nicolas at simide.fr (Nicolas SIMIDE)
Date: Tue, 5 Mar 2024 15:26:57 +0100
Subject: JDK-8293345
Message-ID: <87e5647a-3008-457b-bf9a-24e8b37f3a5a@Spark>

Hello,

Sorry in advance for the inconvenience.
Would it be possible to do something about request JDK-8293345 ?

Thanks in advance.
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240305/5d920e73/attachment.htm>

From weijun at openjdk.org  Tue Mar  5 14:46:47 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:46:47 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
Message-ID: <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>

On Tue, 5 Mar 2024 11:36:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I think we need @kevinjwalls or @dfuch to help advise on this.
>
> Right, this does not depend on the SM.   All we need to do is get the Subject.
> This method implements the basic monitor (readonly) and control (readwrite) access.
> accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.

Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1512951092


From weijun at openjdk.org  Tue Mar  5 14:55:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:55:06 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
 [v4]
In-Reply-To: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
Message-ID: <x_mbt4vFcIqTisw9TX-yqAIiEyN4yCZehoNqUwXH0NA=.cf4b5a6a-060b-4c32-89bd-d179094f11cb@github.com>

> Re-implement it as an `Iterator` to make sure it can only be iterated once and make debugger happy.
> 
> No regression, just a refactoring.

Weijun Wang 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 five additional commits since the last revision:

 - Merge branch 'master' into 8323624
 - rename class name
 - use consistent names
 - : iterator
 - the fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17381/files
  - new: https://git.openjdk.org/jdk/pull/17381/files/cf3d124e..4cfc4c9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17381&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17381&range=02-03

  Stats: 97314 lines in 3236 files changed: 46912 ins; 26097 del; 24305 mod
  Patch: https://git.openjdk.org/jdk/pull/17381.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17381/head:pull/17381

PR: https://git.openjdk.org/jdk/pull/17381


From weijun at openjdk.org  Tue Mar  5 14:55:07 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:55:07 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
 [v3]
In-Reply-To: <v5I_yucA1eBJIxRj1x44izPI-hJF958MTNfrEV-2aWM=.236e1a58-5f0e-48d8-9235-2534904514aa@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
 <mgpIEOJk9SB4HS1I1lwAC4VFPmVU0pkvyE7OPovczlE=.2e972411-1014-4c89-8065-fbb3328705a7@github.com>
 <v5I_yucA1eBJIxRj1x44izPI-hJF958MTNfrEV-2aWM=.236e1a58-5f0e-48d8-9235-2534904514aa@github.com>
Message-ID: <_np_fMv5KAxgJox1DB7XfkqR8B_o0xPIj0Te8vric0c=.2d50ab87-2467-421a-87be-721fb49906ea@github.com>

On Tue, 5 Mar 2024 14:24:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use consistent names
>
> src/java.base/share/classes/sun/security/jca/ProviderList.java line 429:
> 
>> 427:      * Not thread safe.
>> 428:      */
>> 429:     private final class ServiceList implements Iterator<Service> {
> 
> Wouldn't it make more sense to change the name to `ServiceIterator`?

You're right. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1512964316


From weijun at openjdk.org  Tue Mar  5 14:58:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:58:25 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v5]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <5fLmCMsDfb6akv1964_z9y8a4ccxmXaLJVjNiU5Khvs=.69025b5e-374e-4ae2-9db8-d27580a10345@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into 8296244
 - revert some test changes, spec change for subject
 - fix MBeanServerFileAccessController, more test in SM
 - JMX needs SM
 - Resolve Alan's comments
 - remove exe bits
 - remove x bit
 - the patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/e57f7250..2b55b171

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=03-04

  Stats: 97308 lines in 3235 files changed: 46912 ins; 26097 del; 24299 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472


From jlahoda at openjdk.org  Tue Mar  5 16:15:46 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Mar 2024 16:15:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
 <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
 <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>
Message-ID: <qUywPUBxrFPqmBQt0CmeoIjDdY__AaxZ1RnqbqpKtxs=.19abd551-8a3b-40e0-a148-0701fbce0405@github.com>

On Tue, 5 Mar 2024 14:14:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?
>> 
>> The list to be be granted native access is a subset, it shouldn't be granted all modules mapped to the boot or platform class loaders.
>
> I see. I then misunderstood a part of the PR description.

I believe we could technically reuse the list for boot/platform modules. But, the intent here is to provide more control over the modules with native access, not only being able to add to the list, but also remove from the list. So, to me, it seemed better to have an explicit list, from/to which we can remove/add modules easily.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513107379


From eirbjo at gmail.com  Tue Mar  5 16:38:53 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 5 Mar 2024 17:38:53 +0100
Subject: RFD: Missing @deprecated note in
 SecurityManager.checkMulticast(InetAddress, byte)
Message-ID: <CA+pBWhvtb9nPbw==S2KTknAS7y7r=9+5L3Tjaz3X7sg3vxYX2w@mail.gmail.com>

Hi,

I noticed that the long-deprecated
method SecurityManager.checkMulticast(InetAddress, byte) no longer has a
@deprecated note.

Some context:

o The method has been marked @Deprecated since the initial load of OpenJDK
code in 2007
o In 2016, JDK-8145468 [1] added since="1.4"
o  In 2021, JDK-8266459 [2] (JEP 411 implementation) added forRemoval=true,
but curiously also removed the @deprecated note

The removed @deprecated note read:

@deprecated Use #checkPermission(java.security.Permission) instead


The removal of the note was not part of the Specification section of the
JEP-411 CSR [3], which simply read:

@@ -1082,11 +1087,11 @@
>        *             {@code null}.
>        * @since      1.1
>        * @deprecated Use #checkPermission(java.security.Permission) instead
>        * @see        #checkPermission(java.security.Permission)
> checkPermission
>        */
> -     @Deprecated(since="1.4")
> +     @Deprecated(since="1.4", forRemoval=true)
>       public void checkMulticast(InetAddress maddr, byte ttl) {
>           String host = maddr.getHostAddress();
>           if (!host.startsWith("[") && host.indexOf(':') != -1) {
>               host = "[" + host + "]";
>           }


I'm wondering if this was removed by accident, or if there was some
deliberation behind the choice to remove the deprecation note.

If it should not have been removed, would it be worthwhile to add it back,
considering this change was in conflict with the CSR? The deprecation note
is useful in that it recommends a replacement method for the deprecated
method.

Or are we better off just ignoring this, given the eventual removal of
SecurityManager?

Thanks,
Eirik.

[1] https://bugs.openjdk.org/browse/JDK-8145468
[2] https://bugs.openjdk.org/browse/JDK-8266459
[3] https://bugs.openjdk.org/browse/JDK-8266577
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240305/39f49d11/attachment.htm>

From Alan.Bateman at oracle.com  Tue Mar  5 16:43:18 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 5 Mar 2024 16:43:18 +0000
Subject: RFD: Missing @deprecated note in
 SecurityManager.checkMulticast(InetAddress, byte)
In-Reply-To: <CA+pBWhvtb9nPbw==S2KTknAS7y7r=9+5L3Tjaz3X7sg3vxYX2w@mail.gmail.com>
References: <CA+pBWhvtb9nPbw==S2KTknAS7y7r=9+5L3Tjaz3X7sg3vxYX2w@mail.gmail.com>
Message-ID: <41ca1645-4b22-494d-a9fc-76c570a49f7a@oracle.com>



On 05/03/2024 16:38, Eirik Bj?rsn?s wrote:
> :
>
> Or are we better off just ignoring this, given the eventual removal of 
> SecurityManager?
>
I don't think it's worth spending time on this. There will be a JEP to 
remove the SM "feature" (not the APIs) so methods like this will likely 
be re-specified to throw unconditionally. It would be just busy work to 
adjust them for a release or two.

-Alan


From eirbjo at gmail.com  Tue Mar  5 16:46:12 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 5 Mar 2024 17:46:12 +0100
Subject: RFD: Missing @deprecated note in
 SecurityManager.checkMulticast(InetAddress, byte)
In-Reply-To: <41ca1645-4b22-494d-a9fc-76c570a49f7a@oracle.com>
References: <CA+pBWhvtb9nPbw==S2KTknAS7y7r=9+5L3Tjaz3X7sg3vxYX2w@mail.gmail.com>
 <41ca1645-4b22-494d-a9fc-76c570a49f7a@oracle.com>
Message-ID: <CA+pBWhviKLYac3qmtsAT0aRNKw3vc7MNEG-ekMCUWpZP91=JFA@mail.gmail.com>

On Tue, Mar 5, 2024 at 5:43?PM Alan Bateman <Alan.Bateman at oracle.com> wrote:

> > Or are we better off just ignoring this, given the eventual removal of
> > SecurityManager?
> >
> I don't think it's worth spending time on this. There will be a JEP to
> remove the SM "feature" (not the APIs) so methods like this will likely
> be re-specified to throw unconditionally. It would be just busy work to
> adjust them for a release or two.
>

Thanks Alan, that makes sense.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240305/a50eceb7/attachment.htm>

From kevinw at openjdk.org  Tue Mar  5 16:51:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 16:51:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
Message-ID: <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>

On Tue, 5 Mar 2024 14:44:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Right, this does not depend on the SM.   All we need to do is get the Subject.
>> This method implements the basic monitor (readonly) and control (readwrite) access.
>> accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.
>
> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.

Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

(That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
https://github.com/openjdk/jdk/pull/18025 )

makeClient in RMIJRMPServerImpl creates RMIConnectionImpl

..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513164360


From alanb at openjdk.org  Tue Mar  5 18:58:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Mar 2024 18:58:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>

On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

I assume you'll bump the copyright header on all files before integrating.

make/conf/module-loader-map.conf line 139:

> 137:     jdk.unsupported \
> 138:     jdk.xml.dom \
> 139:     jdk.zipfs \

We should create a JBS issue to prune this.

src/java.base/share/classes/java/lang/ModuleLayer.java line 896:

> 894:         return nameToModule.get(name);
> 895:     }
> 896: 

What would you think about replacing this with addEnableNativeAccess(String name) so it can be called by JLA. addEnableNativeAccess. The reason is that the JLA methods are usually just calls to some non-public method but the changes mean mean there is "core" in the JLA method that is not easy to find.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 812:

> 810:     }
> 811: 
> 812:     private static void addEnableNativeAccess(ModuleLayer layer, Set<String> moduleNames, boolean shouldWarn) {

The private methods in this class have a short comment to summarise what they do.

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

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1917862955
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513331594
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513345563
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513347180


From weijun at openjdk.org  Tue Mar  5 19:56:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 19:56:58 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

  revert changes to MBeanServerFileAccessController.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/2b55b171..80810b54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=04-05

  Stats: 14 lines in 1 file changed: 0 ins; 5 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472


From weijun at openjdk.org  Tue Mar  5 19:56:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 19:56:58 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
 <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
Message-ID: <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>

On Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.
>
> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
> 
> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
> https://github.com/openjdk/jdk/pull/18025 )
> 
> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
> 
> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.

I?ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.

Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513410552


From mullan at openjdk.org  Tue Mar  5 20:00:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Mar 2024 20:00:46 GMT
Subject: RFR: 8311002: missing @since info in 21 files in jdk.security.auth
In-Reply-To: <wc90QWTwJjCcb4DACm6UGNY7vUDXBJHyF2_FJuZ6URk=.c957ef4b-a31b-482b-95d3-82d9dfe72028@github.com>
References: <wc90QWTwJjCcb4DACm6UGNY7vUDXBJHyF2_FJuZ6URk=.c957ef4b-a31b-482b-95d3-82d9dfe72028@github.com>
Message-ID: <GzjN6F8xX-DXF0EaHg2JDvs8ewnDgzwelAC1ThSUXys=.a9143d80-858f-495f-b582-3f3e9ea56d05@github.com>

On Thu, 22 Feb 2024 18:47:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add `@since` info. JAAS was included in JDK 1.4 and these classes were all in the initial release.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17969#pullrequestreview-1917989848


From weijun at openjdk.org  Tue Mar  5 20:35:50 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 20:35:50 GMT
Subject: Integrated: 8311002: missing @since info in 21 files in
 jdk.security.auth
In-Reply-To: <wc90QWTwJjCcb4DACm6UGNY7vUDXBJHyF2_FJuZ6URk=.c957ef4b-a31b-482b-95d3-82d9dfe72028@github.com>
References: <wc90QWTwJjCcb4DACm6UGNY7vUDXBJHyF2_FJuZ6URk=.c957ef4b-a31b-482b-95d3-82d9dfe72028@github.com>
Message-ID: <mdUaTZsoxwxIK-cNlLIAabB5PhXHZDA43iM1mpPsXSQ=.7b17dfa1-6e3f-4d8a-892d-ef6ad175c128@github.com>

On Thu, 22 Feb 2024 18:47:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add `@since` info. JAAS was included in JDK 1.4 and these classes were all in the initial release.

This pull request has now been integrated.

Changeset: a7280d1b
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7280d1b9657f1afd07d4a550b687f6ad3f9c885
Stats:     60 lines in 21 files changed: 39 ins; 0 del; 21 mod

8311002: missing @since info in 21 files in jdk.security.auth

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/17969


From mchung at openjdk.org  Tue Mar  5 22:46:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 5 Mar 2024 22:46:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
Message-ID: <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>

On Tue, 5 Mar 2024 18:43:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> make/conf/module-loader-map.conf line 139:
> 
>> 137:     jdk.unsupported \
>> 138:     jdk.xml.dom \
>> 139:     jdk.zipfs \
> 
> We should create a JBS issue to prune this.

Many of these modules do not need native access in the current implementation.   Should this list be trimmed to list the ones that need native access in the current implementation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513588480


From jpai at openjdk.org  Wed Mar  6 00:58:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 6 Mar 2024 00:58:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <qUywPUBxrFPqmBQt0CmeoIjDdY__AaxZ1RnqbqpKtxs=.19abd551-8a3b-40e0-a148-0701fbce0405@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
 <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
 <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>
 <qUywPUBxrFPqmBQt0CmeoIjDdY__AaxZ1RnqbqpKtxs=.19abd551-8a3b-40e0-a148-0701fbce0405@github.com>
Message-ID: <pR_tzy5Mm3VY2y4uJfeE8MxORUmVZ8yv_3fyFJvz-ho=.345d8490-f43b-4757-8ae7-ac0e353e4bd9@github.com>

On Tue, 5 Mar 2024 16:13:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I see. I then misunderstood a part of the PR description.
>
> I believe we could technically reuse the list for boot/platform modules. But, the intent here is to provide more control over the modules with native access, not only being able to add to the list, but also remove from the list. So, to me, it seemed better to have an explicit list, from/to which we can remove/add modules easily.

Hello Jan, my suggestion was based on a misunderstanding that NATIVE_ACCESS_MODULES is always a superset of boot and platform modules. What you currently have looks fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513674172


From duke at openjdk.org  Wed Mar  6 02:04:52 2024
From: duke at openjdk.org (duke)
Date: Wed, 6 Mar 2024 02:04:52 GMT
Subject: Withdrawn: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <nPsEwz_VDBFLVKKia0WQ1MpyveZdDV7q2yxtNmpKgp4=.320618f0-b5fe-46f8-9720-686d16c4b455@github.com>

On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/16424


From alanb at openjdk.org  Wed Mar  6 09:22:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 09:22:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
Message-ID: <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>

On Tue, 5 Mar 2024 22:44:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Many of these modules do not need native access in the current implementation.

In addition this will eventually need jlink support. I view the change to ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as very temporary. It may include many standard/JDK modules that aren't in the image. In addition we'll need some way to grant native access at link-time. The workaround for the latter right now is to configure default options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514113280


From fferrari at openjdk.org  Wed Mar  6 12:19:14 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 6 Mar 2024 12:19:14 GMT
Subject: RFR: 8319332: Security properties files inclusion [v7]
In-Reply-To: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
Message-ID: <U0V_tuSHumW7ClCkug-lAqz_F6sNrDVPwiXzV3IcwxY=.fd48ed90-6be4-41fe-8754-72c917fc10f6@github.com>

> The implementation of this proposal is based on the requirements, specification and design choices described in the [JDK-8319332] ticket and its respective CSR [JDK-8319333]. What follows are implementation notes organized per functional component, with the purpose of assisting to navigate the code changes in this pull-request.
> 
> ## Security properties loading (overview)
> 
> A new static class named `SecPropLoader` (nested within `java.security.Security`) is introduced to handle the loading of all security properties. Its method `loadAll` is the first one to be called, at `java.security.Security` static class initialization. The master security properties file is then loaded by `loadMaster`. When additional security properties files are allowed (the security property `security.overridePropertiesFile` is set to `true`) and the `java.security.properties` system property is passed, the method `loadExtra` handles the extra load.
> 
> The master properties file is loaded in `OVERRIDE` mode, meaning that the map of properties is originally empty. Any failure occurred while loading these properties is considered fatal. The extra properties file (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. Any failure in this case is ignored. This behavior maintains compatibility with the previous implementation.
> 
> While the `java.security.properties` system property is documented to accept an URL type of value, filesystem path values are supported in the same way that they were prior to this enhancement. Values are then interpreted as paths and, only if that fails, are considered URLs. In the latter case, there is one more attempt after opening the stream to check if there is a local file path underneath (e.g. the URL has the form of `file:///path/to/a/local/file`). The reason for preferring paths over URLs is to support relative path file inclusion in properties files.
> 
> ## Loading security properties from paths (`loadFromPath` method)
> 
> When loading a properties file from a path, the normalized file location is stored in the static field `currentPath`. This value is the current base to resolve any relative path encountered while handling an _include_ definition. Normalized paths are also saved in the `activePaths` set to detect recursive cycles. As we move down or up in the _includes_ stack, `currentPath` and `activePaths` values are updated.
> 
> ## Loading security properties from URLs (`loadFromUrl` method)
> 
> The extra properties file can be loaded from a URL. ...

Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge 'openjdk/master' into JDK-8319332
 - Merge 'openjdk/master' into JDK-8319332
   
   Conflict in ConfigFileTest.java solved by keeping our file, which had
   been previously adjusted.
   
   Commands:
     git merge upstream/master
     git restore --ours -- test/jdk/java/security/Security/ConfigFileTest.java
     git add test/jdk/java/security/Security/ConfigFileTest.java
     git merge --continue
 - 8319332: Adjust code for JDK-8319673 changes
   
   JDK-8319673: Few security tests ignore VM flags
   
   Next, we will merge the openjdk/master branch and ignore the conflict in
   this file.
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Update copyright and ConfigFileTest.java.
   
   Bump copyright year to 2024 in all the modified files.
   
   Remove leaked host name from children JVMs debug command.
   
   Extract Executor::addSystemPropertiesAsJvmArgs from Executor::execute
   and rename 'allJvmArgs' to 'command'. Also split class name and
   RUNNER_ARG addition to 'command' as two separated command.add() calls.
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - Merge 'openjdk/master' into JDK-8319332
 - 8319332: Fix corner-case regression with bash pipe
   
   Extra properties files provided through bash pipes used to work before
   this enhancement, restore their behaviour.
   
   Also take advantage to use Files::isRegularFile, Files::isDirectory and
   Files::exists APIs instead of converting from Path to File.
   
   Linux reproducers (sub-shell, stdin, and combination of both):
   
   java -XshowSettings:security:properties                      \
        -Djava.security.properties==<(echo name=value)          \
        -Djava.security.debug=properties -version
   
   echo name=value | java -XshowSettings:security:properties    \
        -Djava.security.properties==/dev/stdin                  \
        -Djava.security.debug=properties -version
   
   echo name=value | java -XshowSettings:security:properties    \
        -Djava.security.properties==<(echo include /dev/stdin)  \
        -Djava.security.debug=properties -version
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Remove wildcard imports, adjust test case
   
   Test case adjustments: add missing check in PropsFile::assertApplied(),
   and fix typo in FilesManager::handleRequest() method name.
   
   Also, add clarifying comments to Executor::assertSuccess() explaining
   how we use the special properties to make the assertion. Make 'lastFile'
   assignation latter, so it's separated from the first group of asserts.
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: use Path::of(URI) to deal with file URLs
   
   Instead of the previously introduced FileURLConnection::getFile(), use
   Path::of(URI), leaving some file URL corner-cases without relative
   imports support.
   
   Further details in https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Implement security properties 'include'
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - 8319332: Refactor security properties file test
   
   Co-authored-by: Martin Balao <mbalao at redhat.com>
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
 - ... and 1 more: https://git.openjdk.org/jdk/compare/fbb422ec...d414fd56

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

Changes: https://git.openjdk.org/jdk/pull/16483/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16483&range=06
  Stats: 1201 lines in 6 files changed: 965 ins; 165 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/16483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16483/head:pull/16483

PR: https://git.openjdk.org/jdk/pull/16483


From fferrari at openjdk.org  Wed Mar  6 14:58:47 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 6 Mar 2024 14:58:47 GMT
Subject: RFR: 8319332: Security properties files inclusion [v7]
In-Reply-To: <U0V_tuSHumW7ClCkug-lAqz_F6sNrDVPwiXzV3IcwxY=.fd48ed90-6be4-41fe-8754-72c917fc10f6@github.com>
References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com>
 <U0V_tuSHumW7ClCkug-lAqz_F6sNrDVPwiXzV3IcwxY=.fd48ed90-6be4-41fe-8754-72c917fc10f6@github.com>
Message-ID: <yRXe0cxiXe7uu_Eky9rGgeHyG3YLgep6MsdpeWmXrI8=.c5e10f43-1693-49cb-a66c-394ab091eab9@github.com>

On Wed, 6 Mar 2024 12:19:14 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> The implementation of this proposal is based on the requirements, specification and design choices described in the [JDK-8319332] ticket and its respective CSR [JDK-8319333]. What follows are implementation notes organized per functional component, with the purpose of assisting to navigate the code changes in this pull-request.
>> 
>> ## Security properties loading (overview)
>> 
>> A new static class named `SecPropLoader` (nested within `java.security.Security`) is introduced to handle the loading of all security properties. Its method `loadAll` is the first one to be called, at `java.security.Security` static class initialization. The master security properties file is then loaded by `loadMaster`. When additional security properties files are allowed (the security property `security.overridePropertiesFile` is set to `true`) and the `java.security.properties` system property is passed, the method `loadExtra` handles the extra load.
>> 
>> The master properties file is loaded in `OVERRIDE` mode, meaning that the map of properties is originally empty. Any failure occurred while loading these properties is considered fatal. The extra properties file (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. Any failure in this case is ignored. This behavior maintains compatibility with the previous implementation.
>> 
>> While the `java.security.properties` system property is documented to accept an URL type of value, filesystem path values are supported in the same way that they were prior to this enhancement. Values are then interpreted as paths and, only if that fails, are considered URLs. In the latter case, there is one more attempt after opening the stream to check if there is a local file path underneath (e.g. the URL has the form of `file:///path/to/a/local/file`). The reason for preferring paths over URLs is to support relative path file inclusion in properties files.
>> 
>> ## Loading security properties from paths (`loadFromPath` method)
>> 
>> When loading a properties file from a path, the normalized file location is stored in the static field `currentPath`. This value is the current base to resolve any relative path encountered while handling an _include_ definition. Normalized paths are also saved in the `activePaths` set to detect recursive cycles. As we move down or up in the _includes_ stack, `currentPath` and `activePaths` values are updated.
>> 
>> ## Loading security properties from URLs (`loadFromUrl` method)
>> 
>> The extra properti...
>
> Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge 'openjdk/master' into JDK-8319332
>  - Merge 'openjdk/master' into JDK-8319332
>    
>    Conflict in ConfigFileTest.java solved by keeping our file, which had
>    been previously adjusted.
>    
>    Commands:
>      git merge upstream/master
>      git restore --ours -- test/jdk/java/security/Security/ConfigFileTest.java
>      git add test/jdk/java/security/Security/ConfigFileTest.java
>      git merge --continue
>  - 8319332: Adjust code for JDK-8319673 changes
>    
>    JDK-8319673: Few security tests ignore VM flags
>    
>    Next, we will merge the openjdk/master branch and ignore the conflict in
>    this file.
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>  - 8319332: Update copyright and ConfigFileTest.java.
>    
>    Bump copyright year to 2024 in all the modified files.
>    
>    Remove leaked host name from children JVMs debug command.
>    
>    Extract Executor::addSystemPropertiesAsJvmArgs from Executor::execute
>    and rename 'allJvmArgs' to 'command'. Also split class name and
>    RUNNER_ARG addition to 'command' as two separated command.add() calls.
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>  - Merge 'openjdk/master' into JDK-8319332
>  - 8319332: Fix corner-case regression with bash pipe
>    
>    Extra properties files provided through bash pipes used to work before
>    this enhancement, restore their behaviour.
>    
>    Also take advantage to use Files::isRegularFile, Files::isDirectory and
>    Files::exists APIs instead of converting from Path to File.
>    
>    Linux reproducers (sub-shell, stdin, and combination of both):
>    
>    java -XshowSettings:security:properties                      \
>         -Djava.security.properties==<(echo name=value)          \
>         -Djava.security.debug=properties -version
>    
>    echo name=value | java -XshowSettings:security:properties    \
>         -Djava.security.properties==/dev/stdin                  \
>         -Djava.security.debug=properties -version
>    
>    echo name=value | java -XshowSettings:security:properties    \
>         -Djava.security.properties==<(echo include /dev/stdin)  \
>         -Djava.security.debug=properties -version
>    
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>    Co-authored-by: Francisco Ferrari Bihurriet...

NOTE: the only [checks failure](https://github.com/openjdk/jdk/pull/16483/checks?check_run_id=22343680786) is due to [JDK-8326960: GHA: RISC-V linux-cross-compile is failing](https://bugs.openjdk.org/browse/JDK-8326960).

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1981052288


From jlahoda at openjdk.org  Wed Mar  6 15:01:47 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Mar 2024 15:01:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <CQCdfDP6785EDomU2zdtqsi6DpyHYpnHo20Sucs7xPc=.58038e72-419c-40a5-a378-a7bd6b766809@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <CQCdfDP6785EDomU2zdtqsi6DpyHYpnHo20Sucs7xPc=.58038e72-419c-40a5-a378-a7bd6b766809@github.com>
Message-ID: <RGk0UCU1r30IQjKZ7qWruBHAB7xzmRCrCUCRslQ0Bss=.59b69ff9-efb2-4c3d-a4b8-e7ecedd25dde@github.com>

On Tue, 5 Mar 2024 13:58:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 817:
> 
>> 815:                 JLA.addEnableNativeAccessToAllUnnamed();
>> 816:             } else if (!JLA.addEnableNativeAccess(layer, name) && shouldWarn) {
>> 817:                 warnUnknownModule(ENABLE_NATIVE_ACCESS, name);
> 
> Should we instead warn irrespective of whether or not it's user configured native access module name or a module name configured in JDK's build configuration? Or are the build misconfiguration in the `NATIVE_ACCESS_MODULES` expected to be caught much earlier in some other place?

For normal "full" JDK build, all the modules with pre-set native access should be present, and the warning might make sense there. But, the user may jlink a smaller version of the platform, or use `--limit-modules`, and that may cause some of the modules are not present. So I don't think it is realistic to produce a warning here for the modules with pre-set native access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514633918


From jlahoda at openjdk.org  Wed Mar  6 15:04:46 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Mar 2024 15:04:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
 <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
Message-ID: <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>

On Wed, 6 Mar 2024 09:19:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Many of these modules do not need native access in the current implementation.   Should this list be trimmed to list the ones that need native access in the current implementation?
>
>> Many of these modules do not need native access in the current implementation.
> 
> In addition this will eventually need jlink support. I view the change to ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as very temporary. It may include many standard/JDK modules that aren't in the image. In addition we'll need some way to grant native access at link-time. The workaround for the latter right now is to configure default options.

> Many of these modules do not need native access in the current implementation. Should this list be trimmed to list the ones that need native access in the current implementation?

Not sure if I know enough to do the pruning, so I was hoping that could be done separately (I'd file a bug as Alan suggests). But I can try to prune the list, if you prefer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514640785


From coffeys at openjdk.org  Wed Mar  6 16:23:46 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 6 Mar 2024 16:23:46 GMT
Subject: RFR: 8051959: Option to print thread information in
 java.security.debug output
In-Reply-To: <_1TPuT-kRBpCXxgDfqUL376R44eoTEZhwQJjeawdu6k=.e11738ee-f115-4bd8-9d2c-e049d0f11e7f@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <_1TPuT-kRBpCXxgDfqUL376R44eoTEZhwQJjeawdu6k=.e11738ee-f115-4bd8-9d2c-e049d0f11e7f@github.com>
Message-ID: <MrwwWnOcLpfdBrIS27DAsKRE6TTTKmkmYyIwTwebJRY=.8b4fcdd6-3012-42c0-b69e-df64f281fbef@github.com>

On Fri, 1 Mar 2024 15:25:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> src/java.base/share/classes/sun/security/util/Debug.java line 294:
> 
>> 292:         if (printThreadDetails) {
>> 293:             retString = toHexString(Thread.currentThread().threadId()) + "|" +
>> 294:                     Thread.currentThread().getName() + "|" + formatCaller();
> 
> The thread ID is in decimal in the default string representation of thread, also other diagnostic features such as the new thread dump. So I think you want to change this to "#" + Thread.currentThread().threadId().

Thanks Alan. Today, the TLS `javax.net.debug` logging prints the thread ID in hex format. I was repeating behaviour seen from that impl. Having `java.security.debug` output in decimal and the other in hex would prove confusing. We could consider flipping both to decimal format in a follow on patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1514781274


From duke at openjdk.org  Wed Mar  6 16:55:47 2024
From: duke at openjdk.org (Bernd)
Date: Wed, 6 Mar 2024 16:55:47 GMT
Subject: RFR: 8051959: Option to print thread information in
 java.security.debug output
In-Reply-To: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
Message-ID: <AbKKxLxRUVjbDGugq1rBV7wWeUd4Erf08As5QUqdHic=.0fb38a71-b055-478d-bf18-ffe66b178b4f@github.com>

On Fri, 1 Mar 2024 15:13:49 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
> 
> examples:
> format without patch :
> 
> 
> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info included:
> 
> 
> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info and timestamp:
> 
> 
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
> 
> 
> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
> 
> current proposal is to keep the thread and timestamp information off (make it opt in)
> 
> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
> 
> e.g 
> 
> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
> 
> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.

src/java.base/share/classes/sun/security/util/Debug.java line 211:

> 209:     public void println()
> 210:     {
> 211:         System.err.println(prefix + ":");

While we are her we could switch to Platfom logger, that also removes the need for timestamps (and thread info)

src/java.base/share/classes/sun/security/util/Debug.java line 304:

> 302:     }
> 303: 
> 304:     // copied from sun/security/ssl/Utilities.java for now

Why own helper, string.format(%x) can build the whole string or call Long.toHexString() or toString(,16)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1514838307
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1514825407


From ihse at openjdk.org  Wed Mar  6 17:13:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 17:13:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <SIUFVO3RcgYnIay7F33-PfFy-T0zu3AbaG5uuWF6Bao=.35edf894-58de-47c1-9c74-79ec609e8425@github.com>

On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Build changes are ok.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1920357192


From ihse at openjdk.org  Wed Mar  6 17:13:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 17:13:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pR_tzy5Mm3VY2y4uJfeE8MxORUmVZ8yv_3fyFJvz-ho=.345d8490-f43b-4757-8ae7-ac0e353e4bd9@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
 <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
 <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>
 <qUywPUBxrFPqmBQt0CmeoIjDdY__AaxZ1RnqbqpKtxs=.19abd551-8a3b-40e0-a148-0701fbce0405@github.com>
 <pR_tzy5Mm3VY2y4uJfeE8MxORUmVZ8yv_3fyFJvz-ho=.345d8490-f43b-4757-8ae7-ac0e353e4bd9@github.com>
Message-ID: <XciX2jKt36bYzbEQzIIFFc2D0oOk_tPuMX3xPtZhn1g=.870478b8-a203-4074-92bb-c7672c74073d@github.com>

On Wed, 6 Mar 2024 00:56:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I believe we could technically reuse the list for boot/platform modules. But, the intent here is to provide more control over the modules with native access, not only being able to add to the list, but also remove from the list. So, to me, it seemed better to have an explicit list, from/to which we can remove/add modules easily.
>
> Hello Jan, my suggestion was based on a misunderstanding that NATIVE_ACCESS_MODULES is always a superset of boot and platform modules. What you currently have looks fine to me.

And also, for the record, the .conf files are supposed to be in a syntactical subset compatible with both bash and make syntax, so this would not have been possible anyway. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514865999


From mchung at openjdk.org  Wed Mar  6 18:02:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 6 Mar 2024 18:02:45 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
 <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
 <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>
Message-ID: <xeO5tMijH6YcZoYCcnK-pqtNSkS_23yM1wETU-kyLG8=.7be74845-5e39-409f-9498-29c9e9e48331@github.com>

On Wed, 6 Mar 2024 15:02:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> Many of these modules do not need native access in the current implementation.
>> 
>> In addition this will eventually need jlink support. I view the change to ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as very temporary. It may include many standard/JDK modules that aren't in the image. In addition we'll need some way to grant native access at link-time. The workaround for the latter right now is to configure default options.
>
>> Many of these modules do not need native access in the current implementation. Should this list be trimmed to list the ones that need native access in the current implementation?
> 
> Not sure if I know enough to do the pruning, so I was hoping that could be done separately (I'd file a bug as Alan suggests). But I can try to prune the list, if you prefer.

Native access is needed for modules which calls restricted methods [1].   AFAICT, java.base, java.desktop and jdk.incubator.vector use java.lang.foreign but I don't know if they call restricted methods or not.

https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/foreign/package-summary.html#restricted

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514932944


From alanb at openjdk.org  Wed Mar  6 19:02:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 19:02:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <xeO5tMijH6YcZoYCcnK-pqtNSkS_23yM1wETU-kyLG8=.7be74845-5e39-409f-9498-29c9e9e48331@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
 <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
 <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>
 <xeO5tMijH6YcZoYCcnK-pqtNSkS_23yM1wETU-kyLG8=.7be74845-5e39-409f-9498-29c9e9e48331@github.com>
Message-ID: <KGp6SKKepujiMeOiDiWGs__WZAYXZl_VjX8qyKNVkj8=.5a145d54-15dd-4724-af59-4306a4c7e5b9@github.com>

On Wed, 6 Mar 2024 18:00:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Native access is needed for modules which calls restricted methods [1].

In time, we'll need it for modules using JNI too. We can do this trimming in another PR to avoid Jan getting pulled into deeply.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514999868


From mchung at openjdk.org  Wed Mar  6 19:11:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 6 Mar 2024 19:11:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <KGp6SKKepujiMeOiDiWGs__WZAYXZl_VjX8qyKNVkj8=.5a145d54-15dd-4724-af59-4306a4c7e5b9@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
 <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
 <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>
 <xeO5tMijH6YcZoYCcnK-pqtNSkS_23yM1wETU-kyLG8=.7be74845-5e39-409f-9498-29c9e9e48331@github.com>
 <KGp6SKKepujiMeOiDiWGs__WZAYXZl_VjX8qyKNVkj8=.5a145d54-15dd-4724-af59-4306a4c7e5b9@github.com>
Message-ID: <QbcMhlKDpFc4WsFmv9Tp16btRZ4ySk0IWo5XYX9RTyQ=.5b7dd50c-8ec8-4f07-bda4-479712c5c661@github.com>

On Wed, 6 Mar 2024 19:00:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Native access is needed for modules which calls restricted methods [1].   AFAICT, java.base, java.desktop and jdk.incubator.vector use java.lang.foreign but I don't know if they call restricted methods or not.
>> 
>> https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/foreign/package-summary.html#restricted
>
>> Native access is needed for modules which calls restricted methods [1].
> 
> In time, we'll need it for modules using JNI too. We can do this trimming in another PR to avoid Jan getting pulled into deeply.

Doing it in another PR is fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515009659


From coffeys at openjdk.org  Wed Mar  6 20:10:49 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 6 Mar 2024 20:10:49 GMT
Subject: RFR: 8051959: Option to print thread information in
 java.security.debug output
In-Reply-To: <AbKKxLxRUVjbDGugq1rBV7wWeUd4Erf08As5QUqdHic=.0fb38a71-b055-478d-bf18-ffe66b178b4f@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <AbKKxLxRUVjbDGugq1rBV7wWeUd4Erf08As5QUqdHic=.0fb38a71-b055-478d-bf18-ffe66b178b4f@github.com>
Message-ID: <64bQgEGVm5pAfCuCLJZUIVqql17j9nzxmGBmSK4uGqc=.96e17201-61c2-406e-b8d4-4bdcef81be46@github.com>

On Wed, 6 Mar 2024 16:52:42 GMT, Bernd <duke at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> src/java.base/share/classes/sun/security/util/Debug.java line 211:
> 
>> 209:     public void println()
>> 210:     {
>> 211:         System.err.println(prefix + ":");
> 
> While we are her we could switch to Platfom logger, that also removes the need for timestamps (and thread info)

I'm thinking along the same lines. the` javax.net.debug` property (TLS) already allows the use of `System Logger`. I'd be interested to hear from anyone who uses that Logger, by passing no args to `javax.net.debug`.  No reason why this (java.security.debug) code couldn't be updated also. I'd like to do this in a follow on (hoping to backport this patch to LTS update releases)

I think the Logger experience could do with tweaking also - something I spoke briefly about at the recent OpenJDK Committers' Workshop in Brussels. One option might be a mechanism where the Logger `Level` can be dialed up and down remotely (e.g. jconsole). I've been looking at this with the  `PlatformLoggingMXBean.setLoggerLevel `operation.

> src/java.base/share/classes/sun/security/util/Debug.java line 304:
> 
>> 302:     }
>> 303: 
>> 304:     // copied from sun/security/ssl/Utilities.java for now
> 
> Why own helper, string.format(%x) can build the whole string or call Long.toHexString() or toString(,16)?

I was emulating what's done for the TLS logging code. Yes  - I'll look at using a JDK library method instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1515092699
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1515082479


From mondain at gmail.com  Wed Mar  6 20:36:51 2024
From: mondain at gmail.com (Mondain)
Date: Wed, 6 Mar 2024 12:36:51 -0800
Subject: Hello fellow devs!
Message-ID: <CAHQq8QJTYjF727+Kxn0gbmG9usdx7j-0kABBx77cMwaQ+goXLQ@mail.gmail.com>

I'm here to inquire primarily about DTLS. I'm looking all over to find
out how to add extensions on both client and server ends; I especially
need to add use_srtp since I'm updating a WebRTC supporting server. In
addition I'd like to know how to be notified in the receiving logic
when the handshake messages arrive so that I can consume items like
the extended_master_secret. Any suggestions or examples are
appreciated. My current source implementation is based on this example
from OpenJDK https://cr.openjdk.org/%7Easmotrak/8159416/webrev.08/test/javax/net/ssl/DTLS/DTLSOverDatagram.java.html


-- 
Paul Gregoire
about.me/mondain


From jlahoda at openjdk.org  Wed Mar  6 21:16:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Mar 2024 21:16:25 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v3]
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
 - Reflecting review feedback.
 - Updating copyright headers.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18106/files
  - new: https://git.openjdk.org/jdk/pull/18106/files/6127044d..e30e4529

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18106&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18106&range=01-02

  Stats: 36 lines in 9 files changed: 11 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18106.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18106/head:pull/18106

PR: https://git.openjdk.org/jdk/pull/18106


From jlahoda at openjdk.org  Wed Mar  6 21:25:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Mar 2024 21:25:00 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
Message-ID: <N8fFio6sYBUPAleJmOsMnImlJNVyrxsMvnNqtiUzXaA=.dba56111-be6f-4b13-a996-3b1acd626a19@github.com>

On Tue, 5 Mar 2024 18:54:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/ModuleLayer.java line 896:
> 
>> 894:         return nameToModule.get(name);
>> 895:     }
>> 896: 
> 
> What would you think about replacing this with addEnableNativeAccess(String name) so it can be called by JLA. addEnableNativeAccess. The reason is that the JLA methods are usually just calls to some non-public method but the changes mean mean there is "core" in the JLA method that is not easy to find.

I've tried to that here:
https://github.com/openjdk/jdk/pull/18106/commits/e17cd3722724cbc6aa298f7b789c6574554af6ea

> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 812:
> 
>> 810:     }
>> 811: 
>> 812:     private static void addEnableNativeAccess(ModuleLayer layer, Set<String> moduleNames, boolean shouldWarn) {
> 
> The private methods in this class have a short comment to summarise what they do.

I've tried to add a comment here:
https://github.com/openjdk/jdk/pull/18106/commits/e17cd3722724cbc6aa298f7b789c6574554af6ea

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515171359
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515171099


From duke at openjdk.org  Wed Mar  6 21:58:53 2024
From: duke at openjdk.org (MustavData)
Date: Wed, 6 Mar 2024 21:58:53 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <m4XUgexOnhJwQn-SNIxYIYr-DV1ouwzLqAa96cUTjL0=.5fc1f78a-5e50-46c7-8148-58514f4fd726@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <m4XUgexOnhJwQn-SNIxYIYr-DV1ouwzLqAa96cUTjL0=.5fc1f78a-5e50-46c7-8148-58514f4fd726@github.com>
Message-ID: <dhH8HuomqsinKHEUwDTYAy16NcIArvcbTkr7HxL7lDI=.81299d9a-91f5-4470-9353-2bf71355f616@github.com>

On Mon, 4 Mar 2024 23:55:50 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> For clarification I've edited the comment in the JBS issue, replacing "feature request" with "enhancement" so that it properly matches the terminology used in JBS.

@macarte :   Thank you for the clarification.  But why do you think this issue should be an Enhancement?  It appears to be a minor scope, high impact defect that would block an application from production deployment.

Omission of a secure environment test for security Enhancement [JDK-6782021](https://bugs.openjdk.org/browse/JDK-6782021) could not have been intentional.  Its underlying requirement, like a lock on a car door, is implicit.  And, even if the fix is broader than the elegant change proposed by @rebarbora-mckvak, a documentation change should be unnecessary.

Given the threat of forgery, security around code signing is not optional.  Windows can be part of a secure platform for activities such as this, but not when applications leave issues like this unresolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1981871397


From duke at openjdk.org  Wed Mar  6 22:15:54 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Wed, 6 Mar 2024 22:15:54 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <5cJn7RPySlJrZUKghJfOz1f4V0QKOmFNB-YsCkY9Tqw=.e71ba4a9-6e1e-4019-91e1-d8bb16311062@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

I have encountered a related problem on my customer's system. Depending on how private keys are imported in the store, either `signCngHash` or `signHash` is used. `signHash` fails to find the key, because it does not look at local machine's store. I will commit a fix for that soon in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1981903052


From alanb at openjdk.org  Thu Mar  7 09:36:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 09:36:54 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v3]
In-Reply-To: <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
Message-ID: <bRjHFpQGmLDFi0kRP_ciClevcZZ1QfvRdCjaqiP3nLw=.57aad825-beca-401e-af14-87a641fb756c@github.com>

On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
>  - Reflecting review feedback.
>  - Updating copyright headers.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/lang/ModuleLayer.java line 891:

> 889:      *         {@code false} otherwise
> 890:      */
> 891:     boolean addEnableNativeAccess(String name) {

Do you mind changing the method description to "Updates the module with the given name in this layer to allow access to restricted methods"? This will be keep it more consistent with the exiting methods.

Also "was present" in the return description hints that it may not now be present. A module layer is immutable so it can just say that it returns true if the  module is in this layer.

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

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1921919290
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515834537


From alanb at openjdk.org  Thu Mar  7 09:36:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 09:36:55 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <N8fFio6sYBUPAleJmOsMnImlJNVyrxsMvnNqtiUzXaA=.dba56111-be6f-4b13-a996-3b1acd626a19@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <N8fFio6sYBUPAleJmOsMnImlJNVyrxsMvnNqtiUzXaA=.dba56111-be6f-4b13-a996-3b1acd626a19@github.com>
Message-ID: <dtV1dHFyE5Reo9dkH7Z82kUZsNYtflxITZL0sexuQvQ=.5cd0ce0e-3acd-4ae5-bbbe-d0e79d3a3ed8@github.com>

On Wed, 6 Mar 2024 21:22:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 812:
>> 
>>> 810:     }
>>> 811: 
>>> 812:     private static void addEnableNativeAccess(ModuleLayer layer, Set<String> moduleNames, boolean shouldWarn) {
>> 
>> The private methods in this class have a short comment to summarise what they do.
>
> I've tried to add a comment here:
> https://github.com/openjdk/jdk/pull/18106/commits/e17cd3722724cbc6aa298f7b789c6574554af6ea

Thanks. I view these changes to ModuleBootstrap to be temporary. We'll need to create a few follow on issues in JBS, one of which is to update jlink so that we have the exact set of modules in the run-time image that have been granted native access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515838474


From dfuchs at openjdk.org  Thu Mar  7 10:12:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 7 Mar 2024 10:12:55 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
 <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
 <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>
Message-ID: <o903TWvm-n5rqeKURwyNYxtab9UPMSrTwyMUgLWBk-A=.31cb42ae-4aa2-43fc-bb4e-27b00b6ba891@github.com>

On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> 
>> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
>> https://github.com/openjdk/jdk/pull/18025 )
>> 
>> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
>> 
>> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.
>
> I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.
> 
> I?ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.
> 
> Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

Yes - the JMX implementation stores and retrieve subjects in the AccessControlContext and then uses doPrivileged. Subject.doAs is not used in the JMX implementation.

There are two different uses of Subject in JMX: 

1. one is a simplified role-based authentication/authorization at the default agent level. 
2. The other one is a permission check where different subjects can be granted different privileges in the policy file. 

The latter will go away since the SM is going away, but needs to be preserved until then.
The former we want to keep and needs to keep working (by changing the code to use callAs) even after the SM is gone.

Subject delegation allows an authenticated subject (1. above) to perform actions on behalf of a delegation subject, where the privileged granted by 2. are the intersection of the privileges of the two subjects.
@kevinjwalls is currently working on removing subject delegation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1515896397


From coffeys at openjdk.org  Thu Mar  7 11:57:07 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 7 Mar 2024 11:57:07 GMT
Subject: RFR: 8051959: Option to print thread information in
 java.security.debug output [v2]
In-Reply-To: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
Message-ID: <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>

> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
> 
> examples:
> format without patch :
> 
> 
> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info included:
> 
> 
> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info and timestamp:
> 
> 
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
> 
> 
> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
> 
> current proposal is to keep the thread and timestamp information off (make it opt in)
> 
> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
> 
> e.g 
> 
> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
> 
> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  use default hex output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18084/files
  - new: https://git.openjdk.org/jdk/pull/18084/files/b679e568..d89308b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=00-01

  Stats: 21 lines in 1 file changed: 1 ins; 18 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18084/head:pull/18084

PR: https://git.openjdk.org/jdk/pull/18084


From alanb at openjdk.org  Thu Mar  7 12:19:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 12:19:53 GMT
Subject: RFR: 8051959: Option to print thread information in
 java.security.debug output [v2]
In-Reply-To: <MrwwWnOcLpfdBrIS27DAsKRE6TTTKmkmYyIwTwebJRY=.8b4fcdd6-3012-42c0-b69e-df64f281fbef@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <_1TPuT-kRBpCXxgDfqUL376R44eoTEZhwQJjeawdu6k=.e11738ee-f115-4bd8-9d2c-e049d0f11e7f@github.com>
 <MrwwWnOcLpfdBrIS27DAsKRE6TTTKmkmYyIwTwebJRY=.8b4fcdd6-3012-42c0-b69e-df64f281fbef@github.com>
Message-ID: <C1KU-0xlnNhVvkh7ls4F5byCA4ToisMptT_N-gRF-J8=.72608abc-3b25-4fa6-afe4-8c968a0d22f7@github.com>

On Wed, 6 Mar 2024 16:20:43 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Debug.java line 294:
>> 
>>> 292:         if (printThreadDetails) {
>>> 293:             retString = toHexString(Thread.currentThread().threadId()) + "|" +
>>> 294:                     Thread.currentThread().getName() + "|" + formatCaller();
>> 
>> The thread ID is in decimal in the default string representation of thread, also other diagnostic features such as the new thread dump. So I think you want to change this to "#" + Thread.currentThread().threadId().
>
> Thanks Alan. Today, the TLS `javax.net.debug` logging prints the thread ID in hex format. I was repeating behaviour seen from that impl. Having `java.security.debug` output in decimal and the other in hex would prove confusing. We could consider flipping both to decimal format in a follow on patch.

Change it here, or in a later PR is okay. Main thing is that the logs are confusing then the Thread string is "#<id>" but the TLS debug logs are different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1516059694


From peter.firmstone at zeus.net.au  Thu Mar  7 12:35:13 2024
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 7 Mar 2024 22:35:13 +1000
Subject: =?UTF-8?Q?Re=3A_RFR=3A_8296244=3A_Alternate_implementation_of_user-?=
 =?UTF-8?Q?based_authorization_Subject_APIs_that_doesn=E2=80=99t_depend_on_S?=
 =?UTF-8?Q?ecurity_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
Message-ID: <591f9c2d-3b42-4cff-9534-5ea13c00d206@zeus.net.au>

Good Evening,

Just noticed the comment below, this is a breaking change.

Recalling earlier discussions on this list about the removal of the 
existing Authorization API post JEP411, it was going to be assigned 
another overarching JEP.

Can we have the entire API destructed in one swift action? That is, all 
API marked for removal under JEP411 should now throw 
UnsupportedOperationException? Keeping the API around as unsupported 
operation would also allow us to maintain a fork where the API remains 
functional, without breaking compile time compatibility with Java, while 
we figure out how to migrate our software over the longer term.

Thank you for retaining Java's Authorization API in Java 21 LTS.

Regards,

Peter.

>>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240307/570d169d/attachment.htm>

From djelinski at openjdk.org  Thu Mar  7 12:40:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 7 Mar 2024 12:40:09 GMT
Subject: RFR: 8325164: Named groups and signature schemes unavailable with
 SunPKCS11 in FIPS mode [v2]
In-Reply-To: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
References: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
Message-ID: <k-Z3z2anZtsVOjA_cwnmBIvT7eDRktrIP44aAzEkIIg=.fe038e66-6ce9-4331-92e7-fa09ef8c8333@github.com>

> Currently the SunPKCS11 provider requires other providers in order to offer ECDHE, FFDHE and RSA-PSS in TLS handshakes:
> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
> - ECDHE requires the SunEC provider to be installed
> - RSA-PSS requires RSASSA-PSS AlgorithmParameters from SunRsaSign
> 
> This PR removes these dependencies: 
> - SunPKCS11 is modified to offer the PSS and DH AlgorithmParameters (using the same implementation classes as the original providers)
> - Elliptic curve code is modified to remove the dependency on SunEC provider where possible
> 
> Two existing tests were modified to verify the changes:
> - SigInteropPSS2 test was modified to install SunPKCS11 provider and remove SunRsaSign provider
> - FipsModeTLS12 test was modified to verify the list of NamedGroups available on a SSLEngine.
> 
> Both modified tests fail without the changes, pass with them. Other tier1-3 tests continue to pass.

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

  Restore original SunEC behavior

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17816/files
  - new: https://git.openjdk.org/jdk/pull/17816/files/9dfb2fc7..09ac283d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17816&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17816&range=00-01

  Stats: 68 lines in 3 files changed: 40 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17816.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17816/head:pull/17816

PR: https://git.openjdk.org/jdk/pull/17816


From djelinski at openjdk.org  Thu Mar  7 13:28:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 7 Mar 2024 13:28:53 GMT
Subject: RFR: 8325164: Named groups and signature schemes unavailable with
 SunPKCS11 in FIPS mode [v2]
In-Reply-To: <k-Z3z2anZtsVOjA_cwnmBIvT7eDRktrIP44aAzEkIIg=.fe038e66-6ce9-4331-92e7-fa09ef8c8333@github.com>
References: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
 <k-Z3z2anZtsVOjA_cwnmBIvT7eDRktrIP44aAzEkIIg=.fe038e66-6ce9-4331-92e7-fa09ef8c8333@github.com>
Message-ID: <ePbsLpztyORFLKr-UYlxVV2r3Z7svlCOo7ziwyc9Us0=.08e6f7ed-0cb0-4b62-af1e-7e8991e732f8@github.com>

On Thu, 7 Mar 2024 12:40:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently the SunPKCS11 provider requires other providers in order to offer ECDHE, FFDHE and RSA-PSS in TLS handshakes:
>> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
>> - ECDHE requires the SunEC provider to be installed
>> - RSA-PSS requires RSASSA-PSS AlgorithmParameters from SunRsaSign
>> 
>> This PR removes these dependencies: 
>> - SunPKCS11 is modified to offer the PSS and DH AlgorithmParameters (using the same implementation classes as the original providers)
>> - Elliptic curve code is modified to remove the dependency on SunEC provider where possible
>> 
>> Two existing tests were modified to verify the changes:
>> - SigInteropPSS2 test was modified to install SunPKCS11 provider and remove SunRsaSign provider
>> - FipsModeTLS12 test was modified to verify the list of NamedGroups available on a SSLEngine.
>> 
>> Both modified tests fail without the changes, pass with them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore original SunEC behavior

After an offline discussion I pushed an alternative implementation that restores the original SunEC provider behavior of resolving ECParameterSpec using the preferred EC AlgorithmParameters provider.

I also modified SunPKCS11 provider to use the preferred provider instead of using SunEC if it's installed, and failing if SunEC is not installed. SunPKCS11 provides EC AlgorithmParameters, so as long as it is installed, ECParameterSpec resolution will work.

History: the dependency on SunEC provider was introduced in [JDK-7194075](https://bugs.openjdk.org/browse/JDK-7194075) / c39030c7b32ae529699aec3d5bde197b194771a7 to remove duplication of code between SunPKCS11 and SunEC.

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

PR Comment: https://git.openjdk.org/jdk/pull/17816#issuecomment-1983501685


From pkumaraswamy at openjdk.org  Thu Mar  7 13:36:54 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Thu, 7 Mar 2024 13:36:54 GMT
Subject: RFR: 8312383: Log X509ExtendedKeyManager implementation class name
 in TLS/SSL connection [v2]
In-Reply-To: <8MmQ5TjiSC4kgS1fnxNDVetKWHRJtL7z2mGqyW7jSlU=.dfa25656-67e5-4bec-984f-e9e3f5784ebd@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
 <8MmQ5TjiSC4kgS1fnxNDVetKWHRJtL7z2mGqyW7jSlU=.dfa25656-67e5-4bec-984f-e9e3f5784ebd@github.com>
Message-ID: <XaCVLSF-WzFL73UPEk590aervcbusKBp7rFb8cUwk2c=.2a9a3b0e-2522-4187-bc69-e7e022cd6fe9@github.com>

On Thu, 8 Feb 2024 09:11:14 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

>> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
>> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
>> 
>> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
>> The screen shots are attached here.
>> [x509_log_testing.zip](https://github.com/openjdk/jdk/files/14206695/x509_log_testing.zip)
>> 
>> Also, the internal test runs against this fix are green
>
> Prajwal Kumaraswamy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add log for client auth
>  - Merge remote-tracking branch 'origin/master' into JDK-8312383
>  - 8312383: Improve SSL debug log

Adding comment to avoid auto closure of PR

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

PR Comment: https://git.openjdk.org/jdk/pull/17742#issuecomment-1983520161


From sean.mullan at oracle.com  Thu Mar  7 15:31:59 2024
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 7 Mar 2024 10:31:59 -0500
Subject: =?UTF-8?Q?Re=3A_RFR=3A_8296244=3A_Alternate_implementation_of_user-?=
 =?UTF-8?Q?based_authorization_Subject_APIs_that_doesn=E2=80=99t_depend_on_S?=
 =?UTF-8?Q?ecurity_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <591f9c2d-3b42-4cff-9534-5ea13c00d206@zeus.net.au>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
 <591f9c2d-3b42-4cff-9534-5ea13c00d206@zeus.net.au>
Message-ID: <80aa16c5-f389-4f78-a71e-e5c909550e44@oracle.com>

On 3/7/24 7:35 AM, Peter Firmstone wrote:
> Good Evening,
> 
> Just noticed the comment below, this is a breaking change.
> 
> Recalling earlier discussions on this list about the removal of the 
> existing Authorization API post JEP411, it was going to be assigned 
> another overarching JEP.

Yes that JEP is eventually coming in the near future.

> Can we have the entire API destructed in one swift action? That is, all 
> API marked for removal under JEP411 should now throw 
> UnsupportedOperationException? Keeping the API around as unsupported 
> operation would also allow us to maintain a fork where the API remains 
> functional, without breaking compile time compatibility with Java, while 
> we figure out how to migrate our software over the longer term.

The next major step is to remove support for the Security Manager (SM) 
from the JDK. However, the deprecated for removal APIs will not be 
removed as part of that - they will be retained and removed at some 
later time. Some APIs will be degraded to throw 
UnsupportedOperationException but others (such as 
AccessController.doPrivileged) will be degraded to behave as if an SM 
had not been enabled.

JAAS is a special case in that it has dependencies on the deprecated SM 
APIs for uses cases that don't always require the SM to be enabled. 
Thus, as described in JEP 411, we introduced new replacement APIs 
(Subject.callAs and Subject.current) in JDK 18 (4 releases ago). 
Applications depending on JAAS for authentication or authorization cases 
that do not require an SM should be migrating to these replacement APIs.

--Sean

> 
> Thank you for retaining Java's Authorization API in Java 21 LTS.
> 
> Regards,
> 
> Peter.
> 
>>>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.


From mullan at openjdk.org  Thu Mar  7 15:12:18 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 7 Mar 2024 15:12:18 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v4]
In-Reply-To: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
Message-ID: <XOqtCCn-ggSJlKO7UQCYX-PgIVNnq--U55whcbQ_-P0=.8346bbfd-813a-4fd1-ae4b-a71ef12ba4c9@github.com>

> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
> 
> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
> 
> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Weijun's comments.
 - Merge
 - Fix whitespace error. Improve debugging. Change return value of distanceToCommonAncestor().
 - Add more comments. Remove unnecessary import.
 - Fix whitespace.
 - Update copyrights.
 - Merge
 - Simplify and improve performance of PKIXCertComparator.
 - Regression test.
 - Use shared secrets instead of reflection.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/fdb17ad8...20b714dd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17248/files
  - new: https://git.openjdk.org/jdk/pull/17248/files/7a91821b..20b714dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17248&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17248&range=02-03

  Stats: 208166 lines in 4462 files changed: 72796 ins; 106611 del; 28759 mod
  Patch: https://git.openjdk.org/jdk/pull/17248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17248/head:pull/17248

PR: https://git.openjdk.org/jdk/pull/17248


From dfuchs at openjdk.org  Thu Mar  7 16:23:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 7 Mar 2024 16:23:55 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v2]
In-Reply-To: <qZT8DM9L1qa1D5rjytsaM_DHvcwDxBF6nASsf4tP5-s=.33bcdec4-3247-425c-af95-3242e52315ed@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <qZT8DM9L1qa1D5rjytsaM_DHvcwDxBF6nASsf4tP5-s=.33bcdec4-3247-425c-af95-3242e52315ed@github.com>
Message-ID: <WUG1PNfEVBM6Dv4ubnScVukcOKVLJ83O8YLZ9rivIXE=.aace1cc1-04f8-4605-adcd-afb4bfa0c2d7@github.com>

On Sat, 2 Mar 2024 13:51:04 GMT, Korov <duke at openjdk.org> wrote:

>> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
>> 
>> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
>> 
>> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.
>
> Korov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modiy the code accordingto the review

Changes requested by dfuchs (Reviewer).

Changes requested by dfuchs (Reviewer).

src/java.base/share/classes/java/net/SocketPermission.java line 230:

> 228:     private transient int[] portrange;
> 229: 
> 230:     private transient boolean defaultDeny = false;

This is used by internal whitebox test. Please revert this change.

src/java.base/share/classes/java/net/SocketPermission.java line 305:

> 303:     }
> 304: 
> 305:     private void setDeny() {

This method is used in internal whitebox tests - please revert this change

src/java.base/share/classes/java/net/SocketPermission.java line 622:

> 620:         try {
> 621:             if (!trustNameService && (defaultDeny ||
> 622:                 sun.net.www.URLConnection.isProxiedHost(hostname))) {

This is important for some internal whitebox test. Please revert this change.

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

PR Review: https://git.openjdk.org/jdk/pull/18086#pullrequestreview-1922908361
PR Review: https://git.openjdk.org/jdk/pull/18086#pullrequestreview-1922920954
PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1516455295
PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1516447605
PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1516450866


From duke at openjdk.org  Thu Mar  7 16:53:22 2024
From: duke at openjdk.org (Korov)
Date: Thu, 7 Mar 2024 16:53:22 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v3]
In-Reply-To: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
Message-ID: <i3p1LKWttRYZoHuednrI7xs4cWWoeB8gJdTVfahPGAE=.fb40909c-d43d-4379-9521-b71cc168b90b@github.com>

> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
> 
> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
> 
> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.

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

  revert change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18086/files
  - new: https://git.openjdk.org/jdk/pull/18086/files/9ebd6e12..e8c948a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18086&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18086&range=01-02

  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18086.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18086/head:pull/18086

PR: https://git.openjdk.org/jdk/pull/18086


From duke at openjdk.org  Thu Mar  7 16:56:56 2024
From: duke at openjdk.org (Korov)
Date: Thu, 7 Mar 2024 16:56:56 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v3]
In-Reply-To: <WUG1PNfEVBM6Dv4ubnScVukcOKVLJ83O8YLZ9rivIXE=.aace1cc1-04f8-4605-adcd-afb4bfa0c2d7@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <qZT8DM9L1qa1D5rjytsaM_DHvcwDxBF6nASsf4tP5-s=.33bcdec4-3247-425c-af95-3242e52315ed@github.com>
 <WUG1PNfEVBM6Dv4ubnScVukcOKVLJ83O8YLZ9rivIXE=.aace1cc1-04f8-4605-adcd-afb4bfa0c2d7@github.com>
Message-ID: <z4bKoVRP92SGlffZtUtR-S9ZqIkDtFJV8QemnhfIx1Q=.6f5f023d-d8b9-4460-9b5c-677fd66df233@github.com>

On Thu, 7 Mar 2024 16:21:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This is used by internal whitebox test. Please revert this change.

Reverted.

> src/java.base/share/classes/java/net/SocketPermission.java line 305:
> 
>> 303:     private void setDeny() {
>> 304:         defaultDeny = true;
>> 305:     }
> 
> This method is used in internal whitebox tests - please revert this change

The method had been reverted.

> This is important for some internal whitebox test. Please revert this change.

Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1516510850
PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1516509391
PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1516510305


From hchao at openjdk.org  Thu Mar  7 17:13:18 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 7 Mar 2024 17:13:18 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe
Message-ID: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>

Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!

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

Commit messages:
 - 8327461: KeyStore getEntry is not thread-safe

Changes: https://git.openjdk.org/jdk/pull/18156/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327461
  Stats: 177 lines in 2 files changed: 161 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/18156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18156/head:pull/18156

PR: https://git.openjdk.org/jdk/pull/18156


From aturbanov at openjdk.org  Thu Mar  7 17:14:58 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 7 Mar 2024 17:14:58 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v3]
In-Reply-To: <z4bKoVRP92SGlffZtUtR-S9ZqIkDtFJV8QemnhfIx1Q=.6f5f023d-d8b9-4460-9b5c-677fd66df233@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <qZT8DM9L1qa1D5rjytsaM_DHvcwDxBF6nASsf4tP5-s=.33bcdec4-3247-425c-af95-3242e52315ed@github.com>
 <WUG1PNfEVBM6Dv4ubnScVukcOKVLJ83O8YLZ9rivIXE=.aace1cc1-04f8-4605-adcd-afb4bfa0c2d7@github.com>
 <z4bKoVRP92SGlffZtUtR-S9ZqIkDtFJV8QemnhfIx1Q=.6f5f023d-d8b9-4460-9b5c-677fd66df233@github.com>
Message-ID: <z1rJes-hM_rxILgpJDLAZRG2RBTzD5_4Q9wADWYGouQ=.643f5476-a6fa-468a-aa9a-8f2a6f0ecf45@github.com>

On Thu, 7 Mar 2024 16:53:05 GMT, Korov <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/SocketPermission.java line 305:
>> 
>>> 303:     private void setDeny() {
>>> 304:         defaultDeny = true;
>>> 305:     }
>> 
>> This method is used in internal whitebox tests - please revert this change
>
> The method had been reverted.

do you which test uses this method? I wasn't able to find it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18086#discussion_r1516535013


From hchao at openjdk.org  Thu Mar  7 17:20:08 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 7 Mar 2024 17:20:08 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v2]
In-Reply-To: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
Message-ID: <M0izFFyinXWlyU_YRATm3R_RIyCP5wj-NzHp411GzBA=.52a40647-8fd4-474f-82d5-ccb46e01ec7c@github.com>

> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update bug number in the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18156/files
  - new: https://git.openjdk.org/jdk/pull/18156/files/44862602..97bf0ece

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/18156


From sean.mullan at oracle.com  Thu Mar  7 21:06:44 2024
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 7 Mar 2024 16:06:44 -0500
Subject: Hello fellow devs!
In-Reply-To: <CAHQq8QJTYjF727+Kxn0gbmG9usdx7j-0kABBx77cMwaQ+goXLQ@mail.gmail.com>
References: <CAHQq8QJTYjF727+Kxn0gbmG9usdx7j-0kABBx77cMwaQ+goXLQ@mail.gmail.com>
Message-ID: <7a12cac1-2758-4955-b095-10683acdec46@oracle.com>

Hi,

Thanks for your interest in Java Security but this list is not for help 
with code and questions about using the APIs. I suggest you check 
various forums on Java and Java Security for more assistance on your 
questions.

Thanks,
Sean

On 3/6/24 3:36 PM, Mondain wrote:
> I'm here to inquire primarily about DTLS. I'm looking all over to find
> out how to add extensions on both client and server ends; I especially
> need to add use_srtp since I'm updating a WebRTC supporting server. In
> addition I'd like to know how to be notified in the receiving logic
> when the handshake messages arrive so that I can consume items like
> the extended_master_secret. Any suggestions or examples are
> appreciated. My current source implementation is based on this example
> from OpenJDK https://cr.openjdk.org/%7Easmotrak/8159416/webrev.08/test/javax/net/ssl/DTLS/DTLSOverDatagram.java.html
> 
> 


From lancea at openjdk.org  Thu Mar  7 21:19:56 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 7 Mar 2024 21:19:56 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v3]
In-Reply-To: <JwZxCNT0ulu-RLMOQ5P65OG5cR5QjqzOKtJ-rMswuTY=.f1ec3dff-081b-4485-b8e7-f580a4709ff6@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <JwZxCNT0ulu-RLMOQ5P65OG5cR5QjqzOKtJ-rMswuTY=.f1ec3dff-081b-4485-b8e7-f580a4709ff6@github.com>
Message-ID: <G6gWV5IS1LXkZFgE3Vg9248Q3qTlxof-kZgQaH_4Cg4=.c9a35e27-8bb9-432c-9783-4eaadb9213a8@github.com>

On Sat, 3 Feb 2024 17:28:29 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s 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 six additional commits since the last revision:
> 
>  - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
>  - For clarity, use "externalFileAttributes" instead of "externalAttributes"
>  - Merge branch 'master' into zipentry-external-attributes
>  - Update copyright years for 2024
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-1923567034


From weijun at openjdk.org  Thu Mar  7 21:27:53 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 7 Mar 2024 21:27:53 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v2]
In-Reply-To: <M0izFFyinXWlyU_YRATm3R_RIyCP5wj-NzHp411GzBA=.52a40647-8fd4-474f-82d5-ccb46e01ec7c@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <M0izFFyinXWlyU_YRATm3R_RIyCP5wj-NzHp411GzBA=.52a40647-8fd4-474f-82d5-ccb46e01ec7c@github.com>
Message-ID: <TUCFVu3_TE6CiYgMBk5ZzHiU91znxhjExfYtrua4v70=.5c7ce51a-e09c-4895-8880-81e42b7e3fc9@github.com>

On Thu, 7 Mar 2024 17:20:08 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug number in the test

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1346:

> 1344:                 char[] password = pp.getPassword();
> 1345: 
> 1346:                 Key key = internalGetKey(entry, password);

This is a very smart change to use the already retrieved `entry` object to avoid it being replaced. There are other places in this method that `alias` is used to retrieve other info -- like `engineIsCertificateEntry(alias)` and `engineIsKeyEntry(alias)`. They should be also modified to depend on `entry` only. Ideally, `entries.get(alias)` (or any method that calls it) should only appear once in every `alias`-related method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1516849094


From weijun at openjdk.org  Thu Mar  7 21:30:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 7 Mar 2024 21:30:58 GMT
Subject: RFR: 8317431: Implement simpler Comparator when building
 certification paths [v4]
In-Reply-To: <XOqtCCn-ggSJlKO7UQCYX-PgIVNnq--U55whcbQ_-P0=.8346bbfd-813a-4fd1-ae4b-a71ef12ba4c9@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
 <XOqtCCn-ggSJlKO7UQCYX-PgIVNnq--U55whcbQ_-P0=.8346bbfd-813a-4fd1-ae4b-a71ef12ba4c9@github.com>
Message-ID: <RdTSN65tBot6ZGiu4A18DvyTj4ekoFjH8lIc4quEHr4=.54b1e6ec-8fdd-4368-a52a-ed6a3a13fcbb@github.com>

On Thu, 7 Mar 2024 15:12:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
>> 
>> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
>> 
>> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
>> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
>> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
>> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Weijun's comments.
>  - Merge
>  - Fix whitespace error. Improve debugging. Change return value of distanceToCommonAncestor().
>  - Add more comments. Remove unnecessary import.
>  - Fix whitespace.
>  - Update copyrights.
>  - Merge
>  - Simplify and improve performance of PKIXCertComparator.
>  - Regression test.
>  - Use shared secrets instead of reflection.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/cf6239b6...20b714dd

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17248#pullrequestreview-1829985213


From mcimadamore at openjdk.org  Thu Mar  7 21:46:55 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Mar 2024 21:46:55 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v3]
In-Reply-To: <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
Message-ID: <1C8Qw4DoYVjv_b73GmWY6EA_UrcqogbRWlqfAeVjepA=.46aa205b-9202-4e8c-bf3d-b6e638b0135d@github.com>

On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
>  - Reflecting review feedback.
>  - Updating copyright headers.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1923612749


From mondain at gmail.com  Thu Mar  7 21:51:07 2024
From: mondain at gmail.com (Mondain)
Date: Thu, 7 Mar 2024 13:51:07 -0800
Subject: Fwd: Hello fellow devs!
In-Reply-To: <CAHQq8QJTYjF727+Kxn0gbmG9usdx7j-0kABBx77cMwaQ+goXLQ@mail.gmail.com>
References: <CAHQq8QJTYjF727+Kxn0gbmG9usdx7j-0kABBx77cMwaQ+goXLQ@mail.gmail.com>
Message-ID: <CAHQq8QLHDxEcMQM7ops9+7okNNLOVMpRgLN9ueeKy+q62kYOrw@mail.gmail.com>

Thanks for replying, maybe you can point me in the right direction? So
far none of the docs cover what I need; I feel like I'm being forced
to use BouncyCastle or find something else, when I'd rather stay in
the JDK/JSSE domain. Filed bugs with regard to DTLS are sitting for
years. Unless otherwise shown, the outlook is not good.

--
<https://about.me/mondain?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb>
Paul Gregoire
about.me/mondain
<https://about.me/mondain?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240307/3b29b75d/attachment.htm>

From jlahoda at openjdk.org  Thu Mar  7 21:53:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Mar 2024 21:53:07 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v4]
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adjusting javadoc as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18106/files
  - new: https://git.openjdk.org/jdk/pull/18106/files/e30e4529..6af399ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18106&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18106&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/18106


From jlahoda at openjdk.org  Thu Mar  7 21:53:08 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Mar 2024 21:53:08 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v3]
In-Reply-To: <bRjHFpQGmLDFi0kRP_ciClevcZZ1QfvRdCjaqiP3nLw=.57aad825-beca-401e-af14-87a641fb756c@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
 <bRjHFpQGmLDFi0kRP_ciClevcZZ1QfvRdCjaqiP3nLw=.57aad825-beca-401e-af14-87a641fb756c@github.com>
Message-ID: <Xhzv0NgCzdvlZ1vROhcFfPu9CBPpAyDKoukDE5cHTOc=.0b44fab2-eef9-4908-9104-1b2653e4147f@github.com>

On Thu, 7 Mar 2024 09:30:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
>>  - Reflecting review feedback.
>>  - Updating copyright headers.
>
> src/java.base/share/classes/java/lang/ModuleLayer.java line 891:
> 
>> 889:      *         {@code false} otherwise
>> 890:      */
>> 891:     boolean addEnableNativeAccess(String name) {
> 
> Do you mind changing the method description to "Updates the module with the given name in this layer to allow access to restricted methods"? This will be keep it more consistent with the exiting methods.
> 
> Also "was present" in the return description hints that it may not now be present. A module layer is immutable so it can just say that it returns true if the  module is in this layer.

Adjusted here:
https://github.com/openjdk/jdk/pull/18106/commits/6af399ee4a3e908cb7c6b983b9747310e23a888e
please let me know if further/other changes/adjustment are desirable.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1516878109


From peter.firmstone at zeus.net.au  Thu Mar  7 22:31:34 2024
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 8 Mar 2024 08:31:34 +1000
Subject: =?utf-8?Q?Re:_RFR:_8296244:_Alternate_implementation_of_user-bas?=
 =?utf-8?Q?ed_authorization_Subject_APIs_that_doesn=E2=80=99t_dep?=
 =?utf-8?Q?end_on_Security_Manager_APIs_[v3]?=
In-Reply-To: <80aa16c5-f389-4f78-a71e-e5c909550e44@oracle.com>
References: <80aa16c5-f389-4f78-a71e-e5c909550e44@oracle.com>
Message-ID: <7E5BB809-581F-4B73-8692-A5393C10FF8A@zeus.net.au>


Sent from my iPhone

> On 8 Mar 2024, at 1:35?am, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> ?On 3/7/24 7:35 AM, Peter Firmstone wrote:
>> Good Evening,
>> Just noticed the comment below, this is a breaking change.
>> Recalling earlier discussions on this list about the removal of the existing Authorization API post JEP411, it was going to be assigned another overarching JEP.
> 
> Yes that JEP is eventually coming in the near future.
> 
>> Can we have the entire API destructed in one swift action? That is, all API marked for removal under JEP411 should now throw UnsupportedOperationException? Keeping the API around as unsupported operation would also allow us to maintain a fork where the API remains functional, without breaking compile time compatibility with Java, while we figure out how to migrate our software over the longer term.
> 
> The next major step is to remove support for the Security Manager (SM) from the JDK. However, the deprecated for removal APIs will not be removed as part of that - they will be retained and removed at some later time. Some APIs will be degraded to throw UnsupportedOperationException but others (such as AccessController.doPrivileged) will be degraded to behave as if an SM had not been enabled.
> 
> JAAS is a special case in that it has dependencies on the deprecated SM APIs for uses cases that don't always require the SM to be enabled. Thus, as described in JEP 411, we introduced new replacement APIs (Subject.callAs and Subject.current) in JDK 18 (4 releases ago). Applications depending on JAAS for authentication or authorization cases that do not require an SM should be migrating to these replacement APIs themselves.
> 
> --Sean

Should, when possible.  Our software is deeply integrated with the deprecated Authorization API, we've determined it's not possible.  Our only choice is to fork, so I'd definitely prefer the API to remain.  Also if functionality can be removed rather than degraded, that will make it easier to patch in replacement functionality. 

Thank you,

Peter.




> 
>> Thank you for retaining Java's Authorization API in Java 21 LTS.
>> Regards,
>> Peter.
>>>>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.



From hchao at openjdk.org  Thu Mar  7 23:13:14 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 7 Mar 2024 23:13:14 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v3]
In-Reply-To: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
Message-ID: <w0VO_JINXhymXUpxiI809ssAaF4X6uNg1eqixgRVjdA=.c9d5e7fa-3dd0-4f07-9237-3fb55ec1fd6d@github.com>

> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update engineIsKeyEntry and engineIsCertificateEntry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18156/files
  - new: https://git.openjdk.org/jdk/pull/18156/files/97bf0ece..5390a426

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=01-02

  Stats: 13 lines in 1 file changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18156/head:pull/18156

PR: https://git.openjdk.org/jdk/pull/18156


From hchao at openjdk.org  Thu Mar  7 23:13:14 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 7 Mar 2024 23:13:14 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v2]
In-Reply-To: <TUCFVu3_TE6CiYgMBk5ZzHiU91znxhjExfYtrua4v70=.5c7ce51a-e09c-4895-8880-81e42b7e3fc9@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <M0izFFyinXWlyU_YRATm3R_RIyCP5wj-NzHp411GzBA=.52a40647-8fd4-474f-82d5-ccb46e01ec7c@github.com>
 <TUCFVu3_TE6CiYgMBk5ZzHiU91znxhjExfYtrua4v70=.5c7ce51a-e09c-4895-8880-81e42b7e3fc9@github.com>
Message-ID: <vD2Oz9dHaWESAnlUzjHqKlnapQ-A0uzDP0hXp-ZdoMI=.509ad133-a2f4-4ab5-a653-c3bcb9863a71@github.com>

On Thu, 7 Mar 2024 21:22:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update bug number in the test
>
> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1346:
> 
>> 1344:                 char[] password = pp.getPassword();
>> 1345: 
>> 1346:                 Key key = internalGetKey(entry, password);
> 
> This is a very smart change to use the already retrieved `entry` object to avoid it being replaced. There are other places in this method that `alias` is used to retrieve other info -- like `engineIsCertificateEntry(alias)` and `engineIsKeyEntry(alias)`. They should be also modified to depend on `entry` only. Ideally, `entries.get(alias)` (or any method that calls it) should only appear once in every `alias`-related method.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1516962177


From peter.firmstone at zeus.net.au  Thu Mar  7 23:30:50 2024
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 8 Mar 2024 09:30:50 +1000
Subject: =?UTF-8?Q?Re=3A_RFR=3A_8296244=3A_Alternate_implementation_of_user-?=
 =?UTF-8?Q?based_authorization_Subject_APIs_that_doesn=E2=80=99t_depend_on_S?=
 =?UTF-8?Q?ecurity_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <7E5BB809-581F-4B73-8692-A5393C10FF8A@zeus.net.au>
References: <80aa16c5-f389-4f78-a71e-e5c909550e44@oracle.com>
 <7E5BB809-581F-4B73-8692-A5393C10FF8A@zeus.net.au>
Message-ID: <c396877f-3cc9-45eb-805c-9db9208b1484@zeus.net.au>

Can this change be documented along with others planned in the new JEP 
so these changes are easier to track?

There's no mention of this change in the bug id.

We've placed all future development on hold in software that depends on 
Java's Authorization API, (apart from bug fixes), while we figure out 
how to manage changes brought about by JEP411.

Thank you.

Peter.

On 8/03/2024 8:31 am, Peter Firmstone wrote:
> Sent from my iPhone
>
>> On 8 Mar 2024, at 1:35?am, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> ?On 3/7/24 7:35 AM, Peter Firmstone wrote:
>>> Good Evening,
>>> Just noticed the comment below, this is a breaking change.
>>> Recalling earlier discussions on this list about the removal of the existing Authorization API post JEP411, it was going to be assigned another overarching JEP.
>> Yes that JEP is eventually coming in the near future.
>>
>>> Can we have the entire API destructed in one swift action? That is, all API marked for removal under JEP411 should now throw UnsupportedOperationException? Keeping the API around as unsupported operation would also allow us to maintain a fork where the API remains functional, without breaking compile time compatibility with Java, while we figure out how to migrate our software over the longer term.
>> The next major step is to remove support for the Security Manager (SM) from the JDK. However, the deprecated for removal APIs will not be removed as part of that - they will be retained and removed at some later time. Some APIs will be degraded to throw UnsupportedOperationException but others (such as AccessController.doPrivileged) will be degraded to behave as if an SM had not been enabled.
>>
>> JAAS is a special case in that it has dependencies on the deprecated SM APIs for uses cases that don't always require the SM to be enabled. Thus, as described in JEP 411, we introduced new replacement APIs (Subject.callAs and Subject.current) in JDK 18 (4 releases ago). Applications depending on JAAS for authentication or authorization cases that do not require an SM should be migrating to these replacement APIs themselves.
>>
>> --Sean
> Should, when possible.  Our software is deeply integrated with the deprecated Authorization API, we've determined it's not possible.  Our only choice is to fork, so I'd definitely prefer the API to remain.  Also if functionality can be removed rather than degraded, that will make it easier to patch in replacement functionality.
>
> Thank you,
>
> Peter.
>
>
>
>
>>> Thank you for retaining Java's Authorization API in Java 21 LTS.
>>> Regards,
>>> Peter.
>>>>>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.


From weijun at openjdk.org  Fri Mar  8 00:16:52 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Mar 2024 00:16:52 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v3]
In-Reply-To: <w0VO_JINXhymXUpxiI809ssAaF4X6uNg1eqixgRVjdA=.c9d5e7fa-3dd0-4f07-9237-3fb55ec1fd6d@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <w0VO_JINXhymXUpxiI809ssAaF4X6uNg1eqixgRVjdA=.c9d5e7fa-3dd0-4f07-9237-3fb55ec1fd6d@github.com>
Message-ID: <I6Rohstit0SpxEmkqboLPu8pONMbRYT-sD8K1_KEUE0=.cac32e22-6b51-4b0c-95b4-3017017a472c@github.com>

On Thu, 7 Mar 2024 23:13:14 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update engineIsKeyEntry and engineIsCertificateEntry

The delete method also uses alias twice. In fact, the remove method of a map already returns the object.

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

PR Comment: https://git.openjdk.org/jdk/pull/18156#issuecomment-1984821539


From jjiang at openjdk.org  Fri Mar  8 03:54:54 2024
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 8 Mar 2024 03:54:54 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v3]
In-Reply-To: <w0VO_JINXhymXUpxiI809ssAaF4X6uNg1eqixgRVjdA=.c9d5e7fa-3dd0-4f07-9237-3fb55ec1fd6d@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <w0VO_JINXhymXUpxiI809ssAaF4X6uNg1eqixgRVjdA=.c9d5e7fa-3dd0-4f07-9237-3fb55ec1fd6d@github.com>
Message-ID: <hF5RkOYaF1CiHB1TtQ7PN01ehfYVLk5L6ewT_nV6GUU=.a4e0e0a4-1ea1-412a-b9fe-675b56c14a26@github.com>

On Thu, 7 Mar 2024 23:13:14 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update engineIsKeyEntry and engineIsCertificateEntry

Should method `engineEntryInstanceOf` be also concerned?

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

PR Comment: https://git.openjdk.org/jdk/pull/18156#issuecomment-1984994917


From pkumaraswamy at openjdk.org  Fri Mar  8 06:12:11 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Fri, 8 Mar 2024 06:12:11 GMT
Subject: RFR: 8312383: Log X509ExtendedKeyManager implementation class name
 in TLS/SSL connection [v3]
In-Reply-To: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
Message-ID: <jO9OCcYH_0HrTfuwQrqFKt9InRu1lsoOZiIqen_9zUM=.1481609b-d686-4460-a171-4870c6e90157@github.com>

> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
> 
> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
> The screen shots are attached here.
> [x509_log_testing.zip](https://github.com/openjdk/jdk/files/14206695/x509_log_testing.zip)
> 
> Also, the internal test runs against this fix are green

Prajwal Kumaraswamy 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 six additional commits since the last revision:

 - change log message
 - Merge remote-tracking branch 'origin/master' into JDK-8312383
 - Merge remote-tracking branch 'origin/master' into JDK-8312383
 - Add log for client auth
 - Merge remote-tracking branch 'origin/master' into JDK-8312383
 - 8312383: Improve SSL debug log

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17742/files
  - new: https://git.openjdk.org/jdk/pull/17742/files/bd8449bd..bb0a54e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17742&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17742&range=01-02

  Stats: 125185 lines in 2742 files changed: 27138 ins; 86267 del; 11780 mod
  Patch: https://git.openjdk.org/jdk/pull/17742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17742/head:pull/17742

PR: https://git.openjdk.org/jdk/pull/17742


From pkumaraswamy at openjdk.org  Fri Mar  8 06:12:12 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Fri, 8 Mar 2024 06:12:12 GMT
Subject: RFR: 8312383: Log X509ExtendedKeyManager implementation class name
 in TLS/SSL connection [v2]
In-Reply-To: <8MmQ5TjiSC4kgS1fnxNDVetKWHRJtL7z2mGqyW7jSlU=.dfa25656-67e5-4bec-984f-e9e3f5784ebd@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
 <8MmQ5TjiSC4kgS1fnxNDVetKWHRJtL7z2mGqyW7jSlU=.dfa25656-67e5-4bec-984f-e9e3f5784ebd@github.com>
Message-ID: <3lr6Dq8uNARWkmMOFmfg8GYaaJTkZZvMYeM2yHIJV1M=.2a464f7d-0172-4231-8b26-391be40aae47@github.com>

On Thu, 8 Feb 2024 09:11:14 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

>> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
>> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
>> 
>> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
>> The screen shots are attached here.
>> [x509_log_testing.zip](https://github.com/openjdk/jdk/files/14206695/x509_log_testing.zip)
>> 
>> Also, the internal test runs against this fix are green
>
> Prajwal Kumaraswamy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add log for client auth
>  - Merge remote-tracking branch 'origin/master' into JDK-8312383
>  - 8312383: Improve SSL debug log

I have tested the latest changes and attached is the snapshot
[x509kmprintlogs_v3.zip](https://github.com/openjdk/jdk/files/14534015/x509kmprintlogs_v3.zip)

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

PR Comment: https://git.openjdk.org/jdk/pull/17742#issuecomment-1985095504


From pkumaraswamy at openjdk.org  Fri Mar  8 06:12:12 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Fri, 8 Mar 2024 06:12:12 GMT
Subject: RFR: 8312383: Log X509ExtendedKeyManager implementation class name
 in TLS/SSL connection [v3]
In-Reply-To: <ZtBxseoBjP4DEhqppmQpUGB2fmGGta74NsezFm_Kv-A=.00508fa7-8aeb-4b83-98ba-4d08d2adf49d@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
 <9JdCwKOWBdW4oBqwVbjQbDdexepvokVGuk7-yb02jzk=.e6bd9c32-23d7-41c5-9ff7-a9f01c06ac1c@github.com>
 <0gxlpmwKCNsek-I3DTVBtsFOXixxCTtHSg4UBUYrOcg=.364f5af5-9fdb-412f-96b7-01f136382ae0@github.com>
 <ZtBxseoBjP4DEhqppmQpUGB2fmGGta74NsezFm_Kv-A=.00508fa7-8aeb-4b83-98ba-4d08d2adf49d@github.com>
Message-ID: <H-9tia7tERE6QmRkntq5hhDEcmFrnTFc1BcTYjo_j0o=.49a5e7de-7bda-4e83-9b03-a8ffdc7eb5cd@github.com>

On Thu, 8 Feb 2024 09:13:18 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

>> I have changed the title to reflect the specific change made here.
>> I'll make changes in createServerPossession as well.
>
> I have made changes and attached the testing snapshots in a zip file attached in bug description

I have made changes to log statement

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17742#discussion_r1517204567


From djelinski1 at gmail.com  Fri Mar  8 07:47:14 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Fri, 8 Mar 2024 08:47:14 +0100
Subject: Hello fellow devs!
In-Reply-To: <CAHQq8QLHDxEcMQM7ops9+7okNNLOVMpRgLN9ueeKy+q62kYOrw@mail.gmail.com>
References: <CAHQq8QJTYjF727+Kxn0gbmG9usdx7j-0kABBx77cMwaQ+goXLQ@mail.gmail.com>
 <CAHQq8QLHDxEcMQM7ops9+7okNNLOVMpRgLN9ueeKy+q62kYOrw@mail.gmail.com>
Message-ID: <CAMrH03J7g7TQhrm7K9V6cNQ-wb23=f1Sqz0+VHEgy5EGrPKLCA@mail.gmail.com>

Hi Paul,
If you're interested in dealing with handshake extensions from user code,
that is currently not possible. SSLEngine abstracts away all TLS messaging.
SSLParameters can be used to configure a limited subset of extensions to
send (like server_name or application protocol), and the negotiated
application protocol can be retrieved from SSLEngine, and that's pretty
much it.

Use_srtp extension is not currently supported by JSSE. If you want to add
that support, you'd need to add the appropriate enum values to
sun.security.ssl.SSLExtension, using the constructors that specify a
producer and a consumer. I'm not familiar with WebRTC or SRTP, so I don't
know how that would interact with the rest of the code.

If you have an idea how WebRTC / SRTP support could be implemented in JSSE,
this is the right place for that discussion.

Regards,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240308/e2b4d6e1/attachment.htm>

From Alan.Bateman at oracle.com  Fri Mar  8 07:52:15 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 8 Mar 2024 07:52:15 +0000
Subject: =?UTF-8?Q?Re=3A_RFR=3A_8296244=3A_Alternate_implementation_of_user-?=
 =?UTF-8?Q?based_authorization_Subject_APIs_that_doesn=E2=80=99t_depend_on_S?=
 =?UTF-8?Q?ecurity_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <c396877f-3cc9-45eb-805c-9db9208b1484@zeus.net.au>
References: <80aa16c5-f389-4f78-a71e-e5c909550e44@oracle.com>
 <7E5BB809-581F-4B73-8692-A5393C10FF8A@zeus.net.au>
 <c396877f-3cc9-45eb-805c-9db9208b1484@zeus.net.au>
Message-ID: <4a1b959c-8310-463d-9eeb-4b876cc5d7a2@oracle.com>

On 07/03/2024 23:30, Peter Firmstone wrote:
> Can this change be documented along with others planned in the new JEP 
> so these changes are easier to track?

As Sean said, JEP 411 already links to JDK-8267108 that introduced 
Subject.current/callAs methods as the replacements for getSubject/doAs.

But yes, the future JEP for removal of the security manager will likely 
cover many areas, including the changes to Subject that are in the API 
for some time.

-Alan


From coffeys at openjdk.org  Fri Mar  8 08:05:55 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 8 Mar 2024 08:05:55 GMT
Subject: RFR: 8312383: Log X509ExtendedKeyManager implementation class name
 in TLS/SSL connection [v3]
In-Reply-To: <jO9OCcYH_0HrTfuwQrqFKt9InRu1lsoOZiIqen_9zUM=.1481609b-d686-4460-a171-4870c6e90157@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
 <jO9OCcYH_0HrTfuwQrqFKt9InRu1lsoOZiIqen_9zUM=.1481609b-d686-4460-a171-4870c6e90157@github.com>
Message-ID: <Oxq5t7waQ3mbUKpudgfRsjqhaveHjZNvlt_ktVpQqJA=.76586d6c-4354-4d0e-9548-3cd3f6f4648f@github.com>

On Fri, 8 Mar 2024 06:12:11 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

>> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
>> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
>> 
>> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
>> The screen shots are attached here.
>> [x509_log_testing.zip](https://github.com/openjdk/jdk/files/14206695/x509_log_testing.zip)
>> 
>> Also, the internal test runs against this fix are green
>
> Prajwal Kumaraswamy 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 six additional commits since the last revision:
> 
>  - change log message
>  - Merge remote-tracking branch 'origin/master' into JDK-8312383
>  - Merge remote-tracking branch 'origin/master' into JDK-8312383
>  - Add log for client auth
>  - Merge remote-tracking branch 'origin/master' into JDK-8312383
>  - 8312383: Improve SSL debug log

Looks good.

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17742#pullrequestreview-1924296052


From alanb at openjdk.org  Fri Mar  8 08:08:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Mar 2024 08:08:55 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v4]
In-Reply-To: <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>
Message-ID: <tV4-kylrA3ztHguo975Tt-s-FslkJ2v5v3e3SDXFstE=.3a194eef-ed88-40f2-bcd5-86b36ae10e60@github.com>

On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting javadoc as suggested.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1924302699


From peter.firmstone at zeus.net.au  Fri Mar  8 08:20:06 2024
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 8 Mar 2024 18:20:06 +1000
Subject: =?UTF-8?Q?Re=3A_RFR=3A_8296244=3A_Alternate_implementation_of_user-?=
 =?UTF-8?Q?based_authorization_Subject_APIs_that_doesn=E2=80=99t_depend_on_S?=
 =?UTF-8?Q?ecurity_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <4a1b959c-8310-463d-9eeb-4b876cc5d7a2@oracle.com>
References: <80aa16c5-f389-4f78-a71e-e5c909550e44@oracle.com>
 <7E5BB809-581F-4B73-8692-A5393C10FF8A@zeus.net.au>
 <c396877f-3cc9-45eb-805c-9db9208b1484@zeus.net.au>
 <4a1b959c-8310-463d-9eeb-4b876cc5d7a2@oracle.com>
Message-ID: <e6931bf6-49b8-4da8-bffb-646543d8ac49@zeus.net.au>

JDK-8267108 doesn't mention any existing getSubject/doAs methods will be 
changed to throw UnsupportedOperationException, would be great if that 
can be documented as well, if I hadn't seen the change in the mailing 
list I would have missed it.?? Just helps track related changes.

Thanks,

Peter.


On 8/03/2024 5:52 pm, Alan Bateman wrote:
> On 07/03/2024 23:30, Peter Firmstone wrote:
>> Can this change be documented along with others planned in the new 
>> JEP so these changes are easier to track?
>
> As Sean said, JEP 411 already links to JDK-8267108 that introduced 
> Subject.current/callAs methods as the replacements for getSubject/doAs.
>
> But yes, the future JEP for removal of the security manager will 
> likely cover many areas, including the changes to Subject that are in 
> the API for some time.
>
> -Alan


From hchao at openjdk.org  Fri Mar  8 08:22:21 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 8 Mar 2024 08:22:21 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v4]
In-Reply-To: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
Message-ID: <hEFCxcsFdCZ4kXaecRgxSRVzri9xFzkJA1OQc4B7TWo=.0f07a199-3107-482c-940e-c1d51297f063@github.com>

> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update engineDeleteEntry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18156/files
  - new: https://git.openjdk.org/jdk/pull/18156/files/5390a426..68c68af2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=02-03

  Stats: 17 lines in 1 file changed: 7 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18156/head:pull/18156

PR: https://git.openjdk.org/jdk/pull/18156


From hchao at openjdk.org  Fri Mar  8 08:27:53 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 8 Mar 2024 08:27:53 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v4]
In-Reply-To: <hEFCxcsFdCZ4kXaecRgxSRVzri9xFzkJA1OQc4B7TWo=.0f07a199-3107-482c-940e-c1d51297f063@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <hEFCxcsFdCZ4kXaecRgxSRVzri9xFzkJA1OQc4B7TWo=.0f07a199-3107-482c-940e-c1d51297f063@github.com>
Message-ID: <-z5ZqQ1VJJZ8ykBFqywqKDb2uC1kuFWMXEGWvyPUuNE=.418b6078-f359-4b75-96ff-dd52d0aa5299@github.com>

On Fri, 8 Mar 2024 08:22:21 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update engineDeleteEntry

engineEntryInstanceOf has only one direct access to the entries map. After obtaining the entry object, its type is checked against the specified entryClass, which do not involve accessing the entries map again.

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

PR Comment: https://git.openjdk.org/jdk/pull/18156#issuecomment-1985254087


From Alan.Bateman at oracle.com  Fri Mar  8 08:36:14 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 8 Mar 2024 08:36:14 +0000
Subject: =?UTF-8?Q?Re=3A_RFR=3A_8296244=3A_Alternate_implementation_of_user-?=
 =?UTF-8?Q?based_authorization_Subject_APIs_that_doesn=E2=80=99t_depend_on_S?=
 =?UTF-8?Q?ecurity_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <e6931bf6-49b8-4da8-bffb-646543d8ac49@zeus.net.au>
References: <80aa16c5-f389-4f78-a71e-e5c909550e44@oracle.com>
 <7E5BB809-581F-4B73-8692-A5393C10FF8A@zeus.net.au>
 <c396877f-3cc9-45eb-805c-9db9208b1484@zeus.net.au>
 <4a1b959c-8310-463d-9eeb-4b876cc5d7a2@oracle.com>
 <e6931bf6-49b8-4da8-bffb-646543d8ac49@zeus.net.au>
Message-ID: <6a1a6845-ddba-469e-a7d2-3ab8b040b1f5@oracle.com>

On 08/03/2024 08:20, Peter Firmstone wrote:
> JDK-8267108 doesn't mention any existing getSubject/doAs methods will 
> be changed to throw UnsupportedOperationException, would be great if 
> that can be documented as well, if I hadn't seen the change in the 
> mailing list I would have missed it.?? Just helps track related changes.

The warning at compile time that the API is deprecated for removal 
should help when compiling with recent JDK releases.

When JDK-8267108 introduced new/replacement APIs then the 
details/time-line for when the old/problematic APIs would be degraded 
was not known.

JDK 23 (or whatever release the current change goes into) will have 
documentation on the change in the release.

-Alan


From djelinski at openjdk.org  Fri Mar  8 08:56:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Mar 2024 08:56:53 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v4]
In-Reply-To: <hEFCxcsFdCZ4kXaecRgxSRVzri9xFzkJA1OQc4B7TWo=.0f07a199-3107-482c-940e-c1d51297f063@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <hEFCxcsFdCZ4kXaecRgxSRVzri9xFzkJA1OQc4B7TWo=.0f07a199-3107-482c-940e-c1d51297f063@github.com>
Message-ID: <SaofHO2BFHTzEeIDSEqpIR1urgIlUjP7TfERcgAnXuk=.68bb3e72-fdb1-4124-8922-68c6dafdf305@github.com>

On Fri, 8 Mar 2024 08:22:21 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update engineDeleteEntry

Very nice improvement. Thank you!

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1331:

> 1329:             if (internalEngineIsCertificateEntry(entry)) {
> 1330:                 if (entry instanceof CertEntry &&
> 1331:                     ((CertEntry) entry).trustedKeyUsage != null) {

`internalEngineIsCertificateEntry` performs exactly the same checks; you can remove these lines.

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1368:

> 1366:                         entry.attributes);
> 1367:                 }
> 1368:             } else if (!internalEngineIsKeyEntry(entry)) {

Suggestion:

            } else {


(the matching `if` already checks `internalEngineIsKeyEntry(entry)`)

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

PR Review: https://git.openjdk.org/jdk/pull/18156#pullrequestreview-1924367027
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1517406770
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1517411548


From pkumaraswamy at openjdk.org  Fri Mar  8 09:07:02 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Fri, 8 Mar 2024 09:07:02 GMT
Subject: Integrated: 8312383: Log X509ExtendedKeyManager implementation class
 name in TLS/SSL connection
In-Reply-To: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
Message-ID: <_r2b8SxG-3YpzN0rfhpVLdmSqbRW_6wG4aobvXZ6lCM=.0d1d4391-a471-4e08-9a44-0a88abed352b@github.com>

On Wed, 7 Feb 2024 06:36:10 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
> 
> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
> The screen shots are attached here.
> [x509_log_testing.zip](https://github.com/openjdk/jdk/files/14206695/x509_log_testing.zip)
> 
> Also, the internal test runs against this fix are green

This pull request has now been integrated.

Changeset: bdd1aebe
Author:    Prajwal Kumaraswamy <pkumaraswamy at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdd1aebea379b63ae405827074530ef8e8a7c239
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8312383: Log X509ExtendedKeyManager implementation class name in TLS/SSL connection

Reviewed-by: coffeys

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

PR: https://git.openjdk.org/jdk/pull/17742


From hchao at openjdk.org  Fri Mar  8 09:22:13 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 8 Mar 2024 09:22:13 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v5]
In-Reply-To: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
Message-ID: <OPhTecq-CE8960Muz-RZbEyYoRvzni-x6kQIAdjPgUM=.1944cdb9-956f-4063-9121-7f93e3bb841d@github.com>

> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  remove unneeded checks in engineGetEntry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18156/files
  - new: https://git.openjdk.org/jdk/pull/18156/files/68c68af2..15220c6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=03-04

  Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18156/head:pull/18156

PR: https://git.openjdk.org/jdk/pull/18156


From hchao at openjdk.org  Fri Mar  8 09:22:13 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 8 Mar 2024 09:22:13 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v4]
In-Reply-To: <SaofHO2BFHTzEeIDSEqpIR1urgIlUjP7TfERcgAnXuk=.68bb3e72-fdb1-4124-8922-68c6dafdf305@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <hEFCxcsFdCZ4kXaecRgxSRVzri9xFzkJA1OQc4B7TWo=.0f07a199-3107-482c-940e-c1d51297f063@github.com>
 <SaofHO2BFHTzEeIDSEqpIR1urgIlUjP7TfERcgAnXuk=.68bb3e72-fdb1-4124-8922-68c6dafdf305@github.com>
Message-ID: <C9tKi1ZcZA0m1NpHkz9AywpMdvbkesr5I3nayeKjPew=.0b4bc30f-7f76-4489-b83b-60962e8b62c9@github.com>

On Fri, 8 Mar 2024 08:42:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update engineDeleteEntry
>
> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1331:
> 
>> 1329:             if (internalEngineIsCertificateEntry(entry)) {
>> 1330:                 if (entry instanceof CertEntry &&
>> 1331:                     ((CertEntry) entry).trustedKeyUsage != null) {
> 
> `internalEngineIsCertificateEntry` performs exactly the same checks; you can remove these lines.

Removed.

> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1368:
> 
>> 1366:                         entry.attributes);
>> 1367:                 }
>> 1368:             } else if (!internalEngineIsKeyEntry(entry)) {
> 
> Suggestion:
> 
>             } else {
> 
> 
> (the matching `if` already checks `internalEngineIsKeyEntry(entry)`)

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1517455306
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1517454736


From djelinski at openjdk.org  Fri Mar  8 09:24:54 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Mar 2024 09:24:54 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v5]
In-Reply-To: <OPhTecq-CE8960Muz-RZbEyYoRvzni-x6kQIAdjPgUM=.1944cdb9-956f-4063-9121-7f93e3bb841d@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <OPhTecq-CE8960Muz-RZbEyYoRvzni-x6kQIAdjPgUM=.1944cdb9-956f-4063-9121-7f93e3bb841d@github.com>
Message-ID: <KFrYlcJoNVqZTKad-7TY-SRE4DUAPSwUu-XtB5gSsl8=.7b715296-f95e-48e2-9149-66ac506f4697@github.com>

On Fri, 8 Mar 2024 09:22:13 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unneeded checks in engineGetEntry

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18156#pullrequestreview-1924445608


From eirbjo at openjdk.org  Fri Mar  8 09:34:05 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 8 Mar 2024 09:34:05 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16952/files
  - new: https://git.openjdk.org/jdk/pull/16952/files/10db9803..243887b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/16952


From thp at westhawk.co.uk  Fri Mar  8 09:56:16 2024
From: thp at westhawk.co.uk (Tim Panton)
Date: Fri, 8 Mar 2024 09:56:16 +0000
Subject: [SPAM] Hello fellow devs!
In-Reply-To: <CAMrH03J7g7TQhrm7K9V6cNQ-wb23=f1Sqz0+VHEgy5EGrPKLCA@mail.gmail.com>
References: <CAHQq8QJTYjF727+Kxn0gbmG9usdx7j-0kABBx77cMwaQ+goXLQ@mail.gmail.com>
 <CAHQq8QLHDxEcMQM7ops9+7okNNLOVMpRgLN9ueeKy+q62kYOrw@mail.gmail.com>
 <CAMrH03J7g7TQhrm7K9V6cNQ-wb23=f1Sqz0+VHEgy5EGrPKLCA@mail.gmail.com>
Message-ID: <EF13927E-BA3C-4656-96EB-2EC2CE741A0F@westhawk.co.uk>



> On 8 Mar 2024, at 07:47, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
> 
> Hi Paul,
> If you're interested in dealing with handshake extensions from user code, that is currently not possible. SSLEngine abstracts away all TLS messaging. SSLParameters can be used to configure a limited subset of extensions to send (like server_name or application protocol), and the negotiated application protocol can be retrieved from SSLEngine, and that's pretty much it.
> 
> Use_srtp extension is not currently supported by JSSE. If you want to add that support, you'd need to add the appropriate enum values to sun.security.ssl.SSLExtension, using the constructors that specify a producer and a consumer. I'm not familiar with WebRTC or SRTP, so I don't know how that would interact with the rest of the code.
> 
> If you have an idea how WebRTC / SRTP support could be implemented in JSSE, this is the right place for that discussion.
> 
> Regards,
> Daniel

Daniel, hi, following up on Paul?s question? 

I've done an integration with BouncyCastle DTLS API with WebRTC?s SRTP (and indirectly paid for the api to exist), here?s what I remember was needed:

1) Ability to inject and receive DTLS packets via a socket-like interface
	- WebRTC muxes several protocols onto the same 5tuple ports so we need to manage the packet traffic from a UDP socket before it gets to DTLS. 
	- In some cases the DTLS packet is wrapped in a TURN packet on the wire - so you cant?t even assume the packet came in on UDP.
2) Ability to set and detect the use_srtp Extension
3) Ability to verify the self signed cert offered in the handshake
4) Ability to manage the handshake timeouts 
5) Ability to extract the keyring material post handshake

I haven?t kept up with JSSE DTLS but I don?t remember any of those API points being available.

It would be nice to be able to use JDK/JSSE but to be honest I?m pretty happy with BouncyCastle.

There is an example of our use here :
https://github.com/pipe/whipi/blob/d0fe6c06f5b34fa832d1ebce0bd228f066920da0/src/main/java/pe/pi/whipi/DTLS.java?
whipi/src/main/java/pe/pi/whipi/DTLS.java at d0fe6c06f5b34fa832d1ebce0bd228f066920da0 ? pipe/whipi
github.com
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240308/31cf053e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: whipi.png
Type: image/png
Size: 43712 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240308/31cf053e/whipi.png>

From jlahoda at openjdk.org  Fri Mar  8 11:24:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Mar 2024 11:24:00 GMT
Subject: Integrated: 8327218: Add an ability to specify modules which should
 have native access enabled
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <PspfSo5N2K5QM43DLB17r8fl_x0INERRapg23AUQ2Wk=.487bbfaf-f063-4ebf-8eee-f765c6b16840@github.com>

On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

This pull request has now been integrated.

Changeset: 27a03e0d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27a03e0dc3e08094aebc3524f68617f7e7fb5c5d
Stats:     132 lines in 9 files changed: 106 ins; 9 del; 17 mod

8327218: Add an ability to specify modules which should have native access enabled

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore, erikj, alanb, ihse

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

PR: https://git.openjdk.org/jdk/pull/18106


From jlahoda at openjdk.org  Fri Mar  8 11:31:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Mar 2024 11:31:57 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v4]
In-Reply-To: <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>
Message-ID: <tXfV4o18WKLPH_ke4NjEl_TBnM5eq1K8rRI4ZoOJ2s8=.fbb2e960-ae6f-4845-81f3-e35028b92a98@github.com>

On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting javadoc as suggested.

Thanks for all the feedback and comments! I've filled:
https://bugs.openjdk.org/browse/JDK-8327686
to cover the cleanup of the modules with native access enabled, and:
https://bugs.openjdk.org/browse/JDK-8327688
to allow to configure the modules with native access at link time.

I can try to take a look at either of those, if desired.

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

PR Comment: https://git.openjdk.org/jdk/pull/18106#issuecomment-1985530868


From mullan at openjdk.org  Fri Mar  8 15:23:00 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 8 Mar 2024 15:23:00 GMT
Subject: Integrated: 8317431: Implement simpler Comparator when building
 certification paths
In-Reply-To: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
References: <a_9GcZ02V_LDaM12w3hBHdmLx3tb14mgXHl46nud2LU=.39393f16-8d4f-4670-b043-0c6bd1191b4e@github.com>
Message-ID: <NiX4ay0uX__Vp7RIRVFhem4Ua3E7Hf9spnQU-hhj8Hw=.b1371638-0dea-45c9-bc1d-3ba82b7addac@github.com>

On Wed, 3 Jan 2024 16:55:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
> 
> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
> 
> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate

This pull request has now been integrated.

Changeset: c4845f01
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4845f01d236a006f3aefb7fa2e1a564673b7ff3
Stats:     828 lines in 8 files changed: 311 ins; 449 del; 68 mod

8317431: Implement simpler Comparator when building certification paths

Reviewed-by: kdriver, weijun

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

PR: https://git.openjdk.org/jdk/pull/17248


From abakhtin at openjdk.org  Fri Mar  8 19:14:57 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 8 Mar 2024 19:14:57 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <yPGDPz9LovJi6Zq2AujBe9wWBN98ccCtmfK6pibQKxA=.9b689fde-49aa-462c-8ab8-ab3c8ba13772@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
 <upJeEhGRHpC5akCsNJE-qw9wLE8JVeTbMgaF19k5XX4=.de8b5d1d-05e7-43c0-8c84-463d26e3a2ab@github.com>
 <iZwXZl-JKTLXb2A4JC1pRHur9ukAcJoyUq3PvK3L_yA=.21848030-bfcc-46f7-b3bd-7cc9aa14381b@github.com>
 <pWiI8p1UCqL6qR2T972Z0HbvAMXxfVwmaxx_OlPlSck=.10058ab2-ee28-4215-880a-dcd3faa42a21@github.com>
 <yPGDPz9LovJi6Zq2AujBe9wWBN98ccCtmfK6pibQKxA=.9b689fde-49aa-462c-8ab8-ab3c8ba13772@github.com>
Message-ID: <TafrQYJsxX63yJuYUR_f7zVxS7iOAhMiUsOVuGbxeHw=.83c8a8d6-e181-4389-b559-a6135c84141f@github.com>

On Fri, 16 Feb 2024 15:01:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> Will KEYCHAINSTORE-ROOT contains trusted certs inside KEYCHAINSTORE? I tried on my machine and there are some items not in `security dump-trust-settings -s`.
>> `security dump-trust-settings -s` returns only predefined root certificates. KEYCHAINSTORE-ROOT additionally contains installed root trusted certificates in the system domain
>
>> `security dump-trust-settings -s` returns only predefined root certificates. KEYCHAINSTORE-ROOT additionally contains installed root trusted certificates in the system domain
> 
> Are you sure they should be added into this keystore? It looks like all the extra certs in KEYCHAINSTORE-ROOT that are not in `security dump-trust-settings -s` are all inside KEYCHAINSTORE. Maybe that's where they should belong to?

@wangweij could you please take a look at the last proposed commit, if you have any chance

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1986258560


From weijun at openjdk.org  Fri Mar  8 19:52:00 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Mar 2024 19:52:00 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
Message-ID: <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>

On Fri, 23 Feb 2024 23:07:07 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Load root certificates from SystemRootCertificates.keychain

src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 525:

> 523:     // Load predefined root certificates from SystemRootCertificates keychain
> 524:     // SecTrustCopyAnchorCertificates includes extra root certificates and can not be used here
> 525:     if( SecKeychainOpen("/System/Library/Keychains/SystemRootCertificates.keychain", &keychain) != errSecSuccess ) {

I'll study the API more but it looks too implementation-detail dependent to read the file directly. Are there any other APIs? I see one named `SecTrustCopyCustomAnchorCertificates`. Can it be used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1518225296


From hchao at openjdk.org  Fri Mar  8 21:15:45 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 8 Mar 2024 21:15:45 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v6]
In-Reply-To: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
Message-ID: <o6rbwmlZAd4hEehO2b9kxBcstNa9wX6_kdaY9smcPu4=.fd51e096-9018-429a-8bb5-90a2d35a4bf7@github.com>

> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!

Hai-May Chao 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 six additional commits since the last revision:

 - Merge
 - remove unneeded checks in engineGetEntry
 - Update engineDeleteEntry
 - Update engineIsKeyEntry and engineIsCertificateEntry
 - Update bug number in the test
 - 8327461: KeyStore getEntry is not thread-safe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18156/files
  - new: https://git.openjdk.org/jdk/pull/18156/files/15220c6b..cbea5228

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=04-05

  Stats: 7994 lines in 136 files changed: 3931 ins; 3807 del; 256 mod
  Patch: https://git.openjdk.org/jdk/pull/18156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18156/head:pull/18156

PR: https://git.openjdk.org/jdk/pull/18156


From weijun at openjdk.org  Fri Mar  8 22:04:10 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Mar 2024 22:04:10 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v6]
In-Reply-To: <o6rbwmlZAd4hEehO2b9kxBcstNa9wX6_kdaY9smcPu4=.fd51e096-9018-429a-8bb5-90a2d35a4bf7@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <o6rbwmlZAd4hEehO2b9kxBcstNa9wX6_kdaY9smcPu4=.fd51e096-9018-429a-8bb5-90a2d35a4bf7@github.com>
Message-ID: <JizpuAv84JI5Sx6O-5pqtVkyk9jRWA19rH-9KH7HgRg=.c7ba186e-cebd-4d6a-8878-173ebacb720d@github.com>

On Fri, 8 Mar 2024 21:15:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!
>
> Hai-May Chao 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 six additional commits since the last revision:
> 
>  - Merge
>  - remove unneeded checks in engineGetEntry
>  - Update engineDeleteEntry
>  - Update engineIsKeyEntry and engineIsCertificateEntry
>  - Update bug number in the test
>  - 8327461: KeyStore getEntry is not thread-safe

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 301:

> 299:         Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH));
> 300:         Key entryKey = internalGetKey(entry, password);
> 301:         return entryKey;

Combine the 2 lines above.

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 480:

> 478:         Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH));
> 479:         Certificate[] certChain = internalGetCertificateChain(entry);
> 480:         return certChain;

Combine the two lines above.

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1027:

> 1025: 
> 1026:         Entry entry = entries.remove(alias.toLowerCase(Locale.ENGLISH));
> 1027:         if (entry != null) {

No need to check `entry != null`.

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1082:

> 1080:     }
> 1081: 
> 1082:     private boolean internalEngineIsKeyEntry(Entry entry) {

No need to have both `internal` and `Engine` in the method name. Use `internal` only to follow the other method names. Same with `internalEngineIsCertificateEntry` below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518348960
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518349769
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518350934
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518355653


From hchao at openjdk.org  Fri Mar  8 23:13:22 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 8 Mar 2024 23:13:22 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v7]
In-Reply-To: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
Message-ID: <1PhsXhVgWPP3Is4eD40SbFt0Twu59GJ9Fe_ujLBrvRo=.f5009aa8-99b5-4859-9946-f79ec0030bbb@github.com>

> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Rename internal method's name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18156/files
  - new: https://git.openjdk.org/jdk/pull/18156/files/cbea5228..f5e41145

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18156&range=05-06

  Stats: 11 lines in 1 file changed: 0 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18156/head:pull/18156

PR: https://git.openjdk.org/jdk/pull/18156


From hchao at openjdk.org  Fri Mar  8 23:13:23 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 8 Mar 2024 23:13:23 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v6]
In-Reply-To: <JizpuAv84JI5Sx6O-5pqtVkyk9jRWA19rH-9KH7HgRg=.c7ba186e-cebd-4d6a-8878-173ebacb720d@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <o6rbwmlZAd4hEehO2b9kxBcstNa9wX6_kdaY9smcPu4=.fd51e096-9018-429a-8bb5-90a2d35a4bf7@github.com>
 <JizpuAv84JI5Sx6O-5pqtVkyk9jRWA19rH-9KH7HgRg=.c7ba186e-cebd-4d6a-8878-173ebacb720d@github.com>
Message-ID: <VD1rkhXsHCto6xft6In4IPi9DBYacc0VMyIPGasG1Ls=.ac0fa4fb-fe58-4a2c-a955-fdb44de87421@github.com>

On Fri, 8 Mar 2024 21:56:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao 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 six additional commits since the last revision:
>> 
>>  - Merge
>>  - remove unneeded checks in engineGetEntry
>>  - Update engineDeleteEntry
>>  - Update engineIsKeyEntry and engineIsCertificateEntry
>>  - Update bug number in the test
>>  - 8327461: KeyStore getEntry is not thread-safe
>
> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 301:
> 
>> 299:         Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH));
>> 300:         Key entryKey = internalGetKey(entry, password);
>> 301:         return entryKey;
> 
> Combine the 2 lines above.

Done.

> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 480:
> 
>> 478:         Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH));
>> 479:         Certificate[] certChain = internalGetCertificateChain(entry);
>> 480:         return certChain;
> 
> Combine the two lines above.

Done.

> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1027:
> 
>> 1025: 
>> 1026:         Entry entry = entries.remove(alias.toLowerCase(Locale.ENGLISH));
>> 1027:         if (entry != null) {
> 
> No need to check `entry != null`.

The API doc states: Returns: the previous value associated with key, or null if there was no mapping for key. It?d be a good practice to check if the entry is not null before proceeding with further operations. Would you please elaborate why it is not needed here?

> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1082:
> 
>> 1080:     }
>> 1081: 
>> 1082:     private boolean internalEngineIsKeyEntry(Entry entry) {
> 
> No need to have both `internal` and `Engine` in the method name. Use `internal` only to follow the other method names. Same with `internalEngineIsCertificateEntry` below.

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518399957
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518399969
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518399996
PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518400012


From weijun at openjdk.org  Fri Mar  8 23:21:57 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Mar 2024 23:21:57 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v6]
In-Reply-To: <VD1rkhXsHCto6xft6In4IPi9DBYacc0VMyIPGasG1Ls=.ac0fa4fb-fe58-4a2c-a955-fdb44de87421@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <o6rbwmlZAd4hEehO2b9kxBcstNa9wX6_kdaY9smcPu4=.fd51e096-9018-429a-8bb5-90a2d35a4bf7@github.com>
 <JizpuAv84JI5Sx6O-5pqtVkyk9jRWA19rH-9KH7HgRg=.c7ba186e-cebd-4d6a-8878-173ebacb720d@github.com>
 <VD1rkhXsHCto6xft6In4IPi9DBYacc0VMyIPGasG1Ls=.ac0fa4fb-fe58-4a2c-a955-fdb44de87421@github.com>
Message-ID: <m8IXhn4OXQg3gMZnEpq4M0TnO9M-4QHrOx60D4YKZgc=.6235a3e4-fdd9-4782-959e-d8023b164be4@github.com>

On Fri, 8 Mar 2024 23:09:42 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1027:
>> 
>>> 1025: 
>>> 1026:         Entry entry = entries.remove(alias.toLowerCase(Locale.ENGLISH));
>>> 1027:         if (entry != null) {
>> 
>> No need to check `entry != null`.
>
> The API doc states: Returns: the previous value associated with key, or null if there was no mapping for key. It?d be a good practice to check if the entry is not null before proceeding with further operations. Would you please elaborate why it is not needed here?

Because `null` will fail all three `instanceof` checks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518404259


From hchao at openjdk.org  Fri Mar  8 23:32:57 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 8 Mar 2024 23:32:57 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v6]
In-Reply-To: <m8IXhn4OXQg3gMZnEpq4M0TnO9M-4QHrOx60D4YKZgc=.6235a3e4-fdd9-4782-959e-d8023b164be4@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <o6rbwmlZAd4hEehO2b9kxBcstNa9wX6_kdaY9smcPu4=.fd51e096-9018-429a-8bb5-90a2d35a4bf7@github.com>
 <JizpuAv84JI5Sx6O-5pqtVkyk9jRWA19rH-9KH7HgRg=.c7ba186e-cebd-4d6a-8878-173ebacb720d@github.com>
 <VD1rkhXsHCto6xft6In4IPi9DBYacc0VMyIPGasG1Ls=.ac0fa4fb-fe58-4a2c-a955-fdb44de87421@github.com>
 <m8IXhn4OXQg3gMZnEpq4M0TnO9M-4QHrOx60D4YKZgc=.6235a3e4-fdd9-4782-959e-d8023b164be4@github.com>
Message-ID: <bAc2TUaeCSi1b_O4Op5AvU5RdpmHidoioNJiIudiMXw=.1345bd35-016a-4b15-b3d6-81a251b4ba41@github.com>

On Fri, 8 Mar 2024 23:18:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The API doc states: Returns: the previous value associated with key, or null if there was no mapping for key. It?d be a good practice to check if the entry is not null before proceeding with further operations. Would you please elaborate why it is not needed here?
>
> Because `null` will fail all three `instanceof` checks.

I'd like to keep the check here for good practice and following the API doc, instead of letting further instanceof operation fails. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518409894


From weijun at openjdk.org  Fri Mar  8 23:41:53 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Mar 2024 23:41:53 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v7]
In-Reply-To: <1PhsXhVgWPP3Is4eD40SbFt0Twu59GJ9Fe_ujLBrvRo=.f5009aa8-99b5-4859-9946-f79ec0030bbb@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <1PhsXhVgWPP3Is4eD40SbFt0Twu59GJ9Fe_ujLBrvRo=.f5009aa8-99b5-4859-9946-f79ec0030bbb@github.com>
Message-ID: <YZSIyVdwlLA7PPw9sUdzOzDiO-OgP6re3EAsjW_95WE=.aea414ca-31d3-4881-b93d-f42ff3c0b45e@github.com>

On Fri, 8 Mar 2024 23:13:22 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename internal method's name

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18156#pullrequestreview-1926012983


From weijun at openjdk.org  Fri Mar  8 23:41:53 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Mar 2024 23:41:53 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v6]
In-Reply-To: <bAc2TUaeCSi1b_O4Op5AvU5RdpmHidoioNJiIudiMXw=.1345bd35-016a-4b15-b3d6-81a251b4ba41@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <o6rbwmlZAd4hEehO2b9kxBcstNa9wX6_kdaY9smcPu4=.fd51e096-9018-429a-8bb5-90a2d35a4bf7@github.com>
 <JizpuAv84JI5Sx6O-5pqtVkyk9jRWA19rH-9KH7HgRg=.c7ba186e-cebd-4d6a-8878-173ebacb720d@github.com>
 <VD1rkhXsHCto6xft6In4IPi9DBYacc0VMyIPGasG1Ls=.ac0fa4fb-fe58-4a2c-a955-fdb44de87421@github.com>
 <m8IXhn4OXQg3gMZnEpq4M0TnO9M-4QHrOx60D4YKZgc=.6235a3e4-fdd9-4782-959e-d8023b164be4@github.com>
 <bAc2TUaeCSi1b_O4Op5AvU5RdpmHidoioNJiIudiMXw=.1345bd35-016a-4b15-b3d6-81a251b4ba41@github.com>
Message-ID: <yKOsaOAjsKWey17O1hXzXtu_6FzYHSGW84o6wCM2rJI=.6cc476c3-ef71-45ad-a4ce-0245a971b7b4@github.com>

On Fri, 8 Mar 2024 23:30:28 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Because `null` will fail all three `instanceof` checks.
>
> I'd like to keep the check here for good practice and following the API doc, instead of letting further instanceof operation fails. Thanks.

Sure, you can keep it. But please note that there was no null check before your change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18156#discussion_r1518413455


From abakhtin at openjdk.org  Sat Mar  9 05:42:57 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Sat, 9 Mar 2024 05:42:57 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>
Message-ID: <RD87A15QGG2SK_C6IRG8xDL7XgOp13r0-C1bZCUf2J4=.cfbc926e-148f-47d4-925b-93bd7b250338@github.com>

On Fri, 8 Mar 2024 19:47:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Load root certificates from SystemRootCertificates.keychain
>
> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 525:
> 
>> 523:     // Load predefined root certificates from SystemRootCertificates keychain
>> 524:     // SecTrustCopyAnchorCertificates includes extra root certificates and can not be used here
>> 525:     if( SecKeychainOpen("/System/Library/Keychains/SystemRootCertificates.keychain", &keychain) != errSecSuccess ) {
> 
> I'll study the API more but it looks too implementation-detail dependent to read the file directly. Are there any other APIs? I see one named `SecTrustCopyCustomAnchorCertificates`. Can it be used?

Hi @wangweij , 
Thank you for review.
Unfortunately `SecTrustCopyCustomAnchorCertificates` can not be used also. It is used to retrieve certificates from your own created SecTrust. As I know it is not possible to create/load SecTrust with predefined certs without reading`/System/Library/Keychains/SystemRootCertificates.keychain`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1518484143


From horvath.peter.gergely at gmail.com  Sat Mar  9 21:15:47 2024
From: horvath.peter.gergely at gmail.com (=?UTF-8?Q?Horv=C3=A1th_P=C3=A9ter_Gergely?=)
Date: Sat, 9 Mar 2024 22:15:47 +0100
Subject: Improving logging in Krb5LoginModule
Message-ID: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>

Dear All,

In the past, I had issues with debug logging in Krb5LoginModule: if debug
is enabled,
messages are simply written to the stdout. It is relatively hard to
correlate these
messages with application logs, as there are no timestamps for
Krb5LoginModule output messages.

Imagine a server fails to service a request, due to its failure to
communicate with
another Kerberized server. The failure itself will be logged properly, but
there is no way
for an operator to easily find and correlate Krb5LoginModule debug output.
(We are talking about servers unders heavy load)

I think debug logging in Krb5LoginModule should be improved; e.g. at least,
messages
should be sent to both stdout and a JUL logger maybe?

I would be happy to implement the code change if someone is willing to
sponsor this issue.

Could someone please help here?

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240309/0e0bcbb9/attachment.htm>

From weijun.wang at oracle.com  Sun Mar 10 16:01:10 2024
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Sun, 10 Mar 2024 16:01:10 +0000
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
Message-ID: <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>

Hi Se?n,

I know you are working on enhancing the security debug output with timestamps and thread info now. Do you think it can also cover Kerberos?

Traditionally, Kerberos debugging is independent of other security areas and itself is quite complicated. It includes the "debug" label in JAAS LoginModule (as Peter pointed out below) and separate system properties like sun.security.krb5.debug, sun.security.jgss.debug, sun.security.nativegss.debug, and sun.security.spnego.debug. It will be definitely great if they can enjoy the enhancement of sun.security.util.Debug.

BTW, Peter also mentioned a JUL logger. IIUC, our current debug messages are only sent to System.err, right?

Thanks,
Weijun



> On Mar 9, 2024, at 4:15?PM, Horv?th P?ter Gergely <horvath.peter.gergely at gmail.com> wrote:
> 
> Dear All,
> 
> In the past, I had issues with debug logging in Krb5LoginModule: if debug is enabled,
> messages are simply written to the stdout. It is relatively hard to correlate these
> messages with application logs, as there are no timestamps for Krb5LoginModule output messages.
> 
> Imagine a server fails to service a request, due to its failure to communicate with
> another Kerberized server. The failure itself will be logged properly, but there is no way
> for an operator to easily find and correlate Krb5LoginModule debug output. 
> (We are talking about servers unders heavy load)
> 
> I think debug logging in Krb5LoginModule should be improved; e.g. at least, messages
> should be sent to both stdout and a JUL logger maybe?
> 
> I would be happy to implement the code change if someone is willing to sponsor this issue.
> 
> Could someone please help here?
> 
> Thanks,
> Peter


From anthony.scarpino at oracle.com  Mon Mar 11 05:13:53 2024
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 11 Mar 2024 05:13:53 +0000
Subject: [External] : Re: PEM API github repo
In-Reply-To: <CACSnhuVUohWjR-WeiCQBBfB81M=322e7fikHznBF8RirGR+Gkg@mail.gmail.com>
References: <d8f11a64-9159-4bb4-83a3-30147886e0be@oracle.com>
 <CAMrH03J=wX-1Kp+LVasv0-R-NEWBy31_dkb+v4CFNXoksJRfwQ@mail.gmail.com>
 <9c42dd2d-00a2-470f-b319-c2cfb7c10de6@oracle.com>
 <CACSnhuU42nCK3kq1MTxavASOeW_gh_2e5m1=KJ41wy+JEpQ7hg@mail.gmail.com>
 <CACSnhuVUohWjR-WeiCQBBfB81M=322e7fikHznBF8RirGR+Gkg@mail.gmail.com>
Message-ID: <52811109-CCBA-4602-A3B2-B619A1F3A0F8@oracle.com>



On Mar 9, 2024, at 8:09?AM, Karl Scheibelhofer <karl.scheibelhofer.75 at gmail.com> wrote:

?
... try again from from my subscribed mail account...

Hi Tony,

in my jdk fork, I created a branch named pem-feedback-karl.

https://github.com/KarlScheibelhofer/jdk/tree/pem-feedback-karl<https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/jdk/tree/pem-feedback-karl__;!!ACWV5N9M2RV99hQ!P088nxefoG2d2NzBJECdP8Ab4OGGscVfSwE-ylR2_lix1Ymcxt9vOjOV_42F3lk9fVHHs7DBVvJwETQHDcjrkRJmSPFTE8aT$>

It is based on the pem branch of your jdk fork.
In this pem-feedback-karl branch, I did some cleanup without changing
the API. Your tests pass as before.

My original pem-keystore implementation for the SUN provider is in this branch

https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore<https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore__;!!ACWV5N9M2RV99hQ!P088nxefoG2d2NzBJECdP8Ab4OGGscVfSwE-ylR2_lix1Ymcxt9vOjOV_42F3lk9fVHHs7DBVvJwETQHDcjrkRJmSHhrXcgG$>

It did not use the PEM API.

In the branch

https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore-pem-api<https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore-pem-api__;!!ACWV5N9M2RV99hQ!P088nxefoG2d2NzBJECdP8Ab4OGGscVfSwE-ylR2_lix1Ymcxt9vOjOV_42F3lk9fVHHs7DBVvJwETQHDcjrkRJmSEywX3XP$>

I modified the PEM keystore implementation to use the PEMDecoder and PEMEncoder.
To make it pass all tests, I had to fix some issues with the PEM api:

* fix missing line-breaks when encoding certificates (and CRLs)
* use uniform line length for PEM encoding keys and certificates

It sounds like I did my repo update to use MimeEncoder after you had pulled the changes.

During this work, I took some notes regarding the PEM api:

* Consider decoupling the raw PEM encoding and decoding from SecurityObject.
  This would make the API usable for general purpose PEM encoding and
decoding, not just for keys and certificates, as it is now.

There has been discussions about adding a generic PEM object that would have methods to return the header, footer, and PEM text, instead of processing into a class or KeySpec. Is there something more ?general purpose? you had it mind?

* For this PEM keystore implementation it is essential to parse the
preceding explanatory text lines.
  The PEM decoder should support this.
  As it is now, the keystore implementation must parse the PEM objects
itself, including reading PEM header and footer lines.
  Having to handle half the work in the application diminishes the
value of the PEMDecoder.
  It only delegates the decoding of certificates and keys to the PEMDecoder.

* PEMDecoder should be able to handle or pass through unknown PEM
objects gracefully.
  Otherwise the application has to check the PEM labels in advance
itself, which does not make sense.

So do you not have a structured data file?  I expected the application would parse its own metadata, then when the structured code got to a PEM tag, it would pass the InputStream to PEMDecoder.

I am concerned about a generic PEM object storing an unknown amount of application metadata and returning it back.  I feel handling non-PEM should be in the scope of the encoder/decoder.


* Though supporting InputStream/OutputStream for reading and writing
makes sense,
  supporting Reader/Writer feels even more essential for robust
support for all character encodings.
  Multi-Byte character encodings won't work with InputStream/OutputStream.

A Reader will read ahead, buffering the input data.  I saw this when I had `decode(Reader)` in the API.  It would return the first PEM object, but the read pointer was at the end of the file, missing the remaining PEM objects.

Is the multi-byte characters for the keystore metadata?  I don?t see how this affects Base64.


* The standard line separator for PEM is "\r\n".
  For PEM files stored in a typical linux file system, "\n" is
typically used, however.
  See the output of openssl, for example.
  Because there are still several command line utilities that do not
work well with "\r\n" line breaks.
  Supporting a different line-separator than "\r\n" is a good idea in
my opinion.
  Base64.getMimeEncoder also supports selecting a custom line separator.

The standards I saw says the line separator is ?\r\n?.  I realize decoders have to be more flexible because many may not follow the line separators or cut-n-paste removes them.  I think having a configurable line separator for encoding is likely to create more incompatibility rather than lessen for cross-platform and using with other applications.


* The PEMEncoder encodes the predefined SecurityObjects only.
  There is no way to use it to PEM encoded any other type of object.
  Consider opening a path to generic use.

The generic PEM object I mentioned previously I think fits this case.  It would still be a SecurityObject as I don?t see value in passing in any object.


* If an application has a DER encoded certificate, it has to decode
and parse the certificate before
  it can encode it using PEMEncoder.
  This is inconvenient.

Yeah, there isn?t an EncodedKeySpec equivalent.  I?d have to think if there is an easy way to do this without causing more problems.  Given the purpose is going between Java Objects and PEM, accepting random data isn?t a goal.  Maybe something that can be addressed with a generic PEM object.

Thanks

Tony

* PEMEncoder uses 64 characters as line length for private and public keys,
  and 76 characters for certificates.
  Use the same line length for all types by default.
  Consider adding support for selecting a custom line length.
  Base64.getMimeEncoder also supports selecting a line custom length.

I hope this helps advancing the PEM efforts.

Best regards, Karl

On Thu, Jan 25, 2024 at 10:02?PM Anthony Scarpino
<anthony.scarpino at oracle.com<mailto:anthony.scarpino at oracle.com>> wrote:
>
>
> On 1/25/24 9:20 AM, Daniel Jeli?ski wrote:
> > Hi Tony,
> > Thanks for the links! The API looks very promising.
> >
> > Out of curiosity, why aren't you using the Base64 MIME
> > encoder/decoder? They are supposed to produce/remove the newline
> > characters.
>
> I can look it over again.  I had inconsistencies during testing with
> expected data and returned data.
>
> > The relationship between the byte[] and String data should be
> > specified. Base64 explicitly specifies that the String APIs are
> > translated to the byte[] APIs with ISO 8859-1 encoding. The PEMDecoder
> > is currently using the default charset, which might produce
> > interesting results if the charset is set to EBCDIC. The encoder is
> > using UTF-8, which is reasonable, but given that the produced output
> > will always be ASCII, ISO 8859-1 will perform better.
>
> That's fine
>
> > There's a disparity between the decoder and the encoder APIs; both
> > work with strings, but Decoder accepts InputStream and not arrays, and
> > Encoder produces byte arrays, but does not work with streams. This
> > should be more uniform. I like Decoder's InputStream support (that's
> > currently the only way to read multiple CA certificates from a single
> > file - the String overload currently only returns the first one), so
> > I'd add OutputStream support to Encoder for parity.
>
> I don't see parity as a requirement.  I see encoding and decoding as
> having unique requirements.  Decoding from a file or InputStream makes
> sense.  A decode(byte[]) method didn't seem necessary as I felt it
> unlikely a user would have a single byte[] with PEM data.  They were
> more likely to have a String or an InputStream.  The developer can wrap
> it with ByteArrayInputStream or String(byte[], Charset), which is what a
> public API method would do internally.
>
> Encoding is a single operation on an object.  Pass in a SecurityObject
> and PEM data is returned.  Returning a byte[] is the most flexible
> without creating more methods.  In the case where meta data is
> in-between the PEM or some other data formatting.
>
> Why should the API have an OutputStream method, something like:
>    pem.encodeToOutputStream(so, outputstream);
> when the API as written today, the developer can use:
>    outputstream.writeBytes(pem.encode(obj));
>
> I don't like to add API methods just for symmetry, they need to have a
> compelling reason.  I have not seen that in the OutputStream case.
>
>
> > Karl's earlier
> > suggestion to support Stream<SecurityObject> also makes a lot of
> > sense.
> I haven't counted out Stream, I just haven't seen a compelling reason.
> My tests use stream() from an array list of PEM strings.  But I haven't
> seen the situation where the API needs stream support that couldn't be
> done in a different way.  This is a preview JEP, and we still have time.
>   If there is a compelling example, point it out to me.
>
> > I'm not a big fan of the non-static factory methods
> > withEncryption/withDecryption/withFactory. The problem with non-static
> > methods that return an instance of the same type is that you need to
> > check the documentation to know if the method returns a new instance
> > or if it mutates the current one. Can we use static factory methods
> > instead? Either that, or create a builder class.
>
> The API states the classes are immutable which was a big requirement and
> it why it's stated all over the docs.  A builder class was considered
> early in the API development, but it was too much complication for a few
> optional cases where the developer may need to specify details like
> encryption or a factory.  The API has the builder idea, without the
> extra builder construction methods.  I don't see how a static factory
> method fit here.
>
> > I don't like the PEMEncoder.withEncryption API. It's not predictable
> > enough; when encoding data, it's not consistent between writing
> > unencrypted data (certificate, crl), throwing (PublicKey,
> > EncryptedPrivateKeyInfo) and writing encrypted data (unencrypted
> > private keys). The alternative of forcing the users to encrypt using
> > EncryptedPrivateKeyInfo looks better to me.
>
> That was a design decision to make the API easier to use.  The
> non-security export does not need to be burden with understanding
> EncryptedPrivateKeyInfo.
>
> The API can be consistent if you choose to only pass in
> EncryptedPrivateKeyInfo and not set withEncryption().  If an
> ArrayList<SecurityObject> encodes with a stream(), it is nice to
> configure encryption for private keys and still encode public keys and
> certificates with the same encoder.
>
>
> > I'd love to see support for the OpenSSL private key formats; it seems
> > that RSAPrivateCrtKeyImpl already supports PKCS#1 format, so it may be
> > just a matter of exposing that functionality. Other key types like EC
> > might need more work. That might be added later after the API is
> > finalized.
>
> OpenSSL 3.0 is transitioning away from their format to PKCS#8.  It is an
> obsoleted format.  While I have thought about decoding support of RSA
> PKCS#1 for compatibility, I have no intention to support OpenSSL or
> PKCS#1 encoding with this PEM API.
>
> If someone is interested in old OpenSSL or other encoding formats, that
> is why the Encoder and Decoder interfaces are included.  To give a
> structure for developing other encoding.
>
> >
> > Thanks,
> > Daniel
> >
> > ?r., 24 sty 2024 o 22:24 Anthony Scarpino
> > <anthony.scarpino at oracle.com<mailto:anthony.scarpino at oracle.com>> napisa?(a):
> >>
> >> Hi,
> >>
> >> The following github link is to the PEM API as it is written in the
> >> draft JEP (https://openjdk.org/jeps/8300911).  There has been a few
> >> changes since the original posting.
> >>
> >> https://urldefense.com/v3/__https://github.com/ascarpino/jdk/tree/pem__;!!ACWV5N9M2RV99hQ!NmZu22NrC2hxWJuqLHZ6l1C0KYVK0Qf_rV7tV-1uLqUb_5sFMJXyCCKVPjmEmGCeQ6US2RJquDm9AJqZXO46ju8Q$
> >>
> >> The Encoder and PEMEncoder to now return byte[] for the encode() method.
> >>    A new PEMEncoder method, encodeToString(), was added.  I believe these
> >> make it easier for outputting data to a file and InputStreams, while
> >> still supporting a method that returns a String.
> >>
> >> For decode, InputStream has replaced Reader.  There were comments
> >> preferring InputStream and I found that Reader's buffering quirks were
> >> problematic. Decoding from a byte[] is easy through an ByteArrayInputStream.
> >>
> >> If you are interested in testing out the API, please download and
> >> compile the repo.  Then let me know how your experience went.
> >>
> >> thanks
> >>
> >> Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240311/b17a03d2/attachment.htm>

From sean.coffey at oracle.com  Mon Mar 11 09:43:27 2024
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=C3=A1n_Coffey?=)
Date: Mon, 11 Mar 2024 09:43:27 +0000
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
 <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
Message-ID: <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>


On 10/03/2024 16:01, Wei-Jun Wang wrote:
> Hi Se?n,
>
> I know you are working on enhancing the security debug output with timestamps and thread info now. Do you think it can also cover Kerberos?
I'd love to see Kerberos fall under the same debug implementation used 
by other JDK security libraries. I suspect it was a standalone product a 
long time back and had its own debug impl as a result. I'd like to see 
it worked separate to the ongoing decorator work that's taking place via 
JDK-8051959. The debug stack for krb5 is different and managed via a Map 
currently. Maybe Peter could start out by moving the debug output from 
System.out calls to the sun.security.util.Debug calls as suggested.

Using a Logger should be on the radar also. We'd have to use the 
System.Logger interface since that's the only one guaranteed to be 
present in the runtime. Maybe the Logger work can be done as a follow on 
task. I'm also examining the potential for wider use of Logger in 
security libs. The TLS javax.net.debug option already offers use of a 
Logger but the configuration in both the calling code and backend 
remains a blocker to adoption IMO. (e.g. no option to configure Level 
correctly and static backend configuration options may not be set up 
correctly at the time logger output becomes necessary to debug an issue)

regards,
Sean.

>
> Traditionally, Kerberos debugging is independent of other security areas and itself is quite complicated. It includes the "debug" label in JAAS LoginModule (as Peter pointed out below) and separate system properties like sun.security.krb5.debug, sun.security.jgss.debug, sun.security.nativegss.debug, and sun.security.spnego.debug. It will be definitely great if they can enjoy the enhancement of sun.security.util.Debug.
>
> BTW, Peter also mentioned a JUL logger. IIUC, our current debug messages are only sent to System.err, right?
>
> Thanks,
> Weijun
>
>
>
>> On Mar 9, 2024, at 4:15?PM, Horv?th P?ter Gergely <horvath.peter.gergely at gmail.com> wrote:
>>
>> Dear All,
>>
>> In the past, I had issues with debug logging in Krb5LoginModule: if debug is enabled,
>> messages are simply written to the stdout. It is relatively hard to correlate these
>> messages with application logs, as there are no timestamps for Krb5LoginModule output messages.
>>
>> Imagine a server fails to service a request, due to its failure to communicate with
>> another Kerberized server. The failure itself will be logged properly, but there is no way
>> for an operator to easily find and correlate Krb5LoginModule debug output.
>> (We are talking about servers unders heavy load)
>>
>> I think debug logging in Krb5LoginModule should be improved; e.g. at least, messages
>> should be sent to both stdout and a JUL logger maybe?
>>
>> I would be happy to implement the code change if someone is willing to sponsor this issue.
>>
>> Could someone please help here?
>>
>> Thanks,
>> Peter


From eirbjo at openjdk.org  Mon Mar 11 11:34:14 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 11 Mar 2024 11:34:14 GMT
Subject: RFR: 8327779: Remove deprecated internal field
 sun.security.x509.X509Key.key
Message-ID: <mldT4vDRBT6DMvgcXy39L2bXT_oWK1nL6khzkGrLqh8=.cd4cfe2e-df0e-4780-b63e-f491aa417671@github.com>

Please review this cleanup PR which removes the protected, deprecated field `X509Key.key` in the internal package `sun.security.x509`.

This field and the associated field `unusedBits` have been marked `@Deprecated` since the initial load. The recommended replacement is to use the `BitArray` representation, which does not require keys to be byte-aligned.

Two use sites of the `key` field were found in subclasses:

* The `ECPublicKeyImpl` constructor was updated to use a `BitArray` instead.
* `ECPublicKeyImpl.parseKeyBits()` was updated to call `getKey().toByteArray()` to produce the byte array.

Somewhat unrelated, the method `ECPublicKeyImpl.getEncodedPublicValue()` was deemed unused and has been removed.

Testing and verification: This PR does not update any tests. GHA runs green.

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

Commit messages:
 - Remove the deprecated field X509Key.key with associated code

Changes: https://git.openjdk.org/jdk/pull/18185/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18185&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327779
  Stats: 55 lines in 2 files changed: 2 ins; 48 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18185/head:pull/18185

PR: https://git.openjdk.org/jdk/pull/18185


From dfuchs at openjdk.org  Mon Mar 11 12:47:58 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 12:47:58 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v3]
In-Reply-To: <i3p1LKWttRYZoHuednrI7xs4cWWoeB8gJdTVfahPGAE=.fb40909c-d43d-4379-9521-b71cc168b90b@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <i3p1LKWttRYZoHuednrI7xs4cWWoeB8gJdTVfahPGAE=.fb40909c-d43d-4379-9521-b71cc168b90b@github.com>
Message-ID: <OhzYcPMv30rlTX_EBjXMAmPBeZA_PHBUi4aeWk1Lnjs=.9ecc04c1-84ea-456e-a56b-ccf95a2a6642@github.com>

On Thu, 7 Mar 2024 16:53:22 GMT, Korov <duke at openjdk.org> wrote:

>> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
>> 
>> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
>> 
>> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.
>
> Korov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert change

@Korov I did a round of testing and results came back green. You're good to go. The SecurityManager has been deprecated for removal, so maybe it would be better to stay away from SecurityManager related classes from now on unless there some strong reason to make a change.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18086#pullrequestreview-1927730456


From weijun.wang at oracle.com  Mon Mar 11 13:21:43 2024
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Mon, 11 Mar 2024 13:21:43 +0000
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
 <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
 <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>
Message-ID: <63B2990C-522D-472B-BB9C-6007CBF9B55E@oracle.com>

I've filed https://bugs.openjdk.org/browse/JDK-8327818.

But first, in order to make sure the debug option in Krb5LoginModule and other JGSS/krb5-related system properties still work, there needs a way to instantiate a Debug object without providing the `-Djava.security.debug` system property.

For example, in Krb5LoginModule, currently we have

       boolean debug = "true".equalsIgnoreCase((String)options.get("debug"));

And I'm thinking of

       Debug debug = Debug.of("krb5loginmodule", (String)options.get("debug"));

Hopefully this .of() method can automatically support thread info or timestamp if the "debug" option has it.

Also, I am wondering if even without he "debug" option, user can set -Djava.security.debug=krb5loginmodule to show debug info there. However, some krb5 debug info might contain sensitive information like passwords or secret keys, so maybe there is a little danger to cover them with `-Djava.security.debug=all`.

Thanks,
Weijun


> On Mar 11, 2024, at 5:43?AM, Sean Coffey <sean.coffey at oracle.com> wrote:
> 
> 
> On 10/03/2024 16:01, Wei-Jun Wang wrote:
>> Hi Se?n,
>> 
>> I know you are working on enhancing the security debug output with timestamps and thread info now. Do you think it can also cover Kerberos?
> I'd love to see Kerberos fall under the same debug implementation used by other JDK security libraries. I suspect it was a standalone product a long time back and had its own debug impl as a result. I'd like to see it worked separate to the ongoing decorator work that's taking place via JDK-8051959. The debug stack for krb5 is different and managed via a Map currently. Maybe Peter could start out by moving the debug output from System.out calls to the sun.security.util.Debug calls as suggested.
> 
> Using a Logger should be on the radar also. We'd have to use the System.Logger interface since that's the only one guaranteed to be present in the runtime. Maybe the Logger work can be done as a follow on task. I'm also examining the potential for wider use of Logger in security libs. The TLS javax.net.debug option already offers use of a Logger but the configuration in both the calling code and backend remains a blocker to adoption IMO. (e.g. no option to configure Level correctly and static backend configuration options may not be set up correctly at the time logger output becomes necessary to debug an issue)
> 
> regards,
> Sean.
> 
>> 
>> Traditionally, Kerberos debugging is independent of other security areas and itself is quite complicated. It includes the "debug" label in JAAS LoginModule (as Peter pointed out below) and separate system properties like sun.security.krb5.debug, sun.security.jgss.debug, sun.security.nativegss.debug, and sun.security.spnego.debug. It will be definitely great if they can enjoy the enhancement of sun.security.util.Debug.
>> 
>> BTW, Peter also mentioned a JUL logger. IIUC, our current debug messages are only sent to System.err, right?
>> 
>> Thanks,
>> Weijun
>> 
>> 
>> 
>>> On Mar 9, 2024, at 4:15?PM, Horv?th P?ter Gergely <horvath.peter.gergely at gmail.com> wrote:
>>> 
>>> Dear All,
>>> 
>>> In the past, I had issues with debug logging in Krb5LoginModule: if debug is enabled,
>>> messages are simply written to the stdout. It is relatively hard to correlate these
>>> messages with application logs, as there are no timestamps for Krb5LoginModule output messages.
>>> 
>>> Imagine a server fails to service a request, due to its failure to communicate with
>>> another Kerberized server. The failure itself will be logged properly, but there is no way
>>> for an operator to easily find and correlate Krb5LoginModule debug output.
>>> (We are talking about servers unders heavy load)
>>> 
>>> I think debug logging in Krb5LoginModule should be improved; e.g. at least, messages
>>> should be sent to both stdout and a JUL logger maybe?
>>> 
>>> I would be happy to implement the code change if someone is willing to sponsor this issue.
>>> 
>>> Could someone please help here?
>>> 
>>> Thanks,
>>> Peter


From weijun.wang at oracle.com  Mon Mar 11 15:39:55 2024
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Mon, 11 Mar 2024 15:39:55 +0000
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <63B2990C-522D-472B-BB9C-6007CBF9B55E@oracle.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
 <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
 <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>
 <63B2990C-522D-472B-BB9C-6007CBF9B55E@oracle.com>
Message-ID: <9C2E4C1B-FDB2-4A18-B9FF-235D45EDF28E@oracle.com>

In fact, I've started working on it, see https://github.com/openjdk/jdk/pull/18199.

--Weijun

> On Mar 11, 2024, at 9:21?AM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> I've filed https://bugs.openjdk.org/browse/JDK-8327818.
> 
> But first, in order to make sure the debug option in Krb5LoginModule and other JGSS/krb5-related system properties still work, there needs a way to instantiate a Debug object without providing the `-Djava.security.debug` system property.
> 
> For example, in Krb5LoginModule, currently we have
> 
>       boolean debug = "true".equalsIgnoreCase((String)options.get("debug"));
> 
> And I'm thinking of
> 
>       Debug debug = Debug.of("krb5loginmodule", (String)options.get("debug"));
> 
> Hopefully this .of() method can automatically support thread info or timestamp if the "debug" option has it.
> 
> Also, I am wondering if even without he "debug" option, user can set -Djava.security.debug=krb5loginmodule to show debug info there. However, some krb5 debug info might contain sensitive information like passwords or secret keys, so maybe there is a little danger to cover them with `-Djava.security.debug=all`.
> 
> Thanks,
> Weijun
> 
> 
>> On Mar 11, 2024, at 5:43?AM, Sean Coffey <sean.coffey at oracle.com> wrote:
>> 
>> 
>> On 10/03/2024 16:01, Wei-Jun Wang wrote:
>>> Hi Se?n,
>>> 
>>> I know you are working on enhancing the security debug output with timestamps and thread info now. Do you think it can also cover Kerberos?
>> I'd love to see Kerberos fall under the same debug implementation used by other JDK security libraries. I suspect it was a standalone product a long time back and had its own debug impl as a result. I'd like to see it worked separate to the ongoing decorator work that's taking place via JDK-8051959. The debug stack for krb5 is different and managed via a Map currently. Maybe Peter could start out by moving the debug output from System.out calls to the sun.security.util.Debug calls as suggested.
>> 
>> Using a Logger should be on the radar also. We'd have to use the System.Logger interface since that's the only one guaranteed to be present in the runtime. Maybe the Logger work can be done as a follow on task. I'm also examining the potential for wider use of Logger in security libs. The TLS javax.net.debug option already offers use of a Logger but the configuration in both the calling code and backend remains a blocker to adoption IMO. (e.g. no option to configure Level correctly and static backend configuration options may not be set up correctly at the time logger output becomes necessary to debug an issue)
>> 
>> regards,
>> Sean.
>> 
>>> 
>>> Traditionally, Kerberos debugging is independent of other security areas and itself is quite complicated. It includes the "debug" label in JAAS LoginModule (as Peter pointed out below) and separate system properties like sun.security.krb5.debug, sun.security.jgss.debug, sun.security.nativegss.debug, and sun.security.spnego.debug. It will be definitely great if they can enjoy the enhancement of sun.security.util.Debug.
>>> 
>>> BTW, Peter also mentioned a JUL logger. IIUC, our current debug messages are only sent to System.err, right?
>>> 
>>> Thanks,
>>> Weijun
>>> 
>>> 
>>> 
>>>> On Mar 9, 2024, at 4:15?PM, Horv?th P?ter Gergely <horvath.peter.gergely at gmail.com> wrote:
>>>> 
>>>> Dear All,
>>>> 
>>>> In the past, I had issues with debug logging in Krb5LoginModule: if debug is enabled,
>>>> messages are simply written to the stdout. It is relatively hard to correlate these
>>>> messages with application logs, as there are no timestamps for Krb5LoginModule output messages.
>>>> 
>>>> Imagine a server fails to service a request, due to its failure to communicate with
>>>> another Kerberized server. The failure itself will be logged properly, but there is no way
>>>> for an operator to easily find and correlate Krb5LoginModule debug output.
>>>> (We are talking about servers unders heavy load)
>>>> 
>>>> I think debug logging in Krb5LoginModule should be improved; e.g. at least, messages
>>>> should be sent to both stdout and a JUL logger maybe?
>>>> 
>>>> I would be happy to implement the code change if someone is willing to sponsor this issue.
>>>> 
>>>> Could someone please help here?
>>>> 
>>>> Thanks,
>>>> Peter
> 


From hchao at openjdk.org  Mon Mar 11 16:32:20 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 11 Mar 2024 16:32:20 GMT
Subject: RFR: 8327461: KeyStore getEntry is not thread-safe [v6]
In-Reply-To: <KFrYlcJoNVqZTKad-7TY-SRE4DUAPSwUu-XtB5gSsl8=.7b715296-f95e-48e2-9149-66ac506f4697@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
 <OPhTecq-CE8960Muz-RZbEyYoRvzni-x6kQIAdjPgUM=.1944cdb9-956f-4063-9121-7f93e3bb841d@github.com>
 <KFrYlcJoNVqZTKad-7TY-SRE4DUAPSwUu-XtB5gSsl8=.7b715296-f95e-48e2-9149-66ac506f4697@github.com>
Message-ID: <oDz74hsUWG3M2odC6omwvu20J5b5IiJF1OXoJbXqHmc=.6a8a2262-7966-4d60-b994-934df2ece36d@github.com>

On Fri, 8 Mar 2024 09:22:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hai-May Chao 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 six additional commits since the last revision:
>> 
>>  - Merge
>>  - remove unneeded checks in engineGetEntry
>>  - Update engineDeleteEntry
>>  - Update engineIsKeyEntry and engineIsCertificateEntry
>>  - Update bug number in the test
>>  - 8327461: KeyStore getEntry is not thread-safe
>
> LGTM. Thanks!

@djelinski @wangweij Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18156#issuecomment-1988635024


From hchao at openjdk.org  Mon Mar 11 16:38:06 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 11 Mar 2024 16:38:06 GMT
Subject: Integrated: 8327461: KeyStore getEntry is not thread-safe
In-Reply-To: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
References: <RJzW372vqBqigkalnXGcwXb7H0fu9G5j9hMrqmA9XRM=.76e19cd7-1998-4c58-ba1b-c7abf7364ea1@github.com>
Message-ID: <RfqSnCiuNEkMUIIrEQdjhs4eggk5SELfkiT09Nmr-qw=.8aaeec75-8890-4bf4-ad24-22a9c5bba65f@github.com>

On Thu, 7 Mar 2024 17:06:19 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and certificate chain from Entry only once. This is because the entry may get updated between engineGetKey() and engineGetCertificateChain() which causes inconsistent result. A new test was added to assess and manipulate PKCS12KeyStore with read and write operations concurrently from multiple threads. Thanks!

This pull request has now been integrated.

Changeset: ffd43c92
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffd43c922e3b8b75a00e494d5484b6a487dd5c90
Stats:     213 lines in 2 files changed: 175 ins; 11 del; 27 mod

8327461: KeyStore getEntry is not thread-safe

Reviewed-by: djelinski, weijun

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

PR: https://git.openjdk.org/jdk/pull/18156


From weijun at openjdk.org  Mon Mar 11 16:42:32 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Mar 2024 16:42:32 GMT
Subject: RFR: 8327818: Implement Kerberos debug with sun.security.util.Debug
Message-ID: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>

Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/18199/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327818
  Stats: 191 lines in 3 files changed: 135 ins; 6 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/18199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18199/head:pull/18199

PR: https://git.openjdk.org/jdk/pull/18199


From weijun at openjdk.org  Mon Mar 11 19:45:33 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Mar 2024 19:45:33 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v2]
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <2cXLLPkJCKaqeLuSb9SbWQZxv94rCZz5OD5XN9Ad24g=.3f65a468-42c7-4ddf-94b1-885c00a75ebf@github.com>

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

  no longer configurable with java.security.debug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18199/files
  - new: https://git.openjdk.org/jdk/pull/18199/files/fef55d28..46dcb685

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=00-01

  Stats: 38 lines in 2 files changed: 0 ins; 32 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18199/head:pull/18199

PR: https://git.openjdk.org/jdk/pull/18199


From duke at openjdk.org  Mon Mar 11 20:35:16 2024
From: duke at openjdk.org (Korov)
Date: Mon, 11 Mar 2024 20:35:16 GMT
Subject: RFR: 8312444: Delete unused parameters and variables in
 SocketPermission [v3]
In-Reply-To: <XiuAe_ZZsvyhrZwq_JC37YMi-beIi6lNXURM2-PBf7c=.4cdee03e-8fce-4072-89d8-79410fc11619@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
 <3QtaPjp5uOWOhsnqPm-MNdLppEDPOP05e4BHqTtRRdk=.bd149fa0-a2a7-468f-87a1-c6f882168b59@github.com>
 <s3O_-Igct9FVE_H8czPXtGJpT7HcWkV4Zq_32cG1Zls=.4ee3a5de-31a2-4c05-90ce-6bc04f4076ee@github.com>
 <V_uDmQqbi0jB73dnwWo3KnfxRdRvl-ZqJ2PHacJ7YpY=.35d76a3e-2d30-4562-86df-d2a95ce5a00b@github.com>
 <iwkZNLvBPCT95X26xLY-a1JyQtlBhjJF57_ggFAncZI=.ac819afc-7141-41b9-aa78-63cd663c6c87@github.com>
 <XiuAe_ZZsvyhrZwq_JC37YMi-beIi6lNXURM2-PBf7c=.4cdee03e-8fce-4072-89d8-79410fc11619@github.com>
Message-ID: <k8OmFDUXO-GlukBt7czSDu9dF1WDaXh8GKuaVuqXbzY=.0fa164f9-4d52-41ad-9c22-8c7682f480f8@github.com>

On Tue, 5 Mar 2024 13:37:22 GMT, Korov <duke at openjdk.org> wrote:

>>> Seems good. If nobody disagrees such mixed patch, I will help you change the title and content of the issue.
>> 
>> Have changed just now! And please wait for a formal reviewer to review this path.
>
>> > Seems good. If nobody disagrees such mixed patch, I will help you change the title and content of the issue.
>> 
>> Have changed just now! And please wait for a formal reviewer to review this path.
> 
> Thanks so much!!!

> @Korov I did a round of testing and results came back green. You're good to go. The SecurityManager has been deprecated for removal, so maybe it would be better to stay away from SecurityManager related classes from now on unless there some strong reason to make a change.

Thanks for your friendly reminder.

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

PR Comment: https://git.openjdk.org/jdk/pull/18086#issuecomment-1989390863


From duke at openjdk.org  Tue Mar 12 15:58:22 2024
From: duke at openjdk.org (Korov)
Date: Tue, 12 Mar 2024 15:58:22 GMT
Subject: Integrated: 8312444: Delete unused parameters and variables in
 SocketPermission
In-Reply-To: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
References: <FS3iAoRJSEtirfMGeXK1kvreJJutZZsFeQ_WTzvatqs=.a0f9def0-0852-407b-8364-eda42b96941c@github.com>
Message-ID: <EZj-MV5cU-X3YxtMov8aFmNlAlilTrnvA0km77YcTZs=.69758ce3-8b0f-494f-b870-dd7f38597e4b@github.com>

On Fri, 1 Mar 2024 17:35:35 GMT, Korov <duke at openjdk.org> wrote:

> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
> 
> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and `SocketPermission.authorizedIPv6`.
> 
> Parameter 'action' must be not empty so `a.length > 0`, the check `a.length - 1 < 0` can be removed.

This pull request has now been integrated.

Changeset: 379ad1fb
Author:    Korov <korov9 at 163.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/379ad1fbb4432c044912139e3d4e897988a341fa
Stats:     24 lines in 1 file changed: 0 ins; 9 del; 15 mod

8312444: Delete unused parameters and variables in SocketPermission

Reviewed-by: gli, aturbanov, dfuchs

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

PR: https://git.openjdk.org/jdk/pull/18086


From prajwal.kumaraswamy at oracle.com  Wed Mar  6 05:05:01 2024
From: prajwal.kumaraswamy at oracle.com (Prajwal Kumaraswamy)
Date: Wed, 6 Mar 2024 05:05:01 +0000
Subject: Request to review MR 17742
Message-ID: <PH0PR10MB70624D2175CDBCCDF0E7C20D8E212@PH0PR10MB7062.namprd10.prod.outlook.com>

Hi All,

Can anyone please review this MR https://github.com/openjdk/jdk/pull/17742

Thanks,
Prajwal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240306/84538de3/attachment.htm>

From karl.scheibelhofer.75 at gmail.com  Sat Mar  9 16:09:28 2024
From: karl.scheibelhofer.75 at gmail.com (Karl Scheibelhofer)
Date: Sat, 9 Mar 2024 17:09:28 +0100
Subject: [External] : Re: PEM API github repo
In-Reply-To: <CACSnhuU42nCK3kq1MTxavASOeW_gh_2e5m1=KJ41wy+JEpQ7hg@mail.gmail.com>
References: <d8f11a64-9159-4bb4-83a3-30147886e0be@oracle.com>
 <CAMrH03J=wX-1Kp+LVasv0-R-NEWBy31_dkb+v4CFNXoksJRfwQ@mail.gmail.com>
 <9c42dd2d-00a2-470f-b319-c2cfb7c10de6@oracle.com>
 <CACSnhuU42nCK3kq1MTxavASOeW_gh_2e5m1=KJ41wy+JEpQ7hg@mail.gmail.com>
Message-ID: <CACSnhuVUohWjR-WeiCQBBfB81M=322e7fikHznBF8RirGR+Gkg@mail.gmail.com>

... try again from from my subscribed mail account...

Hi Tony,
>
> in my jdk fork, I created a branch named pem-feedback-karl.
>
> https://github.com/KarlScheibelhofer/jdk/tree/pem-feedback-karl
>
> It is based on the pem branch of your jdk fork.
> In this pem-feedback-karl branch, I did some cleanup without changing
> the API. Your tests pass as before.
>
> My original pem-keystore implementation for the SUN provider is in this
> branch
>
> https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore
>
> It did not use the PEM API.
>
> In the branch
>
> https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore-pem-api
>
> I modified the PEM keystore implementation to use the PEMDecoder and
> PEMEncoder.
> To make it pass all tests, I had to fix some issues with the PEM api:
>
> * fix missing line-breaks when encoding certificates (and CRLs)
> * use uniform line length for PEM encoding keys and certificates
>
> During this work, I took some notes regarding the PEM api:
>
> * Consider decoupling the raw PEM encoding and decoding from
> SecurityObject.
>   This would make the API usable for general purpose PEM encoding and
> decoding, not just for keys and certificates, as it is now.
>
> * For this PEM keystore implementation it is essential to parse the
> preceding explanatory text lines.
>   The PEM decoder should support this.
>   As it is now, the keystore implementation must parse the PEM objects
> itself, including reading PEM header and footer lines.
>   Having to handle half the work in the application diminishes the
> value of the PEMDecoder.
>   It only delegates the decoding of certificates and keys to the
> PEMDecoder.
>
> * PEMDecoder should be able to handle or pass through unknown PEM
> objects gracefully.
>   Otherwise the application has to check the PEM labels in advance
> itself, which does not make sense.
>
> * Though supporting InputStream/OutputStream for reading and writing
> makes sense,
>   supporting Reader/Writer feels even more essential for robust
> support for all character encodings.
>   Multi-Byte character encodings won't work with InputStream/OutputStream.
>
> * The standard line separator for PEM is "\r\n".
>   For PEM files stored in a typical linux file system, "\n" is
> typically used, however.
>   See the output of openssl, for example.
>   Because there are still several command line utilities that do not
> work well with "\r\n" line breaks.
>   Supporting a different line-separator than "\r\n" is a good idea in
> my opinion.
>   Base64.getMimeEncoder also supports selecting a custom line separator.
>
> * The PEMEncoder encodes the predefined SecurityObjects only.
>   There is no way to use it to PEM encoded any other type of object.
>   Consider opening a path to generic use.
>
> * If an application has a DER encoded certificate, it has to decode
> and parse the certificate before
>   it can encode it using PEMEncoder.
>   This is inconvenient.
>
> * PEMEncoder uses 64 characters as line length for private and public keys,
>   and 76 characters for certificates.
>   Use the same line length for all types by default.
>   Consider adding support for selecting a custom line length.
>   Base64.getMimeEncoder also supports selecting a line custom length.
>
> I hope this helps advancing the PEM efforts.
>
> Best regards, Karl
>
> On Thu, Jan 25, 2024 at 10:02?PM Anthony Scarpino
> <anthony.scarpino at oracle.com> wrote:
> >
> >
> > On 1/25/24 9:20 AM, Daniel Jeli?ski wrote:
> > > Hi Tony,
> > > Thanks for the links! The API looks very promising.
> > >
> > > Out of curiosity, why aren't you using the Base64 MIME
> > > encoder/decoder? They are supposed to produce/remove the newline
> > > characters.
> >
> > I can look it over again.  I had inconsistencies during testing with
> > expected data and returned data.
> >
> > > The relationship between the byte[] and String data should be
> > > specified. Base64 explicitly specifies that the String APIs are
> > > translated to the byte[] APIs with ISO 8859-1 encoding. The PEMDecoder
> > > is currently using the default charset, which might produce
> > > interesting results if the charset is set to EBCDIC. The encoder is
> > > using UTF-8, which is reasonable, but given that the produced output
> > > will always be ASCII, ISO 8859-1 will perform better.
> >
> > That's fine
> >
> > > There's a disparity between the decoder and the encoder APIs; both
> > > work with strings, but Decoder accepts InputStream and not arrays, and
> > > Encoder produces byte arrays, but does not work with streams. This
> > > should be more uniform. I like Decoder's InputStream support (that's
> > > currently the only way to read multiple CA certificates from a single
> > > file - the String overload currently only returns the first one), so
> > > I'd add OutputStream support to Encoder for parity.
> >
> > I don't see parity as a requirement.  I see encoding and decoding as
> > having unique requirements.  Decoding from a file or InputStream makes
> > sense.  A decode(byte[]) method didn't seem necessary as I felt it
> > unlikely a user would have a single byte[] with PEM data.  They were
> > more likely to have a String or an InputStream.  The developer can wrap
> > it with ByteArrayInputStream or String(byte[], Charset), which is what a
> > public API method would do internally.
> >
> > Encoding is a single operation on an object.  Pass in a SecurityObject
> > and PEM data is returned.  Returning a byte[] is the most flexible
> > without creating more methods.  In the case where meta data is
> > in-between the PEM or some other data formatting.
> >
> > Why should the API have an OutputStream method, something like:
> >    pem.encodeToOutputStream(so, outputstream);
> > when the API as written today, the developer can use:
> >    outputstream.writeBytes(pem.encode(obj));
> >
> > I don't like to add API methods just for symmetry, they need to have a
> > compelling reason.  I have not seen that in the OutputStream case.
> >
> >
> > > Karl's earlier
> > > suggestion to support Stream<SecurityObject> also makes a lot of
> > > sense.
> > I haven't counted out Stream, I just haven't seen a compelling reason.
> > My tests use stream() from an array list of PEM strings.  But I haven't
> > seen the situation where the API needs stream support that couldn't be
> > done in a different way.  This is a preview JEP, and we still have time.
> >   If there is a compelling example, point it out to me.
> >
> > > I'm not a big fan of the non-static factory methods
> > > withEncryption/withDecryption/withFactory. The problem with non-static
> > > methods that return an instance of the same type is that you need to
> > > check the documentation to know if the method returns a new instance
> > > or if it mutates the current one. Can we use static factory methods
> > > instead? Either that, or create a builder class.
> >
> > The API states the classes are immutable which was a big requirement and
> > it why it's stated all over the docs.  A builder class was considered
> > early in the API development, but it was too much complication for a few
> > optional cases where the developer may need to specify details like
> > encryption or a factory.  The API has the builder idea, without the
> > extra builder construction methods.  I don't see how a static factory
> > method fit here.
> >
> > > I don't like the PEMEncoder.withEncryption API. It's not predictable
> > > enough; when encoding data, it's not consistent between writing
> > > unencrypted data (certificate, crl), throwing (PublicKey,
> > > EncryptedPrivateKeyInfo) and writing encrypted data (unencrypted
> > > private keys). The alternative of forcing the users to encrypt using
> > > EncryptedPrivateKeyInfo looks better to me.
> >
> > That was a design decision to make the API easier to use.  The
> > non-security export does not need to be burden with understanding
> > EncryptedPrivateKeyInfo.
> >
> > The API can be consistent if you choose to only pass in
> > EncryptedPrivateKeyInfo and not set withEncryption().  If an
> > ArrayList<SecurityObject> encodes with a stream(), it is nice to
> > configure encryption for private keys and still encode public keys and
> > certificates with the same encoder.
> >
> >
> > > I'd love to see support for the OpenSSL private key formats; it seems
> > > that RSAPrivateCrtKeyImpl already supports PKCS#1 format, so it may be
> > > just a matter of exposing that functionality. Other key types like EC
> > > might need more work. That might be added later after the API is
> > > finalized.
> >
> > OpenSSL 3.0 is transitioning away from their format to PKCS#8.  It is an
> > obsoleted format.  While I have thought about decoding support of RSA
> > PKCS#1 for compatibility, I have no intention to support OpenSSL or
> > PKCS#1 encoding with this PEM API.
> >
> > If someone is interested in old OpenSSL or other encoding formats, that
> > is why the Encoder and Decoder interfaces are included.  To give a
> > structure for developing other encoding.
> >
> > >
> > > Thanks,
> > > Daniel
> > >
> > > ?r., 24 sty 2024 o 22:24 Anthony Scarpino
> > > <anthony.scarpino at oracle.com> napisa?(a):
> > >>
> > >> Hi,
> > >>
> > >> The following github link is to the PEM API as it is written in the
> > >> draft JEP (https://openjdk.org/jeps/8300911).  There has been a few
> > >> changes since the original posting.
> > >>
> > >>
> https://urldefense.com/v3/__https://github.com/ascarpino/jdk/tree/pem__;!!ACWV5N9M2RV99hQ!NmZu22NrC2hxWJuqLHZ6l1C0KYVK0Qf_rV7tV-1uLqUb_5sFMJXyCCKVPjmEmGCeQ6US2RJquDm9AJqZXO46ju8Q$
> > >>
> > >> The Encoder and PEMEncoder to now return byte[] for the encode()
> method.
> > >>    A new PEMEncoder method, encodeToString(), was added.  I believe
> these
> > >> make it easier for outputting data to a file and InputStreams, while
> > >> still supporting a method that returns a String.
> > >>
> > >> For decode, InputStream has replaced Reader.  There were comments
> > >> preferring InputStream and I found that Reader's buffering quirks were
> > >> problematic. Decoding from a byte[] is easy through an
> ByteArrayInputStream.
> > >>
> > >> If you are interested in testing out the API, please download and
> > >> compile the repo.  Then let me know how your experience went.
> > >>
> > >> thanks
> > >>
> > >> Tony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240309/e69fbe15/attachment.htm>

From valeriep at openjdk.org  Tue Mar 12 18:15:15 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 12 Mar 2024 18:15:15 GMT
Subject: RFR: 8325164: Named groups and signature schemes unavailable with
 SunPKCS11 in FIPS mode [v2]
In-Reply-To: <k-Z3z2anZtsVOjA_cwnmBIvT7eDRktrIP44aAzEkIIg=.fe038e66-6ce9-4331-92e7-fa09ef8c8333@github.com>
References: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
 <k-Z3z2anZtsVOjA_cwnmBIvT7eDRktrIP44aAzEkIIg=.fe038e66-6ce9-4331-92e7-fa09ef8c8333@github.com>
Message-ID: <EoQ8g32HAmf3QTDoMXAUmZnUAUiMNlpxH4pwu3GkaAI=.118cfac3-51ea-4e1c-883c-97d4939f7bb8@github.com>

On Thu, 7 Mar 2024 12:40:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently the SunPKCS11 provider requires other providers in order to offer ECDHE, FFDHE and RSA-PSS in TLS handshakes:
>> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
>> - ECDHE requires the SunEC provider to be installed
>> - RSA-PSS requires RSASSA-PSS AlgorithmParameters from SunRsaSign
>> 
>> This PR removes these dependencies: 
>> - SunPKCS11 is modified to offer the PSS and DH AlgorithmParameters (using the same implementation classes as the original providers)
>> - Elliptic curve code is modified to remove the dependency on SunEC provider where possible
>> 
>> Two existing tests were modified to verify the changes:
>> - SigInteropPSS2 test was modified to install SunPKCS11 provider and remove SunRsaSign provider
>> - FipsModeTLS12 test was modified to verify the list of NamedGroups available on a SSLEngine.
>> 
>> Both modified tests fail without the changes, pass with them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore original SunEC behavior

test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java line 56:

> 54:         Provider sunRsaSign = Security.getProvider("SunRsaSign");
> 55:         Security.removeProvider("SunRsaSign");
> 56:         Security.insertProviderAt(p, 1);

IIRC, the getInstance() call always specify which provider, why do we need to insert the provider to position 1?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17816#discussion_r1521923378


From mullan at openjdk.org  Tue Mar 12 19:10:16 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Mar 2024 19:10:16 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
Message-ID: <leVNLEnlMOT_Q12vSYN1zBocFXWkf2eoJQrj_GYXqTs=.74126c7c-6afb-483b-98e2-f8666849c3da@github.com>

On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MBeanServerFileAccessController.java

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 55:

> 53:         Subject.callAs(subject, () -> check(0, Subject.current(), "Duke"));
> 54: 
> 55:         // Observable in the same thread in ACC mode, but not in the SV mode

Should this comment actually say "Observable in a new platform thread in ACC mode, but not in the SV mode".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1521991975


From djelinski at openjdk.org  Tue Mar 12 20:18:37 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Mar 2024 20:18:37 GMT
Subject: RFR: 8325164: Named groups and signature schemes unavailable with
 SunPKCS11 in FIPS mode [v3]
In-Reply-To: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
References: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
Message-ID: <R_dNMtGLiXpjwOAXgpSMM7duJatENHy-zaOXgthF78w=.ebd48499-a4b6-414c-a3af-dc38f3bfca06@github.com>

> Currently the SunPKCS11 provider requires other providers in order to offer ECDHE, FFDHE and RSA-PSS in TLS handshakes:
> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
> - ECDHE requires the SunEC provider to be installed
> - RSA-PSS requires RSASSA-PSS AlgorithmParameters from SunRsaSign
> 
> This PR removes these dependencies: 
> - SunPKCS11 is modified to offer the PSS and DH AlgorithmParameters (using the same implementation classes as the original providers)
> - Elliptic curve code is modified to remove the dependency on SunEC provider where possible
> 
> Two existing tests were modified to verify the changes:
> - SigInteropPSS2 test was modified to install SunPKCS11 provider and remove SunRsaSign provider
> - FipsModeTLS12 test was modified to verify the list of NamedGroups available on a SSLEngine.
> 
> Both modified tests fail without the changes, pass with them. Other tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Use explicit provider in PSS engineGetParameters
 - Merge remote-tracking branch 'origin' into pkcs11-parameters
 - Restore original SunEC behavior
 - Update remaining ECUtil usages
 - Update copyright and bugids
 - Reduce SunEC dependencies
 - Add DiffieHellman parameters
 - Add RSASSA-PSS AlgorithmParameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17816/files
  - new: https://git.openjdk.org/jdk/pull/17816/files/09ac283d..f39d4d5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17816&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17816&range=01-02

  Stats: 124621 lines in 2707 files changed: 26343 ins; 86836 del; 11442 mod
  Patch: https://git.openjdk.org/jdk/pull/17816.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17816/head:pull/17816

PR: https://git.openjdk.org/jdk/pull/17816


From djelinski at openjdk.org  Tue Mar 12 20:18:37 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Mar 2024 20:18:37 GMT
Subject: RFR: 8325164: Named groups and signature schemes unavailable with
 SunPKCS11 in FIPS mode [v2]
In-Reply-To: <EoQ8g32HAmf3QTDoMXAUmZnUAUiMNlpxH4pwu3GkaAI=.118cfac3-51ea-4e1c-883c-97d4939f7bb8@github.com>
References: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
 <k-Z3z2anZtsVOjA_cwnmBIvT7eDRktrIP44aAzEkIIg=.fe038e66-6ce9-4331-92e7-fa09ef8c8333@github.com>
 <EoQ8g32HAmf3QTDoMXAUmZnUAUiMNlpxH4pwu3GkaAI=.118cfac3-51ea-4e1c-883c-97d4939f7bb8@github.com>
Message-ID: <FzvYnDO5BgFBo1x6x5vcNW6cmEEY70Kzi2mHWmUNU08=.9893a644-36b2-434e-ac63-a9b32652d799@github.com>

On Tue, 12 Mar 2024 18:12:07 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore original SunEC behavior
>
> test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java line 56:
> 
>> 54:         Provider sunRsaSign = Security.getProvider("SunRsaSign");
>> 55:         Security.removeProvider("SunRsaSign");
>> 56:         Security.insertProviderAt(p, 1);
> 
> IIRC, the getInstance() call always specify which provider, why do we need to insert the provider to position 1?

It was needed because engineGetParameters did not specify provider; I fixed that and removed this line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17816#discussion_r1522059723


From mbalao at redhat.com  Tue Mar 12 21:25:40 2024
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 12 Mar 2024 17:25:40 -0400
Subject: New Draft of the KDF JEP for the Java Platform
In-Reply-To: <BD91A6D7-EEFC-44ED-A713-DA9AAEBC9413@oracle.com>
References: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
 <BD91A6D7-EEFC-44ED-A713-DA9AAEBC9413@oracle.com>
Message-ID: <141de06f-d12c-4f9e-8a22-5d2b277b4134@redhat.com>

Hi Kevin,

When looking at the proposed API, I noticed that the length of a derived 
key or data can be potentially passed both as part of a KDFParameterSpec 
and as a KDF::deriveKey or KDF::deriveData parameter. This is the case 
for HKDF (HKDFParameterSpec) apparently. Having a length value on two 
places makes me think about all the possible combinations. By just 
reading the API, one cannot tell what could happen if values were 
different. It may be handled by the KDF class implementation or passed 
through to the SPI. One interpretation is that the length parameter (if 
valid) enforces a maximum to the output value in HKDFParameterSpec, and 
an error is thrown if the latter is smaller than the former. However, 
one of them could be invalid and that could lead to an error. Another 
interpretation would be that there is a check preventing these values to 
be different. I would like to hear your thoughts on this issue. Perhaps 
it is worth exploring a way to remove ambiguity or adding a note to the 
JEP. E.g. do we need to specify a len parameter or can we leave it for 
KDFParameterSpec to specify it and the key is built consuming all the 
output generated? Does it make sense to generate more output than what 
we are going to consume for a key? Looks like the extra output will be lost.

For some security providers, it may be interesting to keep state between 
KDF::deriveKey or KDF::deriveData calls in the HKDF algorithm, 
particularly during the expansion phase. For example, PKCS #11 providers 
will need the PRK as a key ID for the native C_DeriveKey call. If the 
HKDFParameterSpec forces the PRK to be a byte[], then each expansion 
call pays the cost of creating the key again in the token. This 
observation was made by @Francisco (on CC). Will the KDF class enforce 
the use of well-known KDFParameterSpec implementations such as 
HKDFParameterSpec or will it be open to each provider ?e.g. 
engineGetParameters type of API?? In the latter case, will the call from 
JSSE be such that we can keep/carry state between extraction and expansion?

Thanks,
Martin.-


On 3/1/24 16:08, Kevin Driver wrote:
> Hi All,
> 
> As discussed a few months ago [1], we are working on providing a new API 
> for KDF (Key Derivation Functions). There will be a KDF class for users, 
> a KDFSpi class for security providers, and several other parameter 
> classes. We plan to add support for HKDF (RFC-5869).
> 
> For more details, see the updated draft JEP at: 
> https://openjdk.org/jeps/8189808 <https://openjdk.org/jeps/8189808>
> 
> As before, we look forward to your feedback on the proposal.
> 
> [1] 
> https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html 
> <https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html>
> 
> Thanks,
> 
> image001.png
> Kevin Driver
> Java Security Libraries
> 



From horvath.peter.gergely at gmail.com  Tue Mar 12 21:35:06 2024
From: horvath.peter.gergely at gmail.com (=?UTF-8?Q?Horv=C3=A1th_P=C3=A9ter_Gergely?=)
Date: Tue, 12 Mar 2024 22:35:06 +0100
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <9C2E4C1B-FDB2-4A18-B9FF-235D45EDF28E@oracle.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
 <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
 <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>
 <63B2990C-522D-472B-BB9C-6007CBF9B55E@oracle.com>
 <9C2E4C1B-FDB2-4A18-B9FF-235D45EDF28E@oracle.com>
Message-ID: <CA+UsspCcVBFRH4xHEUJg86ztNM-FnP3SKUX8rXTLs1TpA7fvdQ@mail.gmail.com>

Hi Weijun,

That is brilliant, thank you. Do we have any developer documentation for
sun.security.util.Debug (apart from the code ;) )?

Thinking about this raises the question: wouldn't it be possible to have
these components emit Flight Recorder events as well?
I understand this is a dubious topic, as some arguments contain secrets,
but it would be interesting to know.
Maybe restricting FR events when security debug logging is enabled anyways
would be an option?

Best,
Peter


Wei-Jun Wang <weijun.wang at oracle.com> ezt ?rta (id?pont: 2024. m?rc. 11.,
H, 16:40):

> In fact, I've started working on it, see
> https://github.com/openjdk/jdk/pull/18199.
>
> --Weijun
>
> > On Mar 11, 2024, at 9:21?AM, Wei-Jun Wang <weijun.wang at oracle.com>
> wrote:
> >
> > I've filed https://bugs.openjdk.org/browse/JDK-8327818.
> >
> > But first, in order to make sure the debug option in Krb5LoginModule and
> other JGSS/krb5-related system properties still work, there needs a way to
> instantiate a Debug object without providing the `-Djava.security.debug`
> system property.
> >
> > For example, in Krb5LoginModule, currently we have
> >
> >       boolean debug =
> "true".equalsIgnoreCase((String)options.get("debug"));
> >
> > And I'm thinking of
> >
> >       Debug debug = Debug.of("krb5loginmodule",
> (String)options.get("debug"));
> >
> > Hopefully this .of() method can automatically support thread info or
> timestamp if the "debug" option has it.
> >
> > Also, I am wondering if even without he "debug" option, user can set
> -Djava.security.debug=krb5loginmodule to show debug info there. However,
> some krb5 debug info might contain sensitive information like passwords or
> secret keys, so maybe there is a little danger to cover them with
> `-Djava.security.debug=all`.
> >
> > Thanks,
> > Weijun
> >
> >
> >> On Mar 11, 2024, at 5:43?AM, Sean Coffey <sean.coffey at oracle.com>
> wrote:
> >>
> >>
> >> On 10/03/2024 16:01, Wei-Jun Wang wrote:
> >>> Hi Se?n,
> >>>
> >>> I know you are working on enhancing the security debug output with
> timestamps and thread info now. Do you think it can also cover Kerberos?
> >> I'd love to see Kerberos fall under the same debug implementation used
> by other JDK security libraries. I suspect it was a standalone product a
> long time back and had its own debug impl as a result. I'd like to see it
> worked separate to the ongoing decorator work that's taking place via
> JDK-8051959. The debug stack for krb5 is different and managed via a Map
> currently. Maybe Peter could start out by moving the debug output from
> System.out calls to the sun.security.util.Debug calls as suggested.
> >>
> >> Using a Logger should be on the radar also. We'd have to use the
> System.Logger interface since that's the only one guaranteed to be present
> in the runtime. Maybe the Logger work can be done as a follow on task. I'm
> also examining the potential for wider use of Logger in security libs. The
> TLS javax.net.debug option already offers use of a Logger but the
> configuration in both the calling code and backend remains a blocker to
> adoption IMO. (e.g. no option to configure Level correctly and static
> backend configuration options may not be set up correctly at the time
> logger output becomes necessary to debug an issue)
> >>
> >> regards,
> >> Sean.
> >>
> >>>
> >>> Traditionally, Kerberos debugging is independent of other security
> areas and itself is quite complicated. It includes the "debug" label in
> JAAS LoginModule (as Peter pointed out below) and separate system
> properties like sun.security.krb5.debug, sun.security.jgss.debug,
> sun.security.nativegss.debug, and sun.security.spnego.debug. It will be
> definitely great if they can enjoy the enhancement of
> sun.security.util.Debug.
> >>>
> >>> BTW, Peter also mentioned a JUL logger. IIUC, our current debug
> messages are only sent to System.err, right?
> >>>
> >>> Thanks,
> >>> Weijun
> >>>
> >>>
> >>>
> >>>> On Mar 9, 2024, at 4:15?PM, Horv?th P?ter Gergely <
> horvath.peter.gergely at gmail.com> wrote:
> >>>>
> >>>> Dear All,
> >>>>
> >>>> In the past, I had issues with debug logging in Krb5LoginModule: if
> debug is enabled,
> >>>> messages are simply written to the stdout. It is relatively hard to
> correlate these
> >>>> messages with application logs, as there are no timestamps for
> Krb5LoginModule output messages.
> >>>>
> >>>> Imagine a server fails to service a request, due to its failure to
> communicate with
> >>>> another Kerberized server. The failure itself will be logged
> properly, but there is no way
> >>>> for an operator to easily find and correlate Krb5LoginModule debug
> output.
> >>>> (We are talking about servers unders heavy load)
> >>>>
> >>>> I think debug logging in Krb5LoginModule should be improved; e.g. at
> least, messages
> >>>> should be sent to both stdout and a JUL logger maybe?
> >>>>
> >>>> I would be happy to implement the code change if someone is willing
> to sponsor this issue.
> >>>>
> >>>> Could someone please help here?
> >>>>
> >>>> Thanks,
> >>>> Peter
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240312/cc69f42d/attachment.htm>

From kevin.driver at oracle.com  Tue Mar 12 21:52:39 2024
From: kevin.driver at oracle.com (Kevin Driver)
Date: Tue, 12 Mar 2024 21:52:39 +0000
Subject: [External] : Re: New Draft of the KDF JEP for the Java Platform
In-Reply-To: <141de06f-d12c-4f9e-8a22-5d2b277b4134@redhat.com>
References: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
 <BD91A6D7-EEFC-44ED-A713-DA9AAEBC9413@oracle.com>
 <141de06f-d12c-4f9e-8a22-5d2b277b4134@redhat.com>
Message-ID: <1C401C42-0869-48FF-8780-55915B072F81@oracle.com>

Hi Martin.

To be brief, we will be removing the length parameter from the deriveKey arguments list. There was some thought that there may be a use-case where the caller would not want to use all the generated entropy, but at this time, we have no valid use-case for this in the current API design.

This version of the API reflects our intention for a stateless API design (or put another way, that the ?deriveKey/deriveData? calls are one-and-done operations).

As for the PKCS#11 questions you pose:

1) The PRK is not required to be a byte[]. We have considered the PKCS#11 case, and the caller will not need to re-derive the PRK each time.

2) Furthermore, state does not need to be maintained between calls to the deriveKey/deriveData methods, since the parameters from an extract (including the PRK) can be passed to any successive expand calls.

Perhaps it will be helpful/demonstrative for us to include some finer details about the HKDFParameterSpec class in the JEP write-up.

More soon.

Thanks!

[image001.png]
Kevin Driver
Mobile: +1.512.431.5690
Java Security Libraries

On Mar 12, 2024, at 4:25?PM, Martin Balao <mbalao at redhat.com> wrote:

Hi Kevin,

When looking at the proposed API, I noticed that the length of a derived key or data can be potentially passed both as part of a KDFParameterSpec and as a KDF::deriveKey or KDF::deriveData parameter. This is the case for HKDF (HKDFParameterSpec) apparently. Having a length value on two places makes me think about all the possible combinations. By just reading the API, one cannot tell what could happen if values were different. It may be handled by the KDF class implementation or passed through to the SPI. One interpretation is that the length parameter (if valid) enforces a maximum to the output value in HKDFParameterSpec, and an error is thrown if the latter is smaller than the former. However, one of them could be invalid and that could lead to an error. Another interpretation would be that there is a check preventing these values to be different. I would like to hear your thoughts on this issue. Perhaps it is worth exploring a way to remove ambiguity or adding a note to the JEP. E.g. do we need to specify a len parameter or can we leave it for KDFParameterSpec to specify it and the key is built consuming all the output generated? Does it make sense to generate more output than what we are going to consume for a key? Looks like the extra output will be lost.

For some security providers, it may be interesting to keep state between KDF::deriveKey or KDF::deriveData calls in the HKDF algorithm, particularly during the expansion phase. For example, PKCS #11 providers will need the PRK as a key ID for the native C_DeriveKey call. If the HKDFParameterSpec forces the PRK to be a byte[], then each expansion call pays the cost of creating the key again in the token. This observation was made by @Francisco (on CC). Will the KDF class enforce the use of well-known KDFParameterSpec implementations such as HKDFParameterSpec or will it be open to each provider ?e.g. engineGetParameters type of API?? In the latter case, will the call from JSSE be such that we can keep/carry state between extraction and expansion?

Thanks,
Martin.-


On 3/1/24 16:08, Kevin Driver wrote:
Hi All,
As discussed a few months ago [1], we are working on providing a new API for KDF (Key Derivation Functions). There will be a KDF class for users, a KDFSpi class for security providers, and several other parameter classes. We plan to add support for HKDF (RFC-5869).
For more details, see the updated draft JEP at: https://openjdk.org/jeps/8189808 <https://openjdk.org/jeps/8189808>
As before, we look forward to your feedback on the proposal.
[1] https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html <https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html>
Thanks,
image001.png
Kevin Driver
Java Security Libraries


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240312/191f919d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6346 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240312/191f919d/image001.png>

From valeriep at openjdk.org  Tue Mar 12 22:11:13 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 12 Mar 2024 22:11:13 GMT
Subject: RFR: 8325164: Named groups and signature schemes unavailable with
 SunPKCS11 in FIPS mode [v2]
In-Reply-To: <k-Z3z2anZtsVOjA_cwnmBIvT7eDRktrIP44aAzEkIIg=.fe038e66-6ce9-4331-92e7-fa09ef8c8333@github.com>
References: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
 <k-Z3z2anZtsVOjA_cwnmBIvT7eDRktrIP44aAzEkIIg=.fe038e66-6ce9-4331-92e7-fa09ef8c8333@github.com>
Message-ID: <Pb_-uhC2bKWv45XlRfUW2SuDABBJM8QGxvZyAKMdXkk=.65e031f2-6feb-4601-98e3-1192dd01bc38@github.com>

On Thu, 7 Mar 2024 12:40:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently the SunPKCS11 provider requires other providers in order to offer ECDHE, FFDHE and RSA-PSS in TLS handshakes:
>> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
>> - ECDHE requires the SunEC provider to be installed
>> - RSA-PSS requires RSASSA-PSS AlgorithmParameters from SunRsaSign
>> 
>> This PR removes these dependencies: 
>> - SunPKCS11 is modified to offer the PSS and DH AlgorithmParameters (using the same implementation classes as the original providers)
>> - Elliptic curve code is modified to remove the dependency on SunEC provider where possible
>> 
>> Two existing tests were modified to verify the changes:
>> - SigInteropPSS2 test was modified to install SunPKCS11 provider and remove SunRsaSign provider
>> - FipsModeTLS12 test was modified to verify the list of NamedGroups available on a SSLEngine.
>> 
>> Both modified tests fail without the changes, pass with them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore original SunEC behavior

Looks good; just have a minor question in one test.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17816#pullrequestreview-1932802144


From mbalao at redhat.com  Tue Mar 12 22:34:50 2024
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 12 Mar 2024 18:34:50 -0400
Subject: [External] : Re: New Draft of the KDF JEP for the Java Platform
In-Reply-To: <1C401C42-0869-48FF-8780-55915B072F81@oracle.com>
References: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
 <BD91A6D7-EEFC-44ED-A713-DA9AAEBC9413@oracle.com>
 <141de06f-d12c-4f9e-8a22-5d2b277b4134@redhat.com>
 <1C401C42-0869-48FF-8780-55915B072F81@oracle.com>
Message-ID: <164e2fde-039e-4886-b91f-dcbeca0a421a@redhat.com>

Hi Kevin,

Thanks for your quick response.

On 3/12/24 17:52, Kevin Driver wrote:
> To be brief, we will be removing the length parameter from the deriveKey 
> arguments list. There was some thought that there may be a use-case 
> where the caller would not want to use all the generated entropy, but at 
> this time, we have no valid use-case for this in the current API design.

Makes sense.

> 
> This version of the API reflects our intention for a stateless API 
> design (or put another way, that the ?deriveKey/deriveData? calls are 
> one-and-done operations).
> 
> As for the PKCS#11 questions you pose:
> 
> 1) The PRK is not required to be a byte[]. We have considered the 
> PKCS#11 case, and the caller will not need to re-derive the PRK each time.
> 
> 2) Furthermore, state does not need to be maintained between calls to 
> the deriveKey/deriveData methods, since the parameters from an extract 
> (including the PRK) can be passed to any successive expand calls.

As I understand it, it's not that state is not maintained but that we 
are keeping it on the parameters side. For example, a extraction phase 
call will generate a PRK that will be kept in the parameters side for 
the following expansion phase calls.

> 
> Perhaps it will be helpful/demonstrative for us to include some finer 
> details about the HKDFParameterSpec class in the JEP write-up.
>

That would be appreciated, as we are exploring a SunPKCS11 
implementation ?I am not sure if you got the chance to see my email on 
that regard?.

Thanks,
Martin.-


> More soon.
> 
> Thanks!
> 
> image001.png
> Kevin Driver
> Mobile: +1.512.431.5690
> Java Security Libraries
> 
>> On Mar 12, 2024, at 4:25?PM, Martin Balao <mbalao at redhat.com> wrote:
>>
>> Hi Kevin,
>>
>> When looking at the proposed API, I noticed that the length of a 
>> derived key or data can be potentially passed both as part of a 
>> KDFParameterSpec and as a KDF::deriveKey or KDF::deriveData parameter. 
>> This is the case for HKDF (HKDFParameterSpec) apparently. Having a 
>> length value on two places makes me think about all the possible 
>> combinations. By just reading the API, one cannot tell what could 
>> happen if values were different. It may be handled by the KDF class 
>> implementation or passed through to the SPI. One interpretation is 
>> that the length parameter (if valid) enforces a maximum to the output 
>> value in HKDFParameterSpec, and an error is thrown if the latter is 
>> smaller than the former. However, one of them could be invalid and 
>> that could lead to an error. Another interpretation would be that 
>> there is a check preventing these values to be different. I would like 
>> to hear your thoughts on this issue. Perhaps it is worth exploring a 
>> way to remove ambiguity or adding a note to the JEP. E.g. do we need 
>> to specify a len parameter or can we leave it for KDFParameterSpec to 
>> specify it and the key is built consuming all the output generated? 
>> Does it make sense to generate more output than what we are going to 
>> consume for a key? Looks like the extra output will be lost.
>>
>> For some security providers, it may be interesting to keep state 
>> between KDF::deriveKey or KDF::deriveData calls in the HKDF algorithm, 
>> particularly during the expansion phase. For example, PKCS #11 
>> providers will need the PRK as a key ID for the native C_DeriveKey 
>> call. If the HKDFParameterSpec forces the PRK to be a byte[], then 
>> each expansion call pays the cost of creating the key again in the 
>> token. This observation was made by @Francisco (on CC). Will the KDF 
>> class enforce the use of well-known KDFParameterSpec implementations 
>> such as HKDFParameterSpec or will it be open to each provider ?e.g. 
>> engineGetParameters type of API?? In the latter case, will the call 
>> from JSSE be such that we can keep/carry state between extraction and 
>> expansion?
>>
>> Thanks,
>> Martin.-
>>
>>
>> On 3/1/24 16:08, Kevin Driver wrote:
>>> Hi All,
>>> As discussed a few months ago [1], we are working on providing a new 
>>> API for KDF (Key Derivation Functions). There will be a KDF class for 
>>> users, a KDFSpi class for security providers, and several other 
>>> parameter classes. We plan to add support for HKDF (RFC-5869).
>>> For more details, see the updated draft JEP at: 
>>> https://openjdk.org/jeps/8189808 <https://openjdk.org/jeps/8189808>
>>> As before, we look forward to your feedback on the proposal.
>>> [1] 
>>> https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html 
>>> <https://mail.openjdk.org/pipermail/security-dev/2023-July/036642.html>
>>> Thanks,
>>> image001.png
>>> Kevin Driver
>>> Java Security Libraries
>>
> 



From weijun.wang at oracle.com  Wed Mar 13 01:40:25 2024
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Wed, 13 Mar 2024 01:40:25 +0000
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <CA+UsspCcVBFRH4xHEUJg86ztNM-FnP3SKUX8rXTLs1TpA7fvdQ@mail.gmail.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
 <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
 <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>
 <63B2990C-522D-472B-BB9C-6007CBF9B55E@oracle.com>
 <9C2E4C1B-FDB2-4A18-B9FF-235D45EDF28E@oracle.com>
 <CA+UsspCcVBFRH4xHEUJg86ztNM-FnP3SKUX8rXTLs1TpA7fvdQ@mail.gmail.com>
Message-ID: <DBFEE820-9D41-4647-9660-EA40A87D5046@oracle.com>



> On Mar 12, 2024, at 5:35?PM, Horv?th P?ter Gergely <horvath.peter.gergely at gmail.com> wrote:
> 
> Hi Weijun,
> 
> That is brilliant, thank you. Do we have any developer documentation for sun.security.util.Debug (apart from the code ;) )?

Probably not. The only info I know is the output of

   java -Djava.security.debug=help sun.security.util.Debug

> 
> Thinking about this raises the question: wouldn't it be possible to have these components emit Flight Recorder events as well? 
> I understand this is a dubious topic, as some arguments contain secrets, but it would be interesting to know.
> Maybe restricting FR events when security debug logging is enabled anyways would be an option?

Se?n is our expert on JFR events. He has already created some security-related events, like provider loading and security properties access. You can tell him what else you are interested in.

Thanks,
Weijun

> 
> Best,
> Peter
> 
> 
> Wei-Jun Wang <weijun.wang at oracle.com> ezt ?rta (id?pont: 2024. m?rc. 11., H, 16:40):
> In fact, I've started working on it, see https://github.com/openjdk/jdk/pull/18199.
> 
> --Weijun
> 
> > On Mar 11, 2024, at 9:21?AM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> > 
> > I've filed https://bugs.openjdk.org/browse/JDK-8327818.
> > 
> > But first, in order to make sure the debug option in Krb5LoginModule and other JGSS/krb5-related system properties still work, there needs a way to instantiate a Debug object without providing the `-Djava.security.debug` system property.
> > 
> > For example, in Krb5LoginModule, currently we have
> > 
> >       boolean debug = "true".equalsIgnoreCase((String)options.get("debug"));
> > 
> > And I'm thinking of
> > 
> >       Debug debug = Debug.of("krb5loginmodule", (String)options.get("debug"));
> > 
> > Hopefully this .of() method can automatically support thread info or timestamp if the "debug" option has it.
> > 
> > Also, I am wondering if even without he "debug" option, user can set -Djava.security.debug=krb5loginmodule to show debug info there. However, some krb5 debug info might contain sensitive information like passwords or secret keys, so maybe there is a little danger to cover them with `-Djava.security.debug=all`.
> > 
> > Thanks,
> > Weijun
> > 
> > 
> >> On Mar 11, 2024, at 5:43?AM, Sean Coffey <sean.coffey at oracle.com> wrote:
> >> 
> >> 
> >> On 10/03/2024 16:01, Wei-Jun Wang wrote:
> >>> Hi Se?n,
> >>> 
> >>> I know you are working on enhancing the security debug output with timestamps and thread info now. Do you think it can also cover Kerberos?
> >> I'd love to see Kerberos fall under the same debug implementation used by other JDK security libraries. I suspect it was a standalone product a long time back and had its own debug impl as a result. I'd like to see it worked separate to the ongoing decorator work that's taking place via JDK-8051959. The debug stack for krb5 is different and managed via a Map currently. Maybe Peter could start out by moving the debug output from System.out calls to the sun.security.util.Debug calls as suggested.
> >> 
> >> Using a Logger should be on the radar also. We'd have to use the System.Logger interface since that's the only one guaranteed to be present in the runtime. Maybe the Logger work can be done as a follow on task. I'm also examining the potential for wider use of Logger in security libs. The TLS javax.net.debug option already offers use of a Logger but the configuration in both the calling code and backend remains a blocker to adoption IMO. (e.g. no option to configure Level correctly and static backend configuration options may not be set up correctly at the time logger output becomes necessary to debug an issue)
> >> 
> >> regards,
> >> Sean.
> >> 
> >>> 
> >>> Traditionally, Kerberos debugging is independent of other security areas and itself is quite complicated. It includes the "debug" label in JAAS LoginModule (as Peter pointed out below) and separate system properties like sun.security.krb5.debug, sun.security.jgss.debug, sun.security.nativegss.debug, and sun.security.spnego.debug. It will be definitely great if they can enjoy the enhancement of sun.security.util.Debug.
> >>> 
> >>> BTW, Peter also mentioned a JUL logger. IIUC, our current debug messages are only sent to System.err, right?
> >>> 
> >>> Thanks,
> >>> Weijun
> >>> 
> >>> 
> >>> 
> >>>> On Mar 9, 2024, at 4:15?PM, Horv?th P?ter Gergely <horvath.peter.gergely at gmail.com> wrote:
> >>>> 
> >>>> Dear All,
> >>>> 
> >>>> In the past, I had issues with debug logging in Krb5LoginModule: if debug is enabled,
> >>>> messages are simply written to the stdout. It is relatively hard to correlate these
> >>>> messages with application logs, as there are no timestamps for Krb5LoginModule output messages.
> >>>> 
> >>>> Imagine a server fails to service a request, due to its failure to communicate with
> >>>> another Kerberized server. The failure itself will be logged properly, but there is no way
> >>>> for an operator to easily find and correlate Krb5LoginModule debug output.
> >>>> (We are talking about servers unders heavy load)
> >>>> 
> >>>> I think debug logging in Krb5LoginModule should be improved; e.g. at least, messages
> >>>> should be sent to both stdout and a JUL logger maybe?
> >>>> 
> >>>> I would be happy to implement the code change if someone is willing to sponsor this issue.
> >>>> 
> >>>> Could someone please help here?
> >>>> 
> >>>> Thanks,
> >>>> Peter
> > 
> 


From sean.coffey at oracle.com  Wed Mar 13 09:53:21 2024
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=C3=A1n_Coffey?=)
Date: Wed, 13 Mar 2024 09:53:21 +0000
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <DBFEE820-9D41-4647-9660-EA40A87D5046@oracle.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
 <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
 <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>
 <63B2990C-522D-472B-BB9C-6007CBF9B55E@oracle.com>
 <9C2E4C1B-FDB2-4A18-B9FF-235D45EDF28E@oracle.com>
 <CA+UsspCcVBFRH4xHEUJg86ztNM-FnP3SKUX8rXTLs1TpA7fvdQ@mail.gmail.com>
 <DBFEE820-9D41-4647-9660-EA40A87D5046@oracle.com>
Message-ID: <387c425d-6073-42f0-8cb4-6c69bc796277@oracle.com>


On 13/03/2024 01:40, Wei-Jun Wang wrote:
>> Thinking about this raises the question: wouldn't it be possible to have these components emit Flight Recorder events as well?
>> I understand this is a dubious topic, as some arguments contain secrets, but it would be interesting to know.
>> Maybe restricting FR events when security debug logging is enabled anyways would be an option?
> Se?n is our expert on JFR events. He has already created some security-related events, like provider loading and security properties access. You can tell him what else you are interested in.

Using JFR events is certainly worthy of discussion. What would those JFR 
events looks like ? Would you propose one for each log action currently 
in the krb5 code ? It becomes unmaintainable IMO.

The suggestion has also been made for the TLS logging code in the past. 
It's not trivial to convert every log entry to a JFR event. A typical 
client/server handshake in TLS can generate 1000's of lines of log 
output with -Djavax.net.debug=all enabled. It doesn't translate easily 
to JFR events. Reading text is probably easier also.

On a related note, I think the current TLS logging is too verbose at the 
moment. Over 3,500 lines of output are generated before a ClientHello 
gets created in a typical TLS debug capture. It's too much. Most of it 
is iterating over certs found in the truststore (cacerts by default). 
Need to log a bug on that.

regards,
Sean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240313/26ecddee/attachment.htm>

From weijun.wang at oracle.com  Wed Mar 13 12:52:16 2024
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Wed, 13 Mar 2024 12:52:16 +0000
Subject: [External] : Re: New Draft of the KDF JEP for the Java Platform
In-Reply-To: <164e2fde-039e-4886-b91f-dcbeca0a421a@redhat.com>
References: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
 <BD91A6D7-EEFC-44ED-A713-DA9AAEBC9413@oracle.com>
 <141de06f-d12c-4f9e-8a22-5d2b277b4134@redhat.com>
 <1C401C42-0869-48FF-8780-55915B072F81@oracle.com>
 <164e2fde-039e-4886-b91f-dcbeca0a421a@redhat.com>
Message-ID: <D6891335-5F88-41E7-9BEE-B9DE01EDE6F1@oracle.com>


> On Mar 12, 2024, at 6:34?PM, Martin Balao <mbalao at redhat.com> wrote:
> 
> As I understand it, it's not that state is not maintained but that we are keeping it on the parameters side. For example, a extraction phase call will generate a PRK that will be kept in the parameters side for the following expansion phase calls.

For an extract-once expand-multiple use case, I think you can do an extract-only deriveKey and this returns the PRK. You can then use this PRK to do multiple expand-only deriveKeys. There is no need to store the PRK inside the params after the 1st step. Or, are you worrying about the PRK been leaked?

Thanks,
Weijun


From duke at openjdk.org  Wed Mar 13 14:47:18 2024
From: duke at openjdk.org (MustavData)
Date: Wed, 13 Mar 2024 14:47:18 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <pB624-FX0mgCwNPwFRg6nV1z8xXBPQYgsxosL31c_X0=.0a4455cb-49fe-45c0-aaf6-c97ef19c6656@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

@stepan-atypon-com : This looks like a helpful comment.   But as your first comment on Github,
no one can see it until you return to that page and check the box indicated
you agree to the terms of use.    Then everyone can view your posting.   :-)


On Tue, Mar 5, 2024 at 2:54?AM Stepan Schejbal ***@***.***>
wrote:

> I have encountered another related problem on one of my customer systems -
> signing with some private keys fails when non-administrator account is
> used. I will add another patch after some more testing.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/16687#issuecomment-1978248822>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BFUF6UIAATCKRDBLNIR3LK3YWWB3JAVCNFSM6AAAAAA7OBIQAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZYGI2DQOBSGI>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1994560230


From mbalao at redhat.com  Wed Mar 13 15:23:56 2024
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 13 Mar 2024 11:23:56 -0400
Subject: [External] : Re: New Draft of the KDF JEP for the Java Platform
In-Reply-To: <D6891335-5F88-41E7-9BEE-B9DE01EDE6F1@oracle.com>
References: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
 <BD91A6D7-EEFC-44ED-A713-DA9AAEBC9413@oracle.com>
 <141de06f-d12c-4f9e-8a22-5d2b277b4134@redhat.com>
 <1C401C42-0869-48FF-8780-55915B072F81@oracle.com>
 <164e2fde-039e-4886-b91f-dcbeca0a421a@redhat.com>
 <D6891335-5F88-41E7-9BEE-B9DE01EDE6F1@oracle.com>
Message-ID: <a9e381b9-a483-4dae-9721-396f723b02a3@redhat.com>

On 3/13/24 08:52, Wei-Jun Wang wrote:
> 
>> On Mar 12, 2024, at 6:34?PM, Martin Balao <mbalao at redhat.com> wrote:
>>
>> As I understand it, it's not that state is not maintained but that we are keeping it on the parameters side. For example, a extraction phase call will generate a PRK that will be kept in the parameters side for the following expansion phase calls.
> 
> For an extract-once expand-multiple use case, I think you can do an extract-only deriveKey and this returns the PRK. You can then use this PRK to do multiple expand-only deriveKeys. There is no need to store the PRK inside the params after the 1st step. Or, are you worrying about the PRK been leaked?

The extract phase gets the IKM from the HKDFParameterSpec and the 
derivation produces the PRK. My interpretation is that such PRK will be 
passed to the expansion phase in a HKDFParameterSpec to the next 
derivation call. All of this will be made from code that is agnostic of 
the provider. That's what I meant by passing state on the parameters 
side. If the IKM/PRK in HKDFParameterSpec is not a byte[] but a Key for 
example, that would work for SunPKCS11 because in the first extraction 
call the key is created in the token but in successive expansion calls 
the key (PRK) from the token is used, without needing to create it again 
over and over.



From macarte at openjdk.org  Wed Mar 13 17:02:16 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 13 Mar 2024 17:02:16 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <z8WdfgAV-XCoiP46smIJWoVQQzyLNi76nN_QH9dnvgU=.28f37f5f-c0ef-477b-ac56-c52688919003@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

I welcome your contribution and feel that it will be a worthwhile improvement; and I'm happy to give feedback (and have done already), but as an author I'm not able to sponsor this change.

The original enhancement has gone through a review process and has not had any security related bugs raised against it.  The scenario this change targets is a valid one, but is not a security vulnerability as the original enhancement does not circumvent security.  The choice to deploy to a less-secure environment to use the feature is a user choice.

While the change in this PR is trivial, it is still classed as an enhancement as it's not addressing a bug; ie. the original change functions as expected.  That you have identified a scenario and supplied a patch is much appreciated; however the change will need to go through review as it changes functionality; again we'll need to consider informing the user as the change could lead to unexpected deployment issues (it may also require documentation changes [CSR]).

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1994991109


From weijun at openjdk.org  Wed Mar 13 18:20:17 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 13 Mar 2024 18:20:17 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <z8WdfgAV-XCoiP46smIJWoVQQzyLNi76nN_QH9dnvgU=.28f37f5f-c0ef-477b-ac56-c52688919003@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <z8WdfgAV-XCoiP46smIJWoVQQzyLNi76nN_QH9dnvgU=.28f37f5f-c0ef-477b-ac56-c52688919003@github.com>
Message-ID: <PrXab5oh_lzlAMvCqCmXkz3EHrAH-nzd4eCCTHuJ4Hc=.4f1faecd-138a-4bee-a0d9-5df4b0472f22@github.com>

On Wed, 13 Mar 2024 16:57:17 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> I welcome your contribution and feel that it will be a worthwhile improvement; and I'm happy to give feedback (and have done already), but as an author I'm not able to sponsor this change.
> 
> The original enhancement has gone through a review process and has not had any security related bugs raised against it.  The scenario this change targets is a valid one, but is not a security vulnerability as the original enhancement does not circumvent security.  The choice to deploy to a less-secure environment to use the feature is a user choice.
> 
> While the change in this PR is trivial, it is still classed as an enhancement as it's not addressing a bug; ie. the original change functions as expected.  That you have identified a scenario and supplied a patch is much appreciated; however the change will need to go through review as it changes functionality; again we'll need to consider informing the user as the change could lead to unexpected deployment issues (it may also require documentation changes [CSR]).

@macarte If you find the change ok, you can also add yourself as a reviewer even if the OpenJDK bot might not count you as a *R*eviewer.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1995257115


From weijun at openjdk.org  Wed Mar 13 18:27:15 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 13 Mar 2024 18:27:15 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <Za_-kLCuWGrA5nfrKy8lX1DEG76aUtkrEfGsrGljBac=.7a61ac0a-6de3-430a-9401-7e713c4ac353@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

A CSR is needed if there will be a spec or doc change, and I don't see we need it anywhere. It is also needed if there is a non-trivial compatibility issue. While there is some behavior change here I don't think it's a compatibility issue. Those worked still work and those didn't work now somehow work. To inform the user this behavior change it looks like a release note is enough. See https://openjdk.org/guide/#release-notes.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1995280726


From macarte at openjdk.org  Wed Mar 13 18:52:13 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 13 Mar 2024 18:52:13 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <lmXk7-63bmtnLP2w1O9VtNWika7am8Bz3ivj7SiszHo=.9852b7ff-b8e6-482e-a384-d489f34b29c3@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

If its decided that when the store is opened with readonly access that no warning is output then I'll go with the majority (please raise this discussion in the mailing list).  

However, before "signing off" I'd like to see the output of manually testing the keystore API when opened in readonly mode using this method.

I believe that with this change we can modify the original jtreg test as the test will be able to enumerate the keystore and load it without an access denied exception

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1995367148


From djelinski at openjdk.org  Wed Mar 13 19:12:23 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 13 Mar 2024 19:12:23 GMT
Subject: RFR: 8325164: Named groups and signature schemes unavailable with
 SunPKCS11 in FIPS mode [v3]
In-Reply-To: <R_dNMtGLiXpjwOAXgpSMM7duJatENHy-zaOXgthF78w=.ebd48499-a4b6-414c-a3af-dc38f3bfca06@github.com>
References: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
 <R_dNMtGLiXpjwOAXgpSMM7duJatENHy-zaOXgthF78w=.ebd48499-a4b6-414c-a3af-dc38f3bfca06@github.com>
Message-ID: <F3JoApYhpBjm6uugz_TDchtydHxxMZLJ37CczsuAN_I=.74653b63-a68b-433d-b263-4beed7485568@github.com>

On Tue, 12 Mar 2024 20:18:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently the SunPKCS11 provider requires other providers in order to offer ECDHE, FFDHE and RSA-PSS in TLS handshakes:
>> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
>> - ECDHE requires the SunEC provider to be installed
>> - RSA-PSS requires RSASSA-PSS AlgorithmParameters from SunRsaSign
>> 
>> This PR removes these dependencies: 
>> - SunPKCS11 is modified to offer the PSS and DH AlgorithmParameters (using the same implementation classes as the original providers)
>> - Elliptic curve code is modified to remove the dependency on SunEC provider where possible
>> 
>> Two existing tests were modified to verify the changes:
>> - SigInteropPSS2 test was modified to install SunPKCS11 provider and remove SunRsaSign provider
>> - FipsModeTLS12 test was modified to verify the list of NamedGroups available on a SSLEngine.
>> 
>> Both modified tests fail without the changes, pass with them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Use explicit provider in PSS engineGetParameters
>  - Merge remote-tracking branch 'origin' into pkcs11-parameters
>  - Restore original SunEC behavior
>  - Update remaining ECUtil usages
>  - Update copyright and bugids
>  - Reduce SunEC dependencies
>  - Add DiffieHellman parameters
>  - Add RSASSA-PSS AlgorithmParameters

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17816#issuecomment-1995434396


From djelinski at openjdk.org  Wed Mar 13 19:12:24 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 13 Mar 2024 19:12:24 GMT
Subject: Integrated: 8325164: Named groups and signature schemes unavailable
 with SunPKCS11 in FIPS mode
In-Reply-To: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
References: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>
Message-ID: <fQZWLxDnW6S6k5MtD9W48B74i9WIE9D6zdLGylKFAKw=.ebf5c2fc-1648-4f84-8f46-9009e5458a06@github.com>

On Mon, 12 Feb 2024 20:23:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently the SunPKCS11 provider requires other providers in order to offer ECDHE, FFDHE and RSA-PSS in TLS handshakes:
> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
> - ECDHE requires the SunEC provider to be installed
> - RSA-PSS requires RSASSA-PSS AlgorithmParameters from SunRsaSign
> 
> This PR removes these dependencies: 
> - SunPKCS11 is modified to offer the PSS and DH AlgorithmParameters (using the same implementation classes as the original providers)
> - Elliptic curve code is modified to remove the dependency on SunEC provider where possible
> 
> Two existing tests were modified to verify the changes:
> - SigInteropPSS2 test was modified to install SunPKCS11 provider and remove SunRsaSign provider
> - FipsModeTLS12 test was modified to verify the list of NamedGroups available on a SSLEngine.
> 
> Both modified tests fail without the changes, pass with them. Other tier1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: 8f9899b2
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f9899b23ee46ad986bc719d3e2eec722d8d6bf8
Stats:     96 lines in 10 files changed: 29 ins; 30 del; 37 mod

8325164: Named groups and signature schemes unavailable with SunPKCS11 in FIPS mode

Reviewed-by: valeriep

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

PR: https://git.openjdk.org/jdk/pull/17816


From weijun at openjdk.org  Wed Mar 13 19:35:15 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 13 Mar 2024 19:35:15 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <2xm2Icg7rZifRaWcy59sw8sMq-Hgv3gHnmJRX-nZuOQ=.2d2255fe-4f54-4085-8d6b-54be60bd3206@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

That means a regression test can be added to this code change. No matter if the user running the test is an admin or not, the keystore can always be loaded. Is that right?

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1995508825


From mullan at openjdk.org  Wed Mar 13 19:39:16 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Mar 2024 19:39:16 GMT
Subject: RFR: 8051959: Option to print thread information in
 java.security.debug output [v2]
In-Reply-To: <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
Message-ID: <ttpcQIXZpAqNUQNPnAForn_nHyBDs3abf1aQ-1vOWVM=.d70a35f9-a9b4-4eb5-96f2-cc237de4a98f@github.com>

On Thu, 7 Mar 2024 11:57:07 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use default hex output

Some initial comments.

src/java.base/share/classes/sun/security/util/Debug.java line 75:

> 73:             if (args.equals("help")) {
> 74:                 Help();
> 75:             } else if (args.contains("all")) {

Suggest adding a comment explaining why you need to treat `all` specially here.

src/java.base/share/classes/sun/security/util/Debug.java line 126:

> 124:         System.err.println("+thread can be appended to any of above options to print");
> 125:         System.err.println("              thread information for that debug option");
> 126:         System.err.println();

Would it be more reasonable to place these lines after line 113 ("x509") which are the main options?

src/java.base/share/classes/sun/security/util/Debug.java line 181:

> 179:             d.printDateTime = getConfigInfo(option, "+timestamp");
> 180:             if (d.printDateTime && !dateTimeFormatInitialized) {
> 181:                 // trigger loading of Locale service impl now to avoid

You may want to try the test case added in JDK-8280890 with debugging enabled to make sure you don't get a similar recursion issue.

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

PR Review: https://git.openjdk.org/jdk/pull/18084#pullrequestreview-1935043291
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1523814610
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1523811142
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1523820467


From mullan at openjdk.org  Wed Mar 13 20:09:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Mar 2024 20:09:09 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
Message-ID: <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>

On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MBeanServerFileAccessController.java

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 29:

> 27:  * @enablePreview
> 28:  * @summary Implement Subject.current and Subject.callAs using scoped values.
> 29:  *      Need @enablePreview to use StructuredTaskScope.

jtreg throws a `ParseException` because I think it tries to interpret it as an `@enablePreview` action. Suggest enclosing it in double quotes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1523838888


From weijun at openjdk.org  Wed Mar 13 20:33:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 13 Mar 2024 20:33:40 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <i51mZBlUNCGnrMerNiAedz_2ImgCHMH7rOKLnr8ulzk=.8542b940-1a84-489b-be14-25bdd02f252b@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

I'm trying out this on my Windows Server 2016 box as a domain user. The command prompt window always has "Administrator:" in its title. What can I do?

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1995698297


From jjiang at openjdk.org  Thu Mar 14 03:12:30 2024
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 14 Mar 2024 03:12:30 GMT
Subject: RFR: 8327182: Move serverAlias into the loop [v2]
In-Reply-To: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
Message-ID: <UrquJ4bpwTIZFf4_fEAmyt4Y03oTBzSMN2t9jck8UT0=.32d57362-e2f2-49d5-89a3-1aa44cbcdaf6@github.com>

> In method `X509Authentication::createServerPossession`, it looks unnecessary to define variable `serverAlias` out of the for-loop.
> It may be better to move `serverAlias` into that loop to narrow down the scope.

John Jiang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8327182
 - 8327182: Move serverAlias into the loop

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

Changes: https://git.openjdk.org/jdk/pull/18100/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18100&range=01
  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18100/head:pull/18100

PR: https://git.openjdk.org/jdk/pull/18100


From weijun at openjdk.org  Thu Mar 14 13:31:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 13:31:58 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v3]
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <p-3xoBqXFg5gIz86KjFlfODe0xnqM_9sKLI3nwZGiyE=.19cd605e-0b57-4bc2-a9e7-43f7f24b9068@github.com>

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

  all other JGSS debugging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18199/files
  - new: https://git.openjdk.org/jdk/pull/18199/files/46dcb685..25cf73c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=01-02

  Stats: 775 lines in 54 files changed: 76 ins; 121 del; 578 mod
  Patch: https://git.openjdk.org/jdk/pull/18199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18199/head:pull/18199

PR: https://git.openjdk.org/jdk/pull/18199


From weijun at openjdk.org  Thu Mar 14 13:38:37 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 13:38:37 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v3]
In-Reply-To: <p-3xoBqXFg5gIz86KjFlfODe0xnqM_9sKLI3nwZGiyE=.19cd605e-0b57-4bc2-a9e7-43f7f24b9068@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <p-3xoBqXFg5gIz86KjFlfODe0xnqM_9sKLI3nwZGiyE=.19cd605e-0b57-4bc2-a9e7-43f7f24b9068@github.com>
Message-ID: <oLwsu_GC4zq3YLjOY5mgresfbqXwiVdGrVb60qmNalc=.65711ef1-7274-4c13-a73f-f0e29b1d9eeb@github.com>

On Thu, 14 Mar 2024 13:31:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   all other JGSS debugging

A new commit is pushed to cover all other debug outpus in JGSS/krb5. Most of the changes are simply one of:

1. `if (DEBUG)/` to `if (DEBUG != null)`
2. `System.out.println` to `DEBUG.println`.
3. `e.printStackTrace(System.out)` to `e.printStackTrace(DEBUG.getPrintStream())`

There is no more `DEBUG = Krb5.DEBUG` assignments. Always use `import static Krb5.DEBUG`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18199#issuecomment-1997478408


From weijun at openjdk.org  Thu Mar 14 13:43:01 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 13:43:01 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v4]
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <EV68dkL2FsrxRNubAZEmMBwlYM6oJYckD-LB2E8YBxM=.5c35384e-ed2b-4867-80ea-fbd8f20283ac@github.com>

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

  just use true

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18199/files
  - new: https://git.openjdk.org/jdk/pull/18199/files/25cf73c3..b63deeba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=02-03

  Stats: 11 lines in 1 file changed: 0 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18199/head:pull/18199

PR: https://git.openjdk.org/jdk/pull/18199


From weijun at openjdk.org  Thu Mar 14 15:39:41 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 15:39:41 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <i4FrRW4SMeJQW1W3crv3AkFV05aoPN3CUrUJ0iKMxKs=.65c8cbb3-116e-414d-a65a-11720a91ffae@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

I finally found a toy Windows 11 Home Edition machine and this code change works. The original `AllTypes.java` test also passed after I removed the `detectIfRunningWithAdminPrivileges` check.

However, I see another problem. After creating the entry as shown in step 2 in the bug report, it is listed as a private key entry in Windows-MY-LOCALMACHINE when user has admin privilege. Otherwise, it's just a trusted cert entry, which means the private key is not visible. Maybe this is expected? Because when I tried the `signtool` utility, it also does not work without admin privilege and says "no certificate were found that met all the given criteria". On the other hand, it signs an EXE successfully with admin privelege.

So we have a problem here. The entry was created as a self-signed cert with a private key but only the cert is visible. Is this still worth doing? Will this confuse users? Is it possible to make it a private key entry even if the key is not usable?

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1997743863


From weijun at openjdk.org  Thu Mar 14 15:55:43 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 15:55:43 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <u3gvzAbO1pRBjFKHUmnzKfLMhngOa9sLcpIXLUrsBzo=.1588be67-dfc4-4c03-a1b5-a4c5a3b73a71@github.com>

On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

I also noticed a different problem. No matter if privileged or unprivileged, `keytool -genkeypair -storetype Windows-My-LOCALMACHINE` works successfully but the entries are actually created in Windows-MY-CURRENTUSER.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1997780306


From contact at simonbernard.eu  Thu Mar 14 16:03:38 2024
From: contact at simonbernard.eu (Simon Bernard)
Date: Thu, 14 Mar 2024 17:03:38 +0100
Subject: Key Missing Feature for IoT
Message-ID: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>

Hi all,

I'm the main Maintainer of *Leshan* 
<https://github.com/eclipse-leshan/leshan>. An open Source Java 
Implementation of *LWM2M 
<https://github.com/eclipse-leshan/leshan/wiki/Lightweight-M2M-Specification>* 
protocol.

*LWM2M* is mainly based on *coap* and *coap+tcp* protocol.
Security is available by usage of *coaps* and *coaps+tcp* which are 
based respectively on *DTLS* and *TLS* (mainly v1.2 for now)

Currently we only have support of *coap* and *coaps*. We are using 
*Scandium 
<https://github.com/eclipse-californium/californium/tree/main/scandium-core>* 
as *DTLS* implementation, this is an historical choice because *DTLS* 
was not available *OpenJDK* initially.

Recently, I begin to work about adding *coap+tcp* and *coaps+tcp* to 
Leshan and so I looked again on available security feature in OpenJDK to 
see if I should rely on it but? I understand there still missing key 
features for IoT.

My understanding, DTLS 1.2 was added but there is still no support of :

  * *Pre-Shared Key* for (D)TLS 1.2 :? PSK is one of the most basic
    techniques for TLS/DTLS since it is both computationally efficient
    and bandwidth conserving. (RFC7925?Section4.2
    <https://www.rfc-editor.org/rfc/rfc7925#section-4.2> - TLS / DTLS
    -Profiles for the Internet of Things)
  * *Connection Identifier* for DTLS 1.2 (RFC 9146
    <https://www.rfc-editor.org/rfc/rfc9146.html>) : CID is key feature
    to limit handshake in dynamic IP environment. (and also be used for
    load balancing)
  * Cipher suite based on *AES_128_CCM_8
    *(TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8)
    which are the recommended or mandatory ciphersuite for CoAP or to
    create implementation compliant with RFC7925
    <https://www.rfc-editor.org/rfc/rfc7925>.

If I missed something and one of those feature is already available let 
me know.

The point I want to raise here it that it's pretty hard for Java IoT 
developer to support commons Security IoT Feature.

Community can eventually rely on Scandium but it is currently maintain 
by only 1 person and doesn't follow JSSE API and only target DTLS.
Other alternative is maybe Bouncy Castle but Pre-shared key seems not 
available in their JSSE provider.
There is also possibility to bind native library but this is not so easy 
and also have drawback.
All that solution sounds not so good...

So do you think it could make sense to add this kind of feature in OpenJDK ?
Or Maybe there is already plan to add it ?

(I hope this is the right place for this kind of question)

Thx,

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240314/ad53b18c/attachment.htm>

From coffeys at openjdk.org  Thu Mar 14 17:15:40 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 14 Mar 2024 17:15:40 GMT
Subject: RFR: 8051959: Add decorator options for java.security.debug output
 [v2]
In-Reply-To: <ttpcQIXZpAqNUQNPnAForn_nHyBDs3abf1aQ-1vOWVM=.d70a35f9-a9b4-4eb5-96f2-cc237de4a98f@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
 <ttpcQIXZpAqNUQNPnAForn_nHyBDs3abf1aQ-1vOWVM=.d70a35f9-a9b4-4eb5-96f2-cc237de4a98f@github.com>
Message-ID: <fXE54pPp0I7WxrFJ2-uinplXlVnLmwZxNYTyvcFk6qM=.f22b15c9-e685-47e5-9a78-ec97a21992b2@github.com>

On Wed, 13 Mar 2024 19:30:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use default hex output
>
> src/java.base/share/classes/sun/security/util/Debug.java line 75:
> 
>> 73:             if (args.equals("help")) {
>> 74:                 Help();
>> 75:             } else if (args.contains("all")) {
> 
> Suggest adding a comment explaining why you need to treat `all` specially here.

good point - will update in next commit

> src/java.base/share/classes/sun/security/util/Debug.java line 126:
> 
>> 124:         System.err.println("+thread can be appended to any of above options to print");
>> 125:         System.err.println("              thread information for that debug option");
>> 126:         System.err.println();
> 
> Would it be more reasonable to place these lines after line 113 ("x509") which are the main options?

yes - can do.

> src/java.base/share/classes/sun/security/util/Debug.java line 181:
> 
>> 179:             d.printDateTime = getConfigInfo(option, "+timestamp");
>> 180:             if (d.printDateTime && !dateTimeFormatInitialized) {
>> 181:                 // trigger loading of Locale service impl now to avoid
> 
> You may want to try the test case added in JDK-8280890 with debugging enabled to make sure you don't get a similar recursion issue.

interesting - I did add `-Djava,security.debug=all ` to the internals of that test and see issues.

However - they're issues that exist even without my patch. I need to take a closer look. `sun.util.locale.provider.LocaleServiceProviderPool` doesn't like to be invoked too early. That's a concern - maybe it should be able to handle such scenarios and return a simple/default Locale provider.


Caused by: java.lang.IllegalStateException: getSystemClassLoader cannot be called during the system class loader instantiation
at java.lang.ClassLoader.getSystemClassLoader([java.base at 23-ea](mailto:java.base at 23-ea)/ClassLoader.java:1952)
at java.lang.ClassLoader.getSystemResources([java.base at 23-ea](mailto:java.base at 23-ea)/ClassLoader.java:1723)
at java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1189)
at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1224)
at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1269)
at java.util.ServiceLoader$2.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1305)
at java.util.ServiceLoader$3.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1387)
at sun.util.cldr.CLDRLocaleProviderAdapter.lambda$new$0([java.base at 23-ea](mailto:java.base at 23-ea)/CLDRLocaleProviderAdapter.java:84)
at java.security.AccessController.doPrivileged([java.base at 23-ea](mailto:java.base at 23-ea)/AccessController.java:571)
at sun.util.cldr.CLDRLocaleProviderAdapter.<init>([java.base at 23-ea](mailto:java.base at 23-ea)/CLDRLocaleProviderAdapter.java:83)
at jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance([java.base at 23-ea](mailto:java.base at 23-ea)/DirectConstructorHandleAccessor.java:62)
at java.lang.reflect.Constructor.newInstanceWithCaller([java.base at 23-ea](mailto:java.base at 23-ea)/Constructor.java:502)
at java.lang.reflect.Constructor.newInstance([java.base at 23-ea](mailto:java.base at 23-ea)/Constructor.java:486)
at sun.util.locale.provider.LocaleProviderAdapter.forType([java.base at 23-ea](mailto:java.base at 23-ea)/LocaleProviderAdapter.java:182)
at sun.util.locale.provider.LocaleServiceProviderPool.findProviders([java.base at 23-ea](mailto:java.base at 23-ea)/LocaleServiceProviderPool.java:311)
at sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl([java.base at 23-ea](mailto:java.base at 23-ea)/LocaleServiceProviderPool.java:283)
at sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject([java.base at 23-ea](mailto:java.base at 23-ea)/LocaleServiceProviderPool.java:245)
at sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl([java.base at 23-ea](mailto:java.base at 23-ea)/TimeZoneNameUtility.java:197)
at sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayName([java.base at 23-ea](mailto:java.base at 23-ea)/TimeZoneNameUtility.java:150)
at java.util.TimeZone.getDisplayName([java.base at 23-ea](mailto:java.base at 23-ea)/TimeZone.java:430)
at java.util.Date.toString([java.base at 23-ea](mailto:java.base at 23-ea)/Date.java:1045)
at java.lang.String.valueOf([java.base at 23-ea](mailto:java.base at 23-ea)/String.java:4509)
at java.lang.StringBuilder.append([java.base at 23-ea](mailto:java.base at 23-ea)/StringBuilder.java:173)
at sun.security.x509.CertificateValidity.toString([java.base at 23-ea](mailto:java.base at 23-ea)/CertificateValidity.java:118)
at java.lang.String.valueOf([java.base at 23-ea](mailto:java.base at 23-ea)/String.java:4509)
at java.lang.StringBuilder.append([java.base at 23-ea](mailto:java.base at 23-ea)/StringBuilder.java:173)
at sun.security.x509.X509CertInfo.toString([java.base at 23-ea](mailto:java.base at 23-ea)/X509CertInfo.java:221)
at java.lang.String.valueOf([java.base at 23-ea](mailto:java.base at 23-ea)/String.java:4509)
at java.lang.StringBuilder.append([java.base at 23-ea](mailto:java.base at 23-ea)/StringBuilder.java:173)
at sun.security.x509.X509CertImpl.toString([java.base at 23-ea](mailto:java.base at 23-ea)/X509CertImpl.java:560)
at java.lang.String.valueOf([java.base at 23-ea](mailto:java.base at 23-ea)/String.java:4509)
at java.lang.StringBuilder.append([java.base at 23-ea](mailto:java.base at 23-ea)/StringBuilder.java:173)
at sun.security.util.SignatureFileVerifier.getSigners([java.base at 23-ea](mailto:java.base at 23-ea)/SignatureFileVerifier.java:742)
at sun.security.util.SignatureFileVerifier.processImpl([java.base at 23-ea](mailto:java.base at 23-ea)/SignatureFileVerifier.java:312)
at sun.security.util.SignatureFileVerifier.process([java.base at 23-ea](mailto:java.base at 23-ea)/SignatureFileVerifier.java:281)
at java.util.jar.JarVerifier.processEntry([java.base at 23-ea](mailto:java.base at 23-ea)/JarVerifier.java:320)
at java.util.jar.JarVerifier.update([java.base at 23-ea](mailto:java.base at 23-ea)/JarVerifier.java:232)
at java.util.jar.JarFile.initializeVerifier([java.base at 23-ea](mailto:java.base at 23-ea)/JarFile.java:760)
at java.util.jar.JarFile.getInputStream([java.base at 23-ea](mailto:java.base at 23-ea)/JarFile.java:858)
at jdk.internal.loader.URLClassPath$JarLoader$2.getInputStream([java.base at 23-ea](mailto:java.base at 23-ea)/URLClassPath.java:837)
at jdk.internal.loader.Resource.cachedInputStream([java.base at 23-ea](mailto:java.base at 23-ea)/Resource.java:77)
at jdk.internal.loader.Resource.getByteBuffer([java.base at 23-ea](mailto:java.base at 23-ea)/Resource.java:163)
at jdk.internal.loader.BuiltinClassLoader.defineClass([java.base at 23-ea](mailto:java.base at 23-ea)/BuiltinClassLoader.java:853)
at jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull([java.base at 23-ea](mailto:java.base at 23-ea)/BuiltinClassLoader.java:760)
at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull([java.base at 23-ea](mailto:java.base at 23-ea)/BuiltinClassLoader.java:681)
at jdk.internal.loader.BuiltinClassLoader.loadClass([java.base at 23-ea](mailto:java.base at 23-ea)/BuiltinClassLoader.java:639)
at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass([java.base at 23-ea](mailto:java.base at 23-ea)/ClassLoaders.java:188)
at java.lang.ClassLoader.loadClass([java.base at 23-ea](mailto:java.base at 23-ea)/ClassLoader.java:528)
at java.lang.Class.forName0([java.base at 23-ea](mailto:java.base at 23-ea)/Native Method)
at java.lang.Class.forName([java.base at 23-ea](mailto:java.base at 23-ea)/Class.java:578)
at java.lang.Class.forName([java.base at 23-ea](mailto:java.base at 23-ea)/Class.java:557)
at java.lang.ClassLoader.initSystemClassLoader([java.base at 23-ea](mailto:java.base at 23-ea)/ClassLoader.java:1997)
at java.lang.System.initPhase3([java.base at 23-ea](mailto:java.base at 23-ea)/System.java:2338)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1525239333
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1525239399
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1525239458


From weijun at openjdk.org  Thu Mar 14 18:04:57 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 18:04:57 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v5]
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <ZS_IR3UIubVnI4snmvn_Nt_NkZjAmr2QO1Rt8JYNf1E=.b571730e-9f59-428d-9662-861d6db31fe4@github.com>

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

  native debug in stderr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18199/files
  - new: https://git.openjdk.org/jdk/pull/18199/files/b63deeba..c877d7be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=03-04

  Stats: 60 lines in 5 files changed: 0 ins; 0 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/18199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18199/head:pull/18199

PR: https://git.openjdk.org/jdk/pull/18199


From weijun at openjdk.org  Thu Mar 14 18:10:42 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 18:10:42 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
 <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>
Message-ID: <sgHC9jvz_mQFWtYkX2rREXbGel4XBTzme7hu_4hxOIY=.d04a7e2c-286f-4c14-b9b7-aa5072a1cf37@github.com>

On Wed, 13 Mar 2024 19:53:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes to MBeanServerFileAccessController.java
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 29:
> 
>> 27:  * @enablePreview
>> 28:  * @summary Implement Subject.current and Subject.callAs using scoped values.
>> 29:  *      Need @enablePreview to use StructuredTaskScope.
> 
> jtreg throws a `ParseException` because I think it tries to interpret it as an `@enablePreview` action. Suggest enclosing it in double quotes.

Yes, I noticed that. Thanks.

> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 55:
> 
>> 53:         Subject.callAs(subject, () -> check(0, Subject.current(), "Duke"));
>> 54: 
>> 55:         // Observable in the same thread in ACC mode, but not in the SV mode
> 
> Should this comment actually say "Observable in a new platform thread in ACC mode, but not in the SV mode".

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1525308150
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1525308836


From mpowers at openjdk.org  Thu Mar 14 19:57:41 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 14 Mar 2024 19:57:41 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v4]
In-Reply-To: <EV68dkL2FsrxRNubAZEmMBwlYM6oJYckD-LB2E8YBxM=.5c35384e-ed2b-4867-80ea-fbd8f20283ac@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <EV68dkL2FsrxRNubAZEmMBwlYM6oJYckD-LB2E8YBxM=.5c35384e-ed2b-4867-80ea-fbd8f20283ac@github.com>
Message-ID: <s-Fy4xM9bS2lx8qkaMGQZoD0cGNErNISaU3rWrZkVHg=.86eddf72-0b66-4223-8f76-9ee5a5d255a5@github.com>

On Thu, 14 Mar 2024 13:43:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   just use true

src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoToken.java line 30:

> 28: import org.ietf.jgss.GSSException;
> 29: import sun.security.jgss.GSSToken;
> 30: import sun.security.util.Debug;

Is this really needed?

src/java.security.jgss/share/classes/sun/security/krb5/internal/KerberosTime.java line 36:

> 34: import sun.security.krb5.Config;
> 35: import sun.security.krb5.KrbException;
> 36: import sun.security.util.Debug;

Needed?

src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/crc32.java line 33:

> 31: package sun.security.krb5.internal.crypto;
> 32: 
> 33: import sun.security.krb5.internal.Krb5;

It's not obvious to me why this import is needed.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java line 1015:

> 1013:         } catch (Exception e) {
> 1014:             lcreds = null;
> 1015:             if (debug != null)

Might want to add curley braces here and elsewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525380205
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525354378
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525326097
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525165817


From mpowers at openjdk.org  Thu Mar 14 19:57:43 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 14 Mar 2024 19:57:43 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v5]
In-Reply-To: <ZS_IR3UIubVnI4snmvn_Nt_NkZjAmr2QO1Rt8JYNf1E=.b571730e-9f59-428d-9662-861d6db31fe4@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <ZS_IR3UIubVnI4snmvn_Nt_NkZjAmr2QO1Rt8JYNf1E=.b571730e-9f59-428d-9662-861d6db31fe4@github.com>
Message-ID: <EuvrbI9hzYvuv1u6GrPrzdCOSkcNA5knDCGyrBrps7A=.c07f507e-e578-4e1b-8c6a-43193cf9cdeb@github.com>

On Thu, 14 Mar 2024 18:04:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   native debug in stderr

src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java line 812:

> 810:                 debug.println
> 811:                         ("username from shared state is " + username + "\n");
> 812:             }

Looks like lines 805-808 are copied.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525417530


From weijun at openjdk.org  Thu Mar 14 20:10:57 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 20:10:57 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v6]
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <H5c1lqmVBItKLJTUv9nO_Z2PPPjz_4w5RXStgDDLcjw=.0aa46b2f-b08a-4f99-81a2-b5cbde384d4b@github.com>

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

  a native test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18199/files
  - new: https://git.openjdk.org/jdk/pull/18199/files/c877d7be..a89d3589

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=04-05

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18199/head:pull/18199

PR: https://git.openjdk.org/jdk/pull/18199


From weijun at openjdk.org  Thu Mar 14 20:30:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 20:30:58 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v7]
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <h-0prS5X-2TwbzFM9VjZ_SNJsWGzhDZj-KSdIvexaq4=.c640920a-4dc6-46a2-aae9-8f5678eb7acd@github.com>

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

  Mark's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18199/files
  - new: https://git.openjdk.org/jdk/pull/18199/files/a89d3589..3491a4c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=05-06

  Stats: 8 lines in 4 files changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18199/head:pull/18199

PR: https://git.openjdk.org/jdk/pull/18199


From weijun at openjdk.org  Thu Mar 14 20:30:59 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 20:30:59 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v5]
In-Reply-To: <EuvrbI9hzYvuv1u6GrPrzdCOSkcNA5knDCGyrBrps7A=.c07f507e-e578-4e1b-8c6a-43193cf9cdeb@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <ZS_IR3UIubVnI4snmvn_Nt_NkZjAmr2QO1Rt8JYNf1E=.b571730e-9f59-428d-9662-861d6db31fe4@github.com>
 <EuvrbI9hzYvuv1u6GrPrzdCOSkcNA5knDCGyrBrps7A=.c07f507e-e578-4e1b-8c6a-43193cf9cdeb@github.com>
Message-ID: <Qyw2v8PnpRMOy8kYY5T2DIGmpSTtveSQ-W9M7dFwoXk=.6b2923a2-12d1-45b0-b178-a19cb38df330@github.com>

On Thu, 14 Mar 2024 19:53:41 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   native debug in stderr
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java line 812:
> 
>> 810:                 debug.println
>> 811:                         ("username from shared state is " + username + "\n");
>> 812:             }
> 
> Looks like lines 805-808 are copied.

Yes, you're right. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525444949


From weijun at openjdk.org  Thu Mar 14 20:30:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 20:30:58 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v4]
In-Reply-To: <s-Fy4xM9bS2lx8qkaMGQZoD0cGNErNISaU3rWrZkVHg=.86eddf72-0b66-4223-8f76-9ee5a5d255a5@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <EV68dkL2FsrxRNubAZEmMBwlYM6oJYckD-LB2E8YBxM=.5c35384e-ed2b-4867-80ea-fbd8f20283ac@github.com>
 <s-Fy4xM9bS2lx8qkaMGQZoD0cGNErNISaU3rWrZkVHg=.86eddf72-0b66-4223-8f76-9ee5a5d255a5@github.com>
Message-ID: <tlrqSTm0FunqkzmHSxu26V8hPXfFyvofKqNe72oQSJU=.43b19dc2-176b-4406-9d75-3156391d9e4f@github.com>

On Thu, 14 Mar 2024 19:18:16 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   just use true
>
> src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoToken.java line 30:
> 
>> 28: import org.ietf.jgss.GSSException;
>> 29: import sun.security.jgss.GSSToken;
>> 30: import sun.security.util.Debug;
> 
> Is this really needed?

Will remove it.

> src/java.security.jgss/share/classes/sun/security/krb5/internal/KerberosTime.java line 36:
> 
>> 34: import sun.security.krb5.Config;
>> 35: import sun.security.krb5.KrbException;
>> 36: import sun.security.util.Debug;
> 
> Needed?

No. Sorry.

> src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/crc32.java line 33:
> 
>> 31: package sun.security.krb5.internal.crypto;
>> 32: 
>> 33: import sun.security.krb5.internal.Krb5;
> 
> It's not obvious to me why this import is needed.

Not needed. Will remove.

> src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java line 1015:
> 
>> 1013:         } catch (Exception e) {
>> 1014:             lcreds = null;
>> 1015:             if (debug != null)
> 
> Might want to add curley braces here and elsewhere.

Can I leave them unchanged? I don't know an efficient way to search for all places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525446228
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525446664
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525450527
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525448518


From mpowers at openjdk.org  Thu Mar 14 20:42:39 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 14 Mar 2024 20:42:39 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v4]
In-Reply-To: <tlrqSTm0FunqkzmHSxu26V8hPXfFyvofKqNe72oQSJU=.43b19dc2-176b-4406-9d75-3156391d9e4f@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <EV68dkL2FsrxRNubAZEmMBwlYM6oJYckD-LB2E8YBxM=.5c35384e-ed2b-4867-80ea-fbd8f20283ac@github.com>
 <s-Fy4xM9bS2lx8qkaMGQZoD0cGNErNISaU3rWrZkVHg=.86eddf72-0b66-4223-8f76-9ee5a5d255a5@github.com>
 <tlrqSTm0FunqkzmHSxu26V8hPXfFyvofKqNe72oQSJU=.43b19dc2-176b-4406-9d75-3156391d9e4f@github.com>
Message-ID: <EJQB7l-8_0AkgckfcQoS2fpjrw9RQK4shwAxljHG3o4=.a8a5775f-5560-48fa-811e-ba871948aeca@github.com>

On Thu, 14 Mar 2024 20:25:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java line 1015:
>> 
>>> 1013:         } catch (Exception e) {
>>> 1014:             lcreds = null;
>>> 1015:             if (debug != null)
>> 
>> Might want to add curley braces here and elsewhere.
>
> Can I leave them unchanged? I don't know an efficient way to search for all places.

Yes. It's only a nit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1525463067


From djelinski1 at gmail.com  Fri Mar 15 10:38:47 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Fri, 15 Mar 2024 11:38:47 +0100
Subject: Key Missing Feature for IoT
In-Reply-To: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>
References: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>
Message-ID: <CAMrH03+bc7PFjaS3mfZM8U4P_BDyPt9x0Nzmiu5ApP0YEOCxxw@mail.gmail.com>

Hi Simon, welcome to security-dev!

You got the situation of DTLS right:
- PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
- connection identifier is not implemented, and not on the to-do list yet;
- AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
understand correctly, this one should be relatively easier to
implement, using the implementation of the ChaCha20 cipher as an
example (see JDK-8140466, JDK-8204192).

It makes perfect sense to add these features to the OpenJDK. They were
never high enough on the priority list to get implemented. Help is
welcome.

Cheers,
Daniel


czw., 14 mar 2024 o 17:31 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>
> Hi all,
>
> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
>
> LWM2M is mainly based on coap and coap+tcp protocol.
> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
>
> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
>
> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
>
> My understanding, DTLS 1.2 was added but there is still no support of :
>
> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925?Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
>
> If I missed something and one of those feature is already available let me know.
>
> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
>
> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
> There is also possibility to bind native library but this is not so easy and also have drawback.
> All that solution sounds not so good...
>
> So do you think it could make sense to add this kind of feature in OpenJDK ?
> Or Maybe there is already plan to add it ?
>
> (I hope this is the right place for this kind of question)
>
> Thx,
>
> Simon
>


From djelinski1 at gmail.com  Fri Mar 15 11:29:08 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Fri, 15 Mar 2024 12:29:08 +0100
Subject: [SPAM] Hello fellow devs!
In-Reply-To: <EF13927E-BA3C-4656-96EB-2EC2CE741A0F@westhawk.co.uk>
References: <CAHQq8QJTYjF727+Kxn0gbmG9usdx7j-0kABBx77cMwaQ+goXLQ@mail.gmail.com>
 <CAHQq8QLHDxEcMQM7ops9+7okNNLOVMpRgLN9ueeKy+q62kYOrw@mail.gmail.com>
 <CAMrH03J7g7TQhrm7K9V6cNQ-wb23=f1Sqz0+VHEgy5EGrPKLCA@mail.gmail.com>
 <EF13927E-BA3C-4656-96EB-2EC2CE741A0F@westhawk.co.uk>
Message-ID: <CAMrH03+z0j4pRKxSwVz=aVo82n=8AtWr4U4_Sq-TGmybpUe2zQ@mail.gmail.com>

Hi Tim,
Thanks for the info! Some comments below:
- It is possible to inject and receive DTLS packets via a socket interface.
However, demultiplexing of incoming packets is not supported.
- Use_srtp extension is not implemented. Key material extraction is not
supported either.
- Certificate verification is possible using a custom X509TrustManager; the
certificate can also be verified by the application after the handshake.
- Timeouts are managed by the application. Most DTLS handshake packets can
be retransmitted on demand, but see JDK-8263571
<https://bugs.openjdk.org/browse/JDK-8263571>.

Cheers,
Daniel

pt., 8 mar 2024 o 10:56 Tim Panton <thp at westhawk.co.uk> napisa?(a):

>
>
> On 8 Mar 2024, at 07:47, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>
> Hi Paul,
> If you're interested in dealing with handshake extensions from user code,
> that is currently not possible. SSLEngine abstracts away all TLS messaging.
> SSLParameters can be used to configure a limited subset of extensions to
> send (like server_name or application protocol), and the negotiated
> application protocol can be retrieved from SSLEngine, and that's pretty
> much it.
>
> Use_srtp extension is not currently supported by JSSE. If you want to add
> that support, you'd need to add the appropriate enum values to
> sun.security.ssl.SSLExtension, using the constructors that specify a
> producer and a consumer. I'm not familiar with WebRTC or SRTP, so I don't
> know how that would interact with the rest of the code.
>
> If you have an idea how WebRTC / SRTP support could be implemented in
> JSSE, this is the right place for that discussion.
>
> Regards,
> Daniel
>
>
> Daniel, hi, following up on Paul?s question?
>
> I've done an integration with BouncyCastle DTLS API with WebRTC?s SRTP
> (and indirectly paid for the api to exist), here?s what I remember was
> needed:
>
> 1) Ability to inject and receive DTLS packets via a socket-like interface
> - WebRTC muxes several protocols onto the same 5tuple ports so we need to
> manage the packet traffic from a UDP socket before it gets to DTLS.
> - In some cases the DTLS packet is wrapped in a TURN packet on the wire -
> so you cant?t even assume the packet came in on UDP.
> 2) Ability to set and detect the use_srtp Extension
> 3) Ability to verify the self signed cert offered in the handshake
> 4) Ability to manage the handshake timeouts
> 5) Ability to extract the keyring material post handshake
>
> I haven?t kept up with JSSE DTLS but I don?t remember any of those API
> points being available.
>
> It would be nice to be able to use JDK/JSSE but to be honest I?m pretty
> happy with BouncyCastle.
>
> There is an example of our use here :
> [image: whipi.png]
>
> whipi/src/main/java/pe/pi/whipi/DTLS.java at
> d0fe6c06f5b34fa832d1ebce0bd228f066920da0 ? pipe/whipi
> <https://github.com/pipe/whipi/blob/d0fe6c06f5b34fa832d1ebce0bd228f066920da0/src/main/java/pe/pi/whipi/DTLS.java>
> github.com
> <https://github.com/pipe/whipi/blob/d0fe6c06f5b34fa832d1ebce0bd228f066920da0/src/main/java/pe/pi/whipi/DTLS.java>
>
> <https://github.com/pipe/whipi/blob/d0fe6c06f5b34fa832d1ebce0bd228f066920da0/src/main/java/pe/pi/whipi/DTLS.java>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240315/ba63f7b7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: whipi.png
Type: image/png
Size: 43712 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240315/ba63f7b7/whipi.png>

From duke at openjdk.org  Fri Mar 15 11:55:40 2024
From: duke at openjdk.org (Bernd)
Date: Fri, 15 Mar 2024 11:55:40 GMT
Subject: RFR: 8051959: Add decorator options for java.security.debug output
 [v2]
In-Reply-To: <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
Message-ID: <tLTbs7pzQYUc_Xd-iNtjIzAdxuvYhWCPRmulAYy6NWA=.51f15a5b-b436-45e9-91d7-f80e9e39da85@github.com>

On Thu, 7 Mar 2024 11:57:07 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use default hex output

src/java.base/share/classes/sun/security/util/Debug.java line 294:

> 292:         if (printThreadDetails) {
> 293:             retString = "0x" + Long.toHexString(
> 294:                     Thread.currentThread().threadId()).toUpperCase(Locale.ROOT) +

mmhh.. i can understand the desire to unify casing, but maybe changing the other logs to use javas default casing for hex (instead of changing it here) makes the code faster and better to read?
(Not sure if StringBuilder optimization (including starting with [) would be worth the complication)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1526169704


From djelinski1 at gmail.com  Fri Mar 15 12:16:57 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Fri, 15 Mar 2024 13:16:57 +0100
Subject: Key Missing Feature for IoT
In-Reply-To: <33567a7b-49f0-4845-98ab-921f741a045a@simonbernard.eu>
References: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>
 <CAMrH03+bc7PFjaS3mfZM8U4P_BDyPt9x0Nzmiu5ApP0YEOCxxw@mail.gmail.com>
 <33567a7b-49f0-4845-98ab-921f741a045a@simonbernard.eu>
Message-ID: <CAMrH03+nLgSyZ8thtB+4m47hBk4=Rg6pt75ZOSQ=zjzbztRE=A@mail.gmail.com>

Hi Simon,
Yes, the cipher suites in CipherSuite class are available in both TLS
and DTLS by default. TLS 1.3 uses different cipher suites from TLS
1.2, so both protocols need to be updated.

Regarding backporting to other versions of Java, backports are
reviewed on a case-by-case basis. TLS changes are usually backported,
but that's not a given.

RPK is not implemented either; we have a declaration for the relevant
handshake extensions here:
https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240,
but the producers and consumers aren't defined.

> Which kind of help do you need ? ?

Well, for AES-CCM a pull request would have been nice :)
For the other topics, I think we'd need to agree on the scope of the
API changes needed. For example, how will the user configure the list
of available PSKs? Will we need an API change? If not, which of the
available APIs will we use to configure the keys?

Cheers,
Daniel




pt., 15 mar 2024 o 11:58 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>
> Hi Daniel,
>
> Thx for quick answer.
>
> For PSK and AES, if this is added then this will be also for TLS ? (not only DTLS  right ?) and for version 1.2 and 1.3 ? and also when this feature will be added, would they be available on next JDK version OR also old version ? (e.g. I know some recent security feature was backported in java8)
>
> Today, I was looking at Raw Public Key support (RPK) and I understand this is not supported too. Am I right ?
> RPK is also part of LWM2M specification and also refered in (RFC7925?Section4.3 - TLS / DTLS -Profiles for the Internet of Things) :
> "The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is the first entry point into public key cryptography without having to pay the price of certificates and a public key infrastructure (PKI)."
>
>  Help is welcome.
>
> Which kind of help do you need ? ?
>
> Simon
>
> Le 15/03/2024 ? 11:38, Daniel Jeli?ski a ?crit :
>
> Hi Simon, welcome to security-dev!
>
> You got the situation of DTLS right:
> - PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
> - connection identifier is not implemented, and not on the to-do list yet;
> - AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
> understand correctly, this one should be relatively easier to
> implement, using the implementation of the ChaCha20 cipher as an
> example (see JDK-8140466, JDK-8204192).
>
> It makes perfect sense to add these features to the OpenJDK. They were
> never high enough on the priority list to get implemented. Help is
> welcome.
>
> Cheers,
> Daniel
>
>
> czw., 14 mar 2024 o 17:31 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>
> Hi all,
>
> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
>
> LWM2M is mainly based on coap and coap+tcp protocol.
> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
>
> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
>
> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
>
> My understanding, DTLS 1.2 was added but there is still no support of :
>
> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925?Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
>
> If I missed something and one of those feature is already available let me know.
>
> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
>
> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
> There is also possibility to bind native library but this is not so easy and also have drawback.
> All that solution sounds not so good...
>
> So do you think it could make sense to add this kind of feature in OpenJDK ?
> Or Maybe there is already plan to add it ?
>
> (I hope this is the right place for this kind of question)
>
> Thx,
>
> Simon
>


From coffeys at openjdk.org  Fri Mar 15 13:26:51 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 15 Mar 2024 13:26:51 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v7]
In-Reply-To: <h-0prS5X-2TwbzFM9VjZ_SNJsWGzhDZj-KSdIvexaq4=.c640920a-4dc6-46a2-aae9-8f5678eb7acd@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <h-0prS5X-2TwbzFM9VjZ_SNJsWGzhDZj-KSdIvexaq4=.c640920a-4dc6-46a2-aae9-8f5678eb7acd@github.com>
Message-ID: <zZhi4jsliC3uPloo8N7KiBJxZT0mXOpAP98PCmXQ7AY=.019a26de-b3ba-4e87-a037-04dd9920a57f@github.com>

On Thu, 14 Mar 2024 20:30:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mark's comments

Looks good. Few minor comments made. 

the new Debug.of method will need to implement some logic from the decorator debug PR at https://github.com/openjdk/jdk/pull/18084  -- depending on integration order, we can tackle that as needed.

src/java.base/share/classes/sun/security/util/Debug.java line 172:

> 170:      * settings. For example,
> 171:      * {@snippet lang=java:
> 172:      * Map<String,String> settings = loadLoginSettings();

minor nit - needs a space : `Map<String, String>`

src/java.base/share/classes/sun/security/util/Debug.java line 174:

> 172:      * Map<String,String> settings = loadLoginSettings();
> 173:      * String property = settings.get("login");
> 174:      * Debug debug = Debug.of("login", setting);

did you mean to use the `property` variable name here ?

src/java.base/share/classes/sun/security/util/Debug.java line 180:

> 178:      * @return a new Debug object if the property is true
> 179:      */
> 180:     public static Debug of(String option, String property) {

the `property` name is a bit confusing here IMO. Most use cases will be string corresponding to a boolean (or null) - Would a boolean paramater make more sense ? Otherwise. I'd suggest renaming variable to something like `debugEnabled`

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

PR Review: https://git.openjdk.org/jdk/pull/18199#pullrequestreview-1938907146
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1526259059
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1526259909
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1526262473


From mullan at openjdk.org  Fri Mar 15 13:36:41 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 15 Mar 2024 13:36:41 GMT
Subject: RFR: 8327182: Move serverAlias into the loop [v2]
In-Reply-To: <UrquJ4bpwTIZFf4_fEAmyt4Y03oTBzSMN2t9jck8UT0=.32d57362-e2f2-49d5-89a3-1aa44cbcdaf6@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
 <UrquJ4bpwTIZFf4_fEAmyt4Y03oTBzSMN2t9jck8UT0=.32d57362-e2f2-49d5-89a3-1aa44cbcdaf6@github.com>
Message-ID: <QQGDYAHvQQjnAADshnfwNns-pfYSwNoagA0jBXLYmqs=.7f8dca2b-8d36-450b-b7a3-b474cfd1965f@github.com>

On Thu, 14 Mar 2024 03:12:30 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> In method `X509Authentication::createServerPossession`, it looks unnecessary to define variable `serverAlias` out of the for-loop.
>> It may be better to move `serverAlias` into that loop to narrow down the scope.
>
> John Jiang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8327182
>  - 8327182: Move serverAlias into the loop

Looks good to me. Did you run all JSSE security regression tests?

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18100#pullrequestreview-1938970920


From weijun at openjdk.org  Fri Mar 15 13:39:09 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 15 Mar 2024 13:39:09 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v8]
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <GHLJ92_cWfRb_cV43JvFYwTnutJrS8o5-WYgKWOcQ9M=.a86e6ea1-7f66-43fe-8902-ab0b3402d63a@github.com>

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

  Se?n's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18199/files
  - new: https://git.openjdk.org/jdk/pull/18199/files/3491a4c7..94d0b4ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/18199


From weijun at openjdk.org  Fri Mar 15 13:39:09 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 15 Mar 2024 13:39:09 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v7]
In-Reply-To: <zZhi4jsliC3uPloo8N7KiBJxZT0mXOpAP98PCmXQ7AY=.019a26de-b3ba-4e87-a037-04dd9920a57f@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <h-0prS5X-2TwbzFM9VjZ_SNJsWGzhDZj-KSdIvexaq4=.c640920a-4dc6-46a2-aae9-8f5678eb7acd@github.com>
 <zZhi4jsliC3uPloo8N7KiBJxZT0mXOpAP98PCmXQ7AY=.019a26de-b3ba-4e87-a037-04dd9920a57f@github.com>
Message-ID: <PLZPMNzutZ-7poq3UBHA-m19l6mForUpKA5hSglGE78=.a5438814-9e27-4e21-997f-53e189db15b5@github.com>

On Fri, 15 Mar 2024 13:04:00 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Mark's comments
>
> src/java.base/share/classes/sun/security/util/Debug.java line 172:
> 
>> 170:      * settings. For example,
>> 171:      * {@snippet lang=java:
>> 172:      * Map<String,String> settings = loadLoginSettings();
> 
> minor nit - needs a space : `Map<String, String>`

Will add one.

> src/java.base/share/classes/sun/security/util/Debug.java line 174:
> 
>> 172:      * Map<String,String> settings = loadLoginSettings();
>> 173:      * String property = settings.get("login");
>> 174:      * Debug debug = Debug.of("login", setting);
> 
> did you mean to use the `property` variable name here ?

Ah, yes.

> src/java.base/share/classes/sun/security/util/Debug.java line 180:
> 
>> 178:      * @return a new Debug object if the property is true
>> 179:      */
>> 180:     public static Debug of(String option, String property) {
> 
> the `property` name is a bit confusing here IMO. Most use cases will be string corresponding to a boolean (or null) - Would a boolean paramater make more sense ? Otherwise. I'd suggest renaming variable to something like `debugEnabled`

I was thinking that it will contain more options like `true+timestamp` later. By that time, we only need to update the `Debug` class to add this feature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1526297798
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1526297546
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1526299579


From weijun at openjdk.org  Fri Mar 15 13:46:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 15 Mar 2024 13:46:12 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v9]
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <BWjwoDW0iWUv1AAdkoTpvsmXERWfjA-QSTqcj0tjKyc=.0d38af6d-cf65-4d41-a7d8-ec22a2acbcd6@github.com>

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18199/files
  - new: https://git.openjdk.org/jdk/pull/18199/files/94d0b4ea..01bb32c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18199&range=07-08

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

PR: https://git.openjdk.org/jdk/pull/18199


From coffeys at openjdk.org  Fri Mar 15 13:46:12 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 15 Mar 2024 13:46:12 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v7]
In-Reply-To: <PLZPMNzutZ-7poq3UBHA-m19l6mForUpKA5hSglGE78=.a5438814-9e27-4e21-997f-53e189db15b5@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <h-0prS5X-2TwbzFM9VjZ_SNJsWGzhDZj-KSdIvexaq4=.c640920a-4dc6-46a2-aae9-8f5678eb7acd@github.com>
 <zZhi4jsliC3uPloo8N7KiBJxZT0mXOpAP98PCmXQ7AY=.019a26de-b3ba-4e87-a037-04dd9920a57f@github.com>
 <PLZPMNzutZ-7poq3UBHA-m19l6mForUpKA5hSglGE78=.a5438814-9e27-4e21-997f-53e189db15b5@github.com>
Message-ID: <yU0qpI3_2N8J7BKaCapYz3YpgoAryero3iFnxgwqsS4=.25da7e33-8549-4a13-9d32-a068d3c42488@github.com>

On Fri, 15 Mar 2024 13:35:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Debug.java line 180:
>> 
>>> 178:      * @return a new Debug object if the property is true
>>> 179:      */
>>> 180:     public static Debug of(String option, String property) {
>> 
>> the `property` name is a bit confusing here IMO. Most use cases will be string corresponding to a boolean (or null) - Would a boolean paramater make more sense ? Otherwise. I'd suggest renaming variable to something like `debugEnabled`
>
> I was thinking that it will contain more options like `true+timestamp` later. By that time, we only need to update the `Debug` class to add this feature.

I see. Seems reasonable then. 

I can see how folding these krb5 debug options in under the `java.security.debug` property will make debugging easier for everyone. Hopefully, something that can be done in the near future in a follow on patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1526308374


From contact at simonbernard.eu  Fri Mar 15 10:58:37 2024
From: contact at simonbernard.eu (Simon Bernard)
Date: Fri, 15 Mar 2024 11:58:37 +0100
Subject: Key Missing Feature for IoT
In-Reply-To: <CAMrH03+bc7PFjaS3mfZM8U4P_BDyPt9x0Nzmiu5ApP0YEOCxxw@mail.gmail.com>
References: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>
 <CAMrH03+bc7PFjaS3mfZM8U4P_BDyPt9x0Nzmiu5ApP0YEOCxxw@mail.gmail.com>
Message-ID: <33567a7b-49f0-4845-98ab-921f741a045a@simonbernard.eu>

Hi Daniel,

Thx for quick answer.

For PSK and AES, if this is added then this will be also for TLS ? (not 
only DTLS? right ?) and for version 1.2 and 1.3 ? and also when this 
feature will be added, would they be available on next JDK version OR 
also old version ? (e.g. I know some recent security feature was 
backported in java8)

Today, I was looking at Raw Public Key support (RPK) and I understand 
this is not supported too. Am I right ?
RPK is also part of LWM2M specification and also refered in 
(RFC7925?Section4.3 <https://www.rfc-editor.org/rfc/rfc7925#section-4.3> 
- TLS / DTLS -Profiles for the Internet of Things) :
/"The use of raw public keys with TLS/DTLS, as defined in [RFC7250 
<https://www.rfc-editor.org/rfc/rfc7250>], is the first entry point into 
public key cryptography without having to pay the price of certificates 
and a public key infrastructure (PKI)."/

>   Help is welcome.
Which kind of help do you need ? ?

Simon

Le 15/03/2024 ? 11:38, Daniel Jeli?ski a ?crit?:
> Hi Simon, welcome to security-dev!
>
> You got the situation of DTLS right:
> - PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
> - connection identifier is not implemented, and not on the to-do list yet;
> - AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
> understand correctly, this one should be relatively easier to
> implement, using the implementation of the ChaCha20 cipher as an
> example (see JDK-8140466, JDK-8204192).
>
> It makes perfect sense to add these features to the OpenJDK. They were
> never high enough on the priority list to get implemented. Help is
> welcome.
>
> Cheers,
> Daniel
>
>
> czw., 14 mar 2024 o 17:31 Simon Bernard<contact at simonbernard.eu>  napisa?(a):
>> Hi all,
>>
>> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
>>
>> LWM2M is mainly based on coap and coap+tcp protocol.
>> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
>>
>> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
>>
>> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
>>
>> My understanding, DTLS 1.2 was added but there is still no support of :
>>
>> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925?Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
>> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
>> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
>>
>> If I missed something and one of those feature is already available let me know.
>>
>> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
>>
>> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
>> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
>> There is also possibility to bind native library but this is not so easy and also have drawback.
>> All that solution sounds not so good...
>>
>> So do you think it could make sense to add this kind of feature in OpenJDK ?
>> Or Maybe there is already plan to add it ?
>>
>> (I hope this is the right place for this kind of question)
>>
>> Thx,
>>
>> Simon
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240315/23f4ad4e/attachment.htm>

From contact at simonbernard.eu  Fri Mar 15 15:43:10 2024
From: contact at simonbernard.eu (Simon Bernard)
Date: Fri, 15 Mar 2024 16:43:10 +0100
Subject: Key Missing Feature for IoT
In-Reply-To: <CAMrH03+nLgSyZ8thtB+4m47hBk4=Rg6pt75ZOSQ=zjzbztRE=A@mail.gmail.com>
References: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>
 <CAMrH03+bc7PFjaS3mfZM8U4P_BDyPt9x0Nzmiu5ApP0YEOCxxw@mail.gmail.com>
 <33567a7b-49f0-4845-98ab-921f741a045a@simonbernard.eu>
 <CAMrH03+nLgSyZ8thtB+4m47hBk4=Rg6pt75ZOSQ=zjzbztRE=A@mail.gmail.com>
Message-ID: <b0146018-0600-4f85-93c1-a438845bbae4@simonbernard.eu>

Thx for all this clarification.

>   For example, how will the user configure the list of available PSKs?
Regarding PSK API from other libraries :

*AdvancedPskStore* from Scandium 3.x which is not so straight forward to 
use mainly because it supports async request : 
https://github.com/eclipse-californium/californium/blob/3.11.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/AdvancedPskStore.java

*PskStore* from Scandium 2.x is more simple to understand but no async 
way to request PSK : 
https://github.com/eclipse-californium/californium/blob/2.8.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/PskStore.java

*PSKKeyManager* from Concrypt is a more JSSE oriented API (no async 
too). I also understand that this API is available when coding for 
Android but I think there is a drawback a client is not able to select 
Identity based on InetSocketAddress of destination.
 ?- 
https://android.googlesource.com/platform/frameworks/base/+/ba12af5/core/java/android/net/PskKeyManager.java
 ?- 
https://github.com/google/conscrypt/blob/2.5.2/common/src/main/java/org/conscrypt/PSKKeyManager.java
Note that this class is deprecated in concrypt : I tried to get more 
about this : https://github.com/google/conscrypt/issues/1197

*TlsPSKIdentityManager *is very simple and very limited API from Bouncy 
Castle : 
https://github.com/bcgit/bc-java/blob/1.72/tls/src/main/java/org/bouncycastle/tls/TlsPSKIdentityManager.java

Note that most of them would probably have been thought with (D)TLS 1.2 
in mind. I don't know if this is adapted for (D)TLS 1.3.

> Well, for AES-CCM a pull request would have been nice :)
I'm not so familiar with JSSE API/SunJSSE provider design for now. Do 
you think AES-CCM is a good candidate to start ?
I guess if I want to try to help on this, I need to have a look at : 
https://openjdk.org/guide/ (and also Contribution agreement)
Oh and working on JSSE when it's time to build/running tests is there a 
more simple way than building/testing whole JDK ?

Simon

Le 15/03/2024 ? 13:16, Daniel Jeli?ski a ?crit?:
> Hi Simon,
> Yes, the cipher suites in CipherSuite class are available in both TLS
> and DTLS by default. TLS 1.3 uses different cipher suites from TLS
> 1.2, so both protocols need to be updated.
>
> Regarding backporting to other versions of Java, backports are
> reviewed on a case-by-case basis. TLS changes are usually backported,
> but that's not a given.
>
> RPK is not implemented either; we have a declaration for the relevant
> handshake extensions here:
> https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240,
> but the producers and consumers aren't defined.
>
>> Which kind of help do you need ? ?
> Well, for AES-CCM a pull request would have been nice :)
> For the other topics, I think we'd need to agree on the scope of the
> API changes needed. For example, how will the user configure the list
> of available PSKs? Will we need an API change? If not, which of the
> available APIs will we use to configure the keys?
>
> Cheers,
> Daniel
>
>
>
>
> pt., 15 mar 2024 o 11:58 Simon Bernard<contact at simonbernard.eu>  napisa?(a):
>> Hi Daniel,
>>
>> Thx for quick answer.
>>
>> For PSK and AES, if this is added then this will be also for TLS ? (not only DTLS  right ?) and for version 1.2 and 1.3 ? and also when this feature will be added, would they be available on next JDK version OR also old version ? (e.g. I know some recent security feature was backported in java8)
>>
>> Today, I was looking at Raw Public Key support (RPK) and I understand this is not supported too. Am I right ?
>> RPK is also part of LWM2M specification and also refered in (RFC7925?Section4.3 - TLS / DTLS -Profiles for the Internet of Things) :
>> "The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is the first entry point into public key cryptography without having to pay the price of certificates and a public key infrastructure (PKI)."
>>
>>   Help is welcome.
>>
>> Which kind of help do you need ? ?
>>
>> Simon
>>
>> Le 15/03/2024 ? 11:38, Daniel Jeli?ski a ?crit :
>>
>> Hi Simon, welcome to security-dev!
>>
>> You got the situation of DTLS right:
>> - PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
>> - connection identifier is not implemented, and not on the to-do list yet;
>> - AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
>> understand correctly, this one should be relatively easier to
>> implement, using the implementation of the ChaCha20 cipher as an
>> example (see JDK-8140466, JDK-8204192).
>>
>> It makes perfect sense to add these features to the OpenJDK. They were
>> never high enough on the priority list to get implemented. Help is
>> welcome.
>>
>> Cheers,
>> Daniel
>>
>>
>> czw., 14 mar 2024 o 17:31 Simon Bernard<contact at simonbernard.eu>  napisa?(a):
>>
>> Hi all,
>>
>> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
>>
>> LWM2M is mainly based on coap and coap+tcp protocol.
>> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
>>
>> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
>>
>> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
>>
>> My understanding, DTLS 1.2 was added but there is still no support of :
>>
>> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925?Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
>> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
>> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
>>
>> If I missed something and one of those feature is already available let me know.
>>
>> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
>>
>> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
>> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
>> There is also possibility to bind native library but this is not so easy and also have drawback.
>> All that solution sounds not so good...
>>
>> So do you think it could make sense to add this kind of feature in OpenJDK ?
>> Or Maybe there is already plan to add it ?
>>
>> (I hope this is the right place for this kind of question)
>>
>> Thx,
>>
>> Simon
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240315/29b37f08/attachment.htm>

From horvath.peter.gergely at gmail.com  Fri Mar 15 22:25:06 2024
From: horvath.peter.gergely at gmail.com (=?UTF-8?Q?Horv=C3=A1th_P=C3=A9ter_Gergely?=)
Date: Fri, 15 Mar 2024 23:25:06 +0100
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <387c425d-6073-42f0-8cb4-6c69bc796277@oracle.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
 <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
 <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>
 <63B2990C-522D-472B-BB9C-6007CBF9B55E@oracle.com>
 <9C2E4C1B-FDB2-4A18-B9FF-235D45EDF28E@oracle.com>
 <CA+UsspCcVBFRH4xHEUJg86ztNM-FnP3SKUX8rXTLs1TpA7fvdQ@mail.gmail.com>
 <DBFEE820-9D41-4647-9660-EA40A87D5046@oracle.com>
 <387c425d-6073-42f0-8cb4-6c69bc796277@oracle.com>
Message-ID: <CA+UsspAWWKiYGV4S2hSG5qFjJLvEiDPuHANqNw0Gcn_GB6Ddtw@mail.gmail.com>

Hi Sean,

This is a tough question. I guess maybe the same granularity as the log
messages: that is,
emitting a JFR event for every step where now a log message is logged,
with similar parameters
would probably make sense?

At the same time, would anyone use JFR events to debug a Kerberos issue? I
am unsure about that.
What do you think?

Best,
Peter










Se?n Coffey <sean.coffey at oracle.com> ezt ?rta (id?pont: 2024. m?rc. 13.,
Sze, 10:53):

>
> On 13/03/2024 01:40, Wei-Jun Wang wrote:
>
> Thinking about this raises the question: wouldn't it be possible to have these components emit Flight Recorder events as well?
> I understand this is a dubious topic, as some arguments contain secrets, but it would be interesting to know.
> Maybe restricting FR events when security debug logging is enabled anyways would be an option?
>
> Se?n is our expert on JFR events. He has already created some security-related events, like provider loading and security properties access. You can tell him what else you are interested in.
>
> Using JFR events is certainly worthy of discussion. What would those JFR
> events looks like ? Would you propose one for each log action currently in
> the krb5 code ? It becomes unmaintainable IMO.
>
> The suggestion has also been made for the TLS logging code in the past.
> It's not trivial to convert every log entry to a JFR event. A typical
> client/server handshake in TLS can generate 1000's of lines of log output
> with -Djavax.net.debug=all enabled. It doesn't translate easily to JFR
> events. Reading text is probably easier also.
>
> On a related note, I think the current TLS logging is too verbose at the
> moment. Over 3,500 lines of output are generated before a ClientHello gets
> created in a typical TLS debug capture. It's too much. Most of it is
> iterating over certs found in the truststore (cacerts by default). Need to
> log a bug on that.
>
> regards,
> Sean.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240315/728f5f0d/attachment.htm>

From ecki at zusammenkunft.net  Sat Mar 16 00:00:20 2024
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 16 Mar 2024 01:00:20 +0100 (CET)
Subject: Improving logging in Krb5LoginModule
In-Reply-To: <CA+UsspAWWKiYGV4S2hSG5qFjJLvEiDPuHANqNw0Gcn_GB6Ddtw@mail.gmail.com>
References: <CA+UsspCgHC0DRj6gSiSG-8rVZqQWfcPEZ7qf5whPVJ+3UE7RoQ@mail.gmail.com>
 <262FC7DA-6FB7-4A46-933D-A2C54CD215A9@oracle.com>
 <f1c88af9-55af-42af-beff-e742deefa0e5@oracle.com>
 <63B2990C-522D-472B-BB9C-6007CBF9B55E@oracle.com>
 <9C2E4C1B-FDB2-4A18-B9FF-235D45EDF28E@oracle.com>
 <CA+UsspCcVBFRH4xHEUJg86ztNM-FnP3SKUX8rXTLs1TpA7fvdQ@mail.gmail.com>
 <DBFEE820-9D41-4647-9660-EA40A87D5046@oracle.com>
 <387c425d-6073-42f0-8cb4-6c69bc796277@oracle.com><CA+UsspAWWKiYGV4S2hSG5qFjJLvEiDPuHANqNw0Gcn_GB6Ddtw@mail.gmail.com>
Message-ID: <20240316000020.5ADF66601E2@dd33810.kasserver.com>

Not sure if it is helpful for debugging (other than you get caller stacktraces and a logfile) but for audit purpose a single
consolidated event which allows to see which real, which kdc, which ciphers and Idendity might be a thing useable
even in production. Especially if also SSPI/native cache is involved.

It?s a similar usecase to the TLS handshake events which you can use to check if a cipher you want to remove is still used.

Horv?th P?ter Gergely wrote on 15. Mar 2024 23:25 (GMT +01:00):

> Hi Sean,
> 
> This is a tough question. I guess maybe the same granularity as the log
> messages: that is,
> emitting a JFR event for every step where now a log message is logged,
> with similar parameters
> would probably make sense?
> 
> At the same time, would anyone use JFR events to debug a Kerberos issue? I
> am unsure about that.
> What do you think?
> 
> Best,
> Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Se?n Coffey <sean.coffey at oracle.com> ezt ?rta (id?pont: 2024. m?rc.
> 13.,
> Sze, 10:53):
> 
>>
>> On 13/03/2024 01:40, Wei-Jun Wang wrote:
>>
>> Thinking about this raises the question: wouldn't it be possible to have
>> these components emit Flight Recorder events as well?
>> I understand this is a dubious topic, as some arguments contain secrets,
>> but it would be interesting to know.
>> Maybe restricting FR events when security debug logging is enabled
>> anyways would be an option?
>>
>> Se?n is our expert on JFR events. He has already created some
>> security-related events, like provider loading and security properties
>> access. You can tell him what else you are interested in.
>>
>> Using JFR events is certainly worthy of discussion. What would those JFR
>> events looks like ? Would you propose one for each log action currently
>> in
>> the krb5 code ? It becomes unmaintainable IMO.
>>
>> The suggestion has also been made for the TLS logging code in the past.
>> It's not trivial to convert every log entry to a JFR event. A typical
>> client/server handshake in TLS can generate 1000's of lines of log output
>> with -Djavax.net.debug=all enabled. It doesn't translate easily to JFR
>> events. Reading text is probably easier also.
>>
>> On a related note, I think the current TLS logging is too verbose at the
>> moment. Over 3,500 lines of output are generated before a ClientHello
>> gets
>> created in a typical TLS debug capture. It's too much. Most of it is
>> iterating over certs found in the truststore (cacerts by default). Need
>> to
>> log a bug on that.
>>
>> regards,
>> Sean.
>>
> 


Gru?
Bernd
? 
https://bernd.eckenfels.net


From coffeys at openjdk.org  Sat Mar 16 22:18:38 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Sat, 16 Mar 2024 22:18:38 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v9]
In-Reply-To: <BWjwoDW0iWUv1AAdkoTpvsmXERWfjA-QSTqcj0tjKyc=.0d38af6d-cf65-4d41-a7d8-ec22a2acbcd6@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <BWjwoDW0iWUv1AAdkoTpvsmXERWfjA-QSTqcj0tjKyc=.0d38af6d-cf65-4d41-a7d8-ec22a2acbcd6@github.com>
Message-ID: <3oXZmnG-m4UMf9Wkm_jaRwuXZiNF8b5G-x67i3I-Q4I=.90f772f4-f58a-46a2-9421-6027a651a007@github.com>

On Fri, 15 Mar 2024 13:46:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18199#pullrequestreview-1939533578


From mullan at openjdk.org  Sat Mar 16 22:19:34 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Sat, 16 Mar 2024 22:19:34 GMT
Subject: RFR: 8051959: Add decorator options for java.security.debug output
 [v2]
In-Reply-To: <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
Message-ID: <OFHXFmX1X8hkcHaIs92A95dnp6fh2vUpliguvCW1jR4=.053c045f-691b-4892-9dfe-efee879778bb@github.com>

On Thu, 7 Mar 2024 11:57:07 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use default hex output

Suggest changing the title of the issue to "Add thread and timestamp options to java.security.debug system property"

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

PR Comment: https://git.openjdk.org/jdk/pull/18084#issuecomment-2000121716


From mullan at openjdk.org  Sat Mar 16 22:19:44 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Sat, 16 Mar 2024 22:19:44 GMT
Subject: RFR: 8051959: Add decorator options for java.security.debug output
 [v2]
In-Reply-To: <fXE54pPp0I7WxrFJ2-uinplXlVnLmwZxNYTyvcFk6qM=.f22b15c9-e685-47e5-9a78-ec97a21992b2@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
 <ttpcQIXZpAqNUQNPnAForn_nHyBDs3abf1aQ-1vOWVM=.d70a35f9-a9b4-4eb5-96f2-cc237de4a98f@github.com>
 <fXE54pPp0I7WxrFJ2-uinplXlVnLmwZxNYTyvcFk6qM=.f22b15c9-e685-47e5-9a78-ec97a21992b2@github.com>
Message-ID: <MojzwZcSIZazv0bHz6AOSCLWyurw4HJXhLQVtxnF69I=.20a45613-2f5b-41f6-846a-ecd65ea71ed2@github.com>

On Thu, 14 Mar 2024 17:13:15 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Debug.java line 181:
>> 
>>> 179:             d.printDateTime = getConfigInfo(option, "+timestamp");
>>> 180:             if (d.printDateTime && !dateTimeFormatInitialized) {
>>> 181:                 // trigger loading of Locale service impl now to avoid
>> 
>> You may want to try the test case added in JDK-8280890 with debugging enabled to make sure you don't get a similar recursion issue.
>
> interesting - I did add `-Djava,security.debug=all ` to the internals of that test and see issues.
> 
> However - they're issues that exist even without my patch. I need to take a closer look. `sun.util.locale.provider.LocaleServiceProviderPool` doesn't like to be invoked too early. That's a concern - maybe it should be able to handle such scenarios and return a simple/default Locale provider.
> 
> 
> Caused by: java.lang.IllegalStateException: getSystemClassLoader cannot be called during the system class loader instantiation
> at java.lang.ClassLoader.getSystemClassLoader([java.base at 23-ea](mailto:java.base at 23-ea)/ClassLoader.java:1952)
> at java.lang.ClassLoader.getSystemResources([java.base at 23-ea](mailto:java.base at 23-ea)/ClassLoader.java:1723)
> at java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1189)
> at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1224)
> at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1269)
> at java.util.ServiceLoader$2.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1305)
> at java.util.ServiceLoader$3.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1387)
> at sun.util.cldr.CLDRLocaleProviderAdapter.lambda$new$0([java.base at 23-ea](mailto:java.base at 23-ea)/CLDRLocaleProviderAdapter.java:84)
> at java.security.AccessController.doPrivileged([java.base at 23-ea](mailto:java.base at 23-ea)/AccessController.java:571)
> at sun.util.cldr.CLDRLocaleProviderAdapter.<init>([java.base at 23-ea](mailto:java.base at 23-ea)/CLDRLocaleProviderAdapter.java:83)
> at jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance([java.base at 23-ea](mailto:java.base at 23-ea)/DirectConstructorHandleAccessor.java:62)
> at java.lang.reflect.Constructor.newInstanceWithCaller([java.base at 23-ea](mailto:java.base at 23-ea)/Constructor.java:502)
> at java.lang.reflect.Constructor.newInstance([java.base at 23-ea](mailto:java.base at 23-ea)/Constructor.java:486)
> at sun.util.locale.provider.LocaleProviderAdapter.forType([java.base at 23-ea](mailto:java.base at 23-ea)/LocaleProviderAdapter.java:182)
> at sun.util.locale.provider.LocaleServiceProviderPool.findProviders([java.base at 23-ea](mailto:java.base at 23-ea)/LocaleServiceProviderPool.java:311)
> at sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl([java.base at 23-ea](mailto:java.bas...

Interesting. It seems any attempt to calls like `Date.toString()` early on that triggers a `TimeZone` lookup is going to potentially cause this. A possible workaround is to change `CertificateValidity.toString()` to emit dates as `Date.toInstant().toString()` which is similar to what I did in the fix for JDK-8280890. But this is a separate issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1526645217


From ssahoo at openjdk.org  Mon Mar 18 07:02:27 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Mon, 18 Mar 2024 07:02:27 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v9]
In-Reply-To: <BWjwoDW0iWUv1AAdkoTpvsmXERWfjA-QSTqcj0tjKyc=.0d38af6d-cf65-4d41-a7d8-ec22a2acbcd6@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <BWjwoDW0iWUv1AAdkoTpvsmXERWfjA-QSTqcj0tjKyc=.0d38af6d-cf65-4d41-a7d8-ec22a2acbcd6@github.com>
Message-ID: <xvsypxr5YJvRdyG2yCLy4rKmcaTOaXRn50ct1E74OTQ=.c5bd7965-9cd7-4062-bdba-09214581897a@github.com>

On Fri, 15 Mar 2024 13:46:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Marked as reviewed by ssahoo (Committer).

test/jdk/sun/security/krb5/auto/LoginModuleDebug.java line 32:

> 30: import com.sun.security.auth.module.Krb5LoginModule;
> 31: import jdk.test.lib.process.ProcessTools;
> 32: 

Additional line can be removed.

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

PR Review: https://git.openjdk.org/jdk/pull/18199#pullrequestreview-1942101470
PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1527946029


From djelinski1 at gmail.com  Mon Mar 18 08:59:33 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Mon, 18 Mar 2024 09:59:33 +0100
Subject: Key Missing Feature for IoT
In-Reply-To: <b0146018-0600-4f85-93c1-a438845bbae4@simonbernard.eu>
References: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>
 <CAMrH03+bc7PFjaS3mfZM8U4P_BDyPt9x0Nzmiu5ApP0YEOCxxw@mail.gmail.com>
 <33567a7b-49f0-4845-98ab-921f741a045a@simonbernard.eu>
 <CAMrH03+nLgSyZ8thtB+4m47hBk4=Rg6pt75ZOSQ=zjzbztRE=A@mail.gmail.com>
 <b0146018-0600-4f85-93c1-a438845bbae4@simonbernard.eu>
Message-ID: <CAMrH03KAzua0J=n1L7t5pQv_66_1ztT3zqfpCQW=Vb2Uh7tfAg@mail.gmail.com>

Well I think AES-CCM is a decent candidate to start. If you choose to
work on this, you'll need to add support for AES/CCM to the JCE first.
Most of the code is already there: AES is implemented, CTR and CBC are
implemented, AEAD mode is implemented, so it's probably just a matter
of wiring these things together, and adding some known-answer tests,
which you can find here:
https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/CAVP-TESTING-BLOCK-CIPHER-MODES

Yes, you'll need the Oracle Contributor Agreement before you can
contribute code to the JDK. Once you have it, you can open a PR. Use
8176395 in the PR title. The guide contains the instructions for
running selected tests only.

Regarding PSK API, if you could put together a more complete proposal
of the API changes, together with an example of how this would look
from the API consumer side, this would be a good starting point for a
discussion. I know this is a lot to ask, but this is necessary to make
progres on the PSK.

Cheers,
Daniel

pt., 15 mar 2024 o 16:43 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>
> Thx for all this clarification.
>
>  For example, how will the user configure the list of available PSKs?
>
> Regarding PSK API from other libraries :
>
> AdvancedPskStore from Scandium 3.x which is not so straight forward to use mainly because it supports async request : https://github.com/eclipse-californium/californium/blob/3.11.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/AdvancedPskStore.java
>
> PskStore from Scandium 2.x is more simple to understand but no async way to request PSK : https://github.com/eclipse-californium/californium/blob/2.8.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/PskStore.java
>
> PSKKeyManager from Concrypt is a more JSSE oriented API (no async too). I also understand that this API is available when coding for Android but I think there is a drawback a client is not able to select Identity based on InetSocketAddress of destination.
>  - https://android.googlesource.com/platform/frameworks/base/+/ba12af5/core/java/android/net/PskKeyManager.java
>  - https://github.com/google/conscrypt/blob/2.5.2/common/src/main/java/org/conscrypt/PSKKeyManager.java
> Note that this class is deprecated in concrypt : I tried to get more about this : https://github.com/google/conscrypt/issues/1197
>
> TlsPSKIdentityManager is very simple and very limited API from Bouncy Castle : https://github.com/bcgit/bc-java/blob/1.72/tls/src/main/java/org/bouncycastle/tls/TlsPSKIdentityManager.java
>
> Note that most of them would probably have been thought with (D)TLS 1.2 in mind. I don't know if this is adapted for (D)TLS 1.3.
>
> Well, for AES-CCM a pull request would have been nice :)
>
> I'm not so familiar with JSSE API/SunJSSE provider design for now. Do you think AES-CCM is a good candidate to start ?
> I guess if I want to try to help on this, I need to have a look at : https://openjdk.org/guide/ (and also Contribution agreement)
> Oh and working on JSSE when it's time to build/running tests is there a more simple way than building/testing whole JDK ?
>
> Simon
>
> Le 15/03/2024 ? 13:16, Daniel Jeli?ski a ?crit :
>
> Hi Simon,
> Yes, the cipher suites in CipherSuite class are available in both TLS
> and DTLS by default. TLS 1.3 uses different cipher suites from TLS
> 1.2, so both protocols need to be updated.
>
> Regarding backporting to other versions of Java, backports are
> reviewed on a case-by-case basis. TLS changes are usually backported,
> but that's not a given.
>
> RPK is not implemented either; we have a declaration for the relevant
> handshake extensions here:
> https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240,
> but the producers and consumers aren't defined.
>
> Which kind of help do you need ? ?
>
> Well, for AES-CCM a pull request would have been nice :)
> For the other topics, I think we'd need to agree on the scope of the
> API changes needed. For example, how will the user configure the list
> of available PSKs? Will we need an API change? If not, which of the
> available APIs will we use to configure the keys?
>
> Cheers,
> Daniel
>
>
>
>
> pt., 15 mar 2024 o 11:58 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>
> Hi Daniel,
>
> Thx for quick answer.
>
> For PSK and AES, if this is added then this will be also for TLS ? (not only DTLS  right ?) and for version 1.2 and 1.3 ? and also when this feature will be added, would they be available on next JDK version OR also old version ? (e.g. I know some recent security feature was backported in java8)
>
> Today, I was looking at Raw Public Key support (RPK) and I understand this is not supported too. Am I right ?
> RPK is also part of LWM2M specification and also refered in (RFC7925?Section4.3 - TLS / DTLS -Profiles for the Internet of Things) :
> "The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is the first entry point into public key cryptography without having to pay the price of certificates and a public key infrastructure (PKI)."
>
>  Help is welcome.
>
> Which kind of help do you need ? ?
>
> Simon
>
> Le 15/03/2024 ? 11:38, Daniel Jeli?ski a ?crit :
>
> Hi Simon, welcome to security-dev!
>
> You got the situation of DTLS right:
> - PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
> - connection identifier is not implemented, and not on the to-do list yet;
> - AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
> understand correctly, this one should be relatively easier to
> implement, using the implementation of the ChaCha20 cipher as an
> example (see JDK-8140466, JDK-8204192).
>
> It makes perfect sense to add these features to the OpenJDK. They were
> never high enough on the priority list to get implemented. Help is
> welcome.
>
> Cheers,
> Daniel
>
>
> czw., 14 mar 2024 o 17:31 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>
> Hi all,
>
> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
>
> LWM2M is mainly based on coap and coap+tcp protocol.
> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
>
> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
>
> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
>
> My understanding, DTLS 1.2 was added but there is still no support of :
>
> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925?Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
>
> If I missed something and one of those feature is already available let me know.
>
> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
>
> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
> There is also possibility to bind native library but this is not so easy and also have drawback.
> All that solution sounds not so good...
>
> So do you think it could make sense to add this kind of feature in OpenJDK ?
> Or Maybe there is already plan to add it ?
>
> (I hope this is the right place for this kind of question)
>
> Thx,
>
> Simon
>


From jjiang at openjdk.org  Mon Mar 18 09:37:31 2024
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 18 Mar 2024 09:37:31 GMT
Subject: RFR: 8327182: Move serverAlias into the loop [v2]
In-Reply-To: <QQGDYAHvQQjnAADshnfwNns-pfYSwNoagA0jBXLYmqs=.7f8dca2b-8d36-450b-b7a3-b474cfd1965f@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
 <UrquJ4bpwTIZFf4_fEAmyt4Y03oTBzSMN2t9jck8UT0=.32d57362-e2f2-49d5-89a3-1aa44cbcdaf6@github.com>
 <QQGDYAHvQQjnAADshnfwNns-pfYSwNoagA0jBXLYmqs=.7f8dca2b-8d36-450b-b7a3-b474cfd1965f@github.com>
Message-ID: <PGYDYZAo0_PXiZrRFRfKI-3k4um2mT1CFsANaPayQXE=.0cdf6610-5161-4b86-8a07-ebb73c8beed7@github.com>

On Fri, 15 Mar 2024 13:34:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> John Jiang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8327182
>>  - 8327182: Move serverAlias into the loop
>
> Looks good to me. Did you run all JSSE security regression tests?

@seanjmullan 
Thanks for your review!

> Did you run all JSSE security regression tests?

I did run all tests in `javax/net/ssl` and `sun/security/ssl`, and they passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18100#issuecomment-2003333620


From weijun at openjdk.org  Mon Mar 18 13:15:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Mar 2024 13:15:29 GMT
Subject: RFR: 8327818: Implement Kerberos debug with
 sun.security.util.Debug [v9]
In-Reply-To: <xvsypxr5YJvRdyG2yCLy4rKmcaTOaXRn50ct1E74OTQ=.c5bd7965-9cd7-4062-bdba-09214581897a@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
 <BWjwoDW0iWUv1AAdkoTpvsmXERWfjA-QSTqcj0tjKyc=.0d38af6d-cf65-4d41-a7d8-ec22a2acbcd6@github.com>
 <xvsypxr5YJvRdyG2yCLy4rKmcaTOaXRn50ct1E74OTQ=.c5bd7965-9cd7-4062-bdba-09214581897a@github.com>
Message-ID: <3KvvE5EU2YqWp85RLeNo2pbgS82tfuEKx5EwHIMl-jA=.baddb0a5-8fe1-43a3-8ee7-8493203ce6d4@github.com>

On Mon, 18 Mar 2024 06:59:57 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> test/jdk/sun/security/krb5/auto/LoginModuleDebug.java line 32:
> 
>> 30: import com.sun.security.auth.module.Krb5LoginModule;
>> 31: import jdk.test.lib.process.ProcessTools;
>> 32: 
> 
> Additional line can be removed.

IntelliJ IDEA suggested the format. The other imports (non Java SE) and normal imports (Java SE) are separated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18199#discussion_r1528507524


From weijun at openjdk.org  Mon Mar 18 14:30:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Mar 2024 14:30:29 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <RD87A15QGG2SK_C6IRG8xDL7XgOp13r0-C1bZCUf2J4=.cfbc926e-148f-47d4-925b-93bd7b250338@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>
 <RD87A15QGG2SK_C6IRG8xDL7XgOp13r0-C1bZCUf2J4=.cfbc926e-148f-47d4-925b-93bd7b250338@github.com>
Message-ID: <FjarXbLJOmh32ks6gEG5uiOgaNcV6ezBQZ0gG-fCAn8=.7ad1f67a-0c41-4a82-b7f5-ca5b5f11ae03@github.com>

On Sat, 9 Mar 2024 05:40:06 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 525:
>> 
>>> 523:     // Load predefined root certificates from SystemRootCertificates keychain
>>> 524:     // SecTrustCopyAnchorCertificates includes extra root certificates and can not be used here
>>> 525:     if( SecKeychainOpen("/System/Library/Keychains/SystemRootCertificates.keychain", &keychain) != errSecSuccess ) {
>> 
>> I'll study the API more but it looks too implementation-detail dependent to read the file directly. Are there any other APIs? I see one named `SecTrustCopyCustomAnchorCertificates`. Can it be used?
>
> Hi @wangweij , 
> Thank you for review.
> Unfortunately `SecTrustCopyCustomAnchorCertificates` can not be used also. It is used to retrieve certificates from your own created SecTrust. As I know it is not possible to create/load SecTrust with predefined certs without reading`/System/Library/Keychains/SystemRootCertificates.keychain`

Then this is the best solution we can find. I have no more comment and thanks a lot for the patience. You might need to finalize your CSR now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1528674342


From weijun at openjdk.org  Mon Mar 18 15:39:35 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Mar 2024 15:39:35 GMT
Subject: Integrated: 8327818: Implement Kerberos debug with
 sun.security.util.Debug
In-Reply-To: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
References: <LJI6NDjmjisvLP-cI1KT33vK-4GKO3NSA5XeNXL3K_o=.723a10ad-6437-4066-883b-a1004cc88f9c@github.com>
Message-ID: <BtNhOthsjGSLd00czqobRF8a-OvN_e8dZYJq-VWoYvI=.0f843596-c8c4-4172-98ae-6a202b60e019@github.com>

On Mon, 11 Mar 2024 15:31:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Change `Krb5LoginModule` debugging to use `sun.security.util.Debug`.

This pull request has now been integrated.

Changeset: 569b05ad
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/569b05addf69698fc93026b4dca69bc6ca0920b6
Stats:     981 lines in 62 files changed: 165 ins; 126 del; 690 mod

8327818: Implement Kerberos debug with sun.security.util.Debug

Reviewed-by: coffeys, ssahoo

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

PR: https://git.openjdk.org/jdk/pull/18199


From bhuang at openjdk.org  Mon Mar 18 16:52:47 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 18 Mar 2024 16:52:47 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests
Message-ID: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>

This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.

Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
- Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
- Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

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

Commit messages:
 - Clean up temporary files after tests complete.

Changes: https://git.openjdk.org/jdk/pull/18352/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327474
  Stats: 42 lines in 11 files changed: 20 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

PR: https://git.openjdk.org/jdk/pull/18352


From mullan at openjdk.org  Mon Mar 18 17:50:28 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 18 Mar 2024 17:50:28 GMT
Subject: RFR: 8051959: Add decorator options for java.security.debug output
 [v2]
In-Reply-To: <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <C1ih1UIngt0dMg00VELZBJ3nIqom18YfCeZS_blQjv4=.54cebc3f-e3b5-4977-8a7e-0dadf3e4cb06@github.com>
Message-ID: <UKaumFuVs6QTbZKbbgOyK3XE4tpd48mH_7l5IFyyK98=.0cc49088-98ae-40fd-be76-45e20141173e@github.com>

On Thu, 7 Mar 2024 11:57:07 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use default hex output

Marked as reviewed by mullan (Reviewer).

src/java.base/share/classes/sun/security/util/Debug.java line 80:

> 78:                 if (commaIndex == -1) commaIndex = args.length();
> 79:                 threadInfoAll = args.substring(beginIndex, commaIndex).contains("+thread");;
> 80:                 timeStampInfoAll = args.substring(beginIndex, commaIndex).contains("+timestamp");;

extra semi-colon at end of line.

src/java.base/share/classes/sun/security/util/Debug.java line 125:

> 123:         System.err.println("              a timestamp for that debug option");
> 124:         System.err.println("+thread can be appended to any of above options to print");
> 125:         System.err.println("              thread information for that debug option");

How about mentioning caller too? "thread and caller information ..."

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

PR Review: https://git.openjdk.org/jdk/pull/18084#pullrequestreview-1943766266
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1528992108
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1528988533


From abakhtin at openjdk.org  Mon Mar 18 20:25:29 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 18 Mar 2024 20:25:29 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <FjarXbLJOmh32ks6gEG5uiOgaNcV6ezBQZ0gG-fCAn8=.7ad1f67a-0c41-4a82-b7f5-ca5b5f11ae03@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>
 <RD87A15QGG2SK_C6IRG8xDL7XgOp13r0-C1bZCUf2J4=.cfbc926e-148f-47d4-925b-93bd7b250338@github.com>
 <FjarXbLJOmh32ks6gEG5uiOgaNcV6ezBQZ0gG-fCAn8=.7ad1f67a-0c41-4a82-b7f5-ca5b5f11ae03@github.com>
Message-ID: <0QlULa75Q0q4FM7XpzlbD3ZZI8MR6T9F1HMma0abhTI=.a475f58a-2e15-41a1-b512-97fc929e0aa9@github.com>

On Mon, 18 Mar 2024 14:28:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hi @wangweij , 
>> Thank you for review.
>> Unfortunately `SecTrustCopyCustomAnchorCertificates` can not be used also. It is used to retrieve certificates from your own created SecTrust. As I know it is not possible to create/load SecTrust with predefined certs without reading`/System/Library/Keychains/SystemRootCertificates.keychain`
>
> Then this is the best solution we can find. I have no more comment and thanks a lot for the patience. You might need to finalize your CSR now.

Thank you. I've updated CSR and waiting for review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1529226114


From weijun at openjdk.org  Mon Mar 18 20:57:42 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Mar 2024 20:57:42 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <0QlULa75Q0q4FM7XpzlbD3ZZI8MR6T9F1HMma0abhTI=.a475f58a-2e15-41a1-b512-97fc929e0aa9@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>
 <RD87A15QGG2SK_C6IRG8xDL7XgOp13r0-C1bZCUf2J4=.cfbc926e-148f-47d4-925b-93bd7b250338@github.com>
 <FjarXbLJOmh32ks6gEG5uiOgaNcV6ezBQZ0gG-fCAn8=.7ad1f67a-0c41-4a82-b7f5-ca5b5f11ae03@github.com>
 <0QlULa75Q0q4FM7XpzlbD3ZZI8MR6T9F1HMma0abhTI=.a475f58a-2e15-41a1-b512-97fc929e0aa9@github.com>
Message-ID: <FoJnTjDE1lzXvGTJMbtQuE5-EVepWBTohtpfRg6dzMA=.2ee84c70-164d-472a-b6f8-d234298f628f@github.com>

On Mon, 18 Mar 2024 20:22:54 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Then this is the best solution we can find. I have no more comment and thanks a lot for the patience. You might need to finalize your CSR now.
>
> Thank you. I've updated CSR and waiting for review.

I added myself as a reviewer some time ago. You can finalize it and wait for approval.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1529258266


From abakhtin at openjdk.org  Mon Mar 18 20:57:42 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 18 Mar 2024 20:57:42 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <FoJnTjDE1lzXvGTJMbtQuE5-EVepWBTohtpfRg6dzMA=.2ee84c70-164d-472a-b6f8-d234298f628f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>
 <RD87A15QGG2SK_C6IRG8xDL7XgOp13r0-C1bZCUf2J4=.cfbc926e-148f-47d4-925b-93bd7b250338@github.com>
 <FjarXbLJOmh32ks6gEG5uiOgaNcV6ezBQZ0gG-fCAn8=.7ad1f67a-0c41-4a82-b7f5-ca5b5f11ae03@github.com>
 <0QlULa75Q0q4FM7XpzlbD3ZZI8MR6T9F1HMma0abhTI=.a475f58a-2e15-41a1-b512-97fc929e0aa9@github.com>
 <FoJnTjDE1lzXvGTJMbtQuE5-EVepWBTohtpfRg6dzMA=.2ee84c70-164d-472a-b6f8-d234298f628f@github.com>
Message-ID: <tx5GEFyElE5T2Asr-EBq7YBRHh4jnRfYEk8qCU-No-w=.5bc77cb2-7331-4f14-9fb2-45f89e15d10d@github.com>

On Mon, 18 Mar 2024 20:50:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Thank you. I've updated CSR and waiting for review.
>
> I added myself as a reviewer some time ago. You can finalize it and wait for approval.

CSR is in the Proposed state now. Workflow does not allow me to Finalize it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1529264050


From weijun at openjdk.org  Mon Mar 18 21:08:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Mar 2024 21:08:24 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <tx5GEFyElE5T2Asr-EBq7YBRHh4jnRfYEk8qCU-No-w=.5bc77cb2-7331-4f14-9fb2-45f89e15d10d@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>
 <RD87A15QGG2SK_C6IRG8xDL7XgOp13r0-C1bZCUf2J4=.cfbc926e-148f-47d4-925b-93bd7b250338@github.com>
 <FjarXbLJOmh32ks6gEG5uiOgaNcV6ezBQZ0gG-fCAn8=.7ad1f67a-0c41-4a82-b7f5-ca5b5f11ae03@github.com>
 <0QlULa75Q0q4FM7XpzlbD3ZZI8MR6T9F1HMma0abhTI=.a475f58a-2e15-41a1-b512-97fc929e0aa9@github.com>
 <FoJnTjDE1lzXvGTJMbtQuE5-EVepWBTohtpfRg6dzMA=.2ee84c70-164d-472a-b6f8-d234298f628f@github.com>
 <tx5GEFyElE5T2Asr-EBq7YBRHh4jnRfYEk8qCU-No-w=.5bc77cb2-7331-4f14-9fb2-45f89e15d10d@github.com>
Message-ID: <DfYmYkm57jSsy8gPloYu_0wNu2qmWBWOxCedCsIvA5c=.4cc3200a-4694-49a4-9bc6-a5f6f7ae1bb2@github.com>

On Mon, 18 Mar 2024 20:55:17 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> I added myself as a reviewer some time ago. You can finalize it and wait for approval.
>
> CSR is in the Proposed state now. Workflow does not allow me to Finalize it.

Now that it's in Proposed state, Joe will need to move to Provisional first. Since it was already Provisional some time ago and you haven't really updated it since then, I suggest you change it Back to Draft and then directly Finalize it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1529277623


From abakhtin at openjdk.org  Mon Mar 18 21:11:31 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 18 Mar 2024 21:11:31 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <DfYmYkm57jSsy8gPloYu_0wNu2qmWBWOxCedCsIvA5c=.4cc3200a-4694-49a4-9bc6-a5f6f7ae1bb2@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <J1DWXWTJWnWvmig-wijexxscDbJxlWXypX04GSQEOFc=.9ca2274a-82e1-4e96-9476-69b6f03eae49@github.com>
 <RD87A15QGG2SK_C6IRG8xDL7XgOp13r0-C1bZCUf2J4=.cfbc926e-148f-47d4-925b-93bd7b250338@github.com>
 <FjarXbLJOmh32ks6gEG5uiOgaNcV6ezBQZ0gG-fCAn8=.7ad1f67a-0c41-4a82-b7f5-ca5b5f11ae03@github.com>
 <0QlULa75Q0q4FM7XpzlbD3ZZI8MR6T9F1HMma0abhTI=.a475f58a-2e15-41a1-b512-97fc929e0aa9@github.com>
 <FoJnTjDE1lzXvGTJMbtQuE5-EVepWBTohtpfRg6dzMA=.2ee84c70-164d-472a-b6f8-d234298f628f@github.com>
 <tx5GEFyElE5T2Asr-EBq7YBRHh4jnRfYEk8qCU-No-w=.5bc77cb2-7331-4f14-9fb2-45f89e15d10d@github.com>
 <DfYmYkm57jSsy8gPloYu_0wNu2qmWBWOxCedCsIvA5c=.4cc3200a-4694-49a4-9bc6-a5f6f7ae1bb2@github.com>
Message-ID: <B9uJKGvW8sKHyz2oQVKh8vyWZ4IoBE6DOI_s2nt1p5o=.9b9ac7b6-d336-4fb0-ba43-c5e28ddc872d@github.com>

On Mon, 18 Mar 2024 21:05:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> CSR is in the Proposed state now. Workflow does not allow me to Finalize it.
>
> Now that it's in Proposed state, Joe will need to move to Provisional first. Since it was already Provisional some time ago and you haven't really updated it since then, I suggest you change it Back to Draft and then directly Finalize it.

Thank you. Moved to Finalized

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1529282007


From weijun at openjdk.org  Mon Mar 18 21:26:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Mar 2024 21:26:25 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
Message-ID: <GMKAjaEm9LgGLQ0oGtR1k73lri7ZZmU007adeJX2rfs=.3667a0c6-c747-4114-94f6-81a03c4b25ff@github.com>

On Fri, 23 Feb 2024 23:07:07 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Load root certificates from SystemRootCertificates.keychain

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16722#pullrequestreview-1944229109


From alanb at openjdk.org  Mon Mar 18 22:52:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Mar 2024 22:52:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <W4H6LMjZxokSSq71NxDkNNbQgPxQKAJ9unepFW6K2sU=.de53b1b9-60b7-4786-925c-9accf7681f7e@github.com>

On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

test/jdk/java/nio/channels/unixdomain/Bind.java line 191:

> 189:             server.bind(null);
> 190:             UnixDomainSocketAddress usa = (UnixDomainSocketAddress)server.getLocalAddress();
> 191:             usa.getPath().toFile().deleteOnExit();

The test already deletes the file, I think you just want a try-finally here, same comment on a few other tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1529408542


From hchao at openjdk.org  Tue Mar 19 00:03:29 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 19 Mar 2024 00:03:29 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl
Message-ID: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>

For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.

A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:

1. Accept that PKIX+PKCS12 is slow.
2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).

Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.

Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   104.764 ?   3.237  ops/s
SSLHandshake.doHandshake      PKIX     false           TLS  thrpt   15    99.397 ?   5.645  ops/s

Running modified SSLHandshake.java test with the change that caches the PKCS12 keystore entries for PKIX:
Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9580.548 ?  93.887  ops/s
SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   897.413 ?  49.559  ops/s
SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   516.918 ?  54.658  ops/s
SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   472.145 ?  19.537  ops/s
SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9283.989 ? 218.025  ops/s
SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   838.580 ? 100.300  ops/s
SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   533.631 ?  57.975  ops/s
SSLHandshake.doHandshake      PKIX     false           TLS  thrpt   15   535.980 ?  10.160  ops/s

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

Commit messages:
 - Remove synchronized (keyStore) code from ProcessCredentials()
 - Update to address concurrent update and caching mismatch
 - Update cached map properly for PKCS12KeyStore
 - Update credentialsMap to accommodate when there is a change in the underlying KeyStore
 - 8322767: TLS full handshake is slow with PKCS12KeyStore and X509KeyManagerImpl

Changes: https://git.openjdk.org/jdk/pull/17956/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322767
  Stats: 240 lines in 2 files changed: 234 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17956/head:pull/17956

PR: https://git.openjdk.org/jdk/pull/17956


From mdonovan at openjdk.org  Tue Mar 19 00:03:29 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 19 Mar 2024 00:03:29 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl
In-Reply-To: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
Message-ID: <tGiMqJYgPkqX9PSi9CGxuLw_JgSQ3HJEp-NH43khZ-w=.f0fb7663-0de4-44d6-acae-295570dad55b@github.com>

On Thu, 22 Feb 2024 01:14:24 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
> 
> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
> 
> 1. Accept that PKIX+PKCS12 is slow.
> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
> 
> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
> 
> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   104.764 ?   3.237  ops/s
> SSLHandshak...

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 194:

> 192:                 }
> 193:             } catch (Exception e) {
> 194:                 // ignore

Should this exception be logged?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1509051768


From hchao at openjdk.org  Tue Mar 19 00:03:29 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 19 Mar 2024 00:03:29 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl
In-Reply-To: <tGiMqJYgPkqX9PSi9CGxuLw_JgSQ3HJEp-NH43khZ-w=.f0fb7663-0de4-44d6-acae-295570dad55b@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <tGiMqJYgPkqX9PSi9CGxuLw_JgSQ3HJEp-NH43khZ-w=.f0fb7663-0de4-44d6-acae-295570dad55b@github.com>
Message-ID: <Sd78OB0Z6X9cYxYNlV7Icev_sOfB0Wb2S_xEoNPQqEI=.5beb6f43-9d67-492b-bd08-a1f99f46be66@github.com>

On Fri, 1 Mar 2024 13:59:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
>> 
>> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
>> 
>> 1. Accept that PKIX+PKCS12 is slow.
>> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
>> 
>> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
>> 
>> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
>> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
>> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
>> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
>> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
>> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
>> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
>> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
>> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   ...
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 194:
> 
>> 192:                 }
>> 193:             } catch (Exception e) {
>> 194:                 // ignore
> 
> Should this exception be logged?

Yes, log is added. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1510655807


From jjiang at openjdk.org  Tue Mar 19 02:06:27 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 19 Mar 2024 02:06:27 GMT
Subject: Integrated: 8327182: Move serverAlias into the loop
In-Reply-To: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
Message-ID: <L5lMKcnoTvtwjU-NqJplIHGMG4EAVOUyo4jKQp4E-ec=.1b030f50-2e00-4f72-8fb3-6b7b6c6dcb63@github.com>

On Mon, 4 Mar 2024 03:58:18 GMT, John Jiang <jjiang at openjdk.org> wrote:

> In method `X509Authentication::createServerPossession`, it looks unnecessary to define variable `serverAlias` out of the for-loop.
> It may be better to move `serverAlias` into that loop to narrow down the scope.

This pull request has now been integrated.

Changeset: 9059727d
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9059727df135dc90311bd476124f090b5766092b
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8327182: Move serverAlias into the loop

Reviewed-by: gli, mullan

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

PR: https://git.openjdk.org/jdk/pull/18100


From jjiang at openjdk.org  Tue Mar 19 02:18:24 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 19 Mar 2024 02:18:24 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl
In-Reply-To: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
Message-ID: <KtFEbjbVJE49sTtjTQX-HAbMWAZVB3tfsl06zBo8coQ=.b47bc2d5-dbd3-406d-9320-8692a3da2a20@github.com>

On Thu, 22 Feb 2024 01:14:24 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
> 
> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
> 
> 1. Accept that PKIX+PKCS12 is slow.
> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
> 
> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
> 
> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   104.764 ?   3.237  ops/s
> SSLHandshak...

@haimaychao 
Just a suggestion.
Could you please re-format those micro bench results to make them more readable?
If you still have the original JMH outputs, it's easy to do that with Markdown.

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

PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2005616296


From jjiang at openjdk.org  Tue Mar 19 06:42:21 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 19 Mar 2024 06:42:21 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl
In-Reply-To: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
Message-ID: <yK9bcsiM--LTenRxL-VYBBFqIAPL02ghyojkeAgtpYo=.a374fab5-866f-4ae5-a9d3-26e246307ea6@github.com>

On Thu, 22 Feb 2024 01:14:24 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
> 
> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
> 
> 1. Accept that PKIX+PKCS12 is slow.
> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
> 
> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
> 
> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   104.764 ?   3.237  ops/s
> SSLHandshak...

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 82:

> 80:     private final Map<String,Reference<PrivateKeyEntry>> entryCacheMap;
> 81: 
> 82:     private boolean ksP12;

Could `ksP12` also be `final`?

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 106:

> 104:         this.builders = builders;
> 105:         uidCounter = new AtomicLong();
> 106:         KeyStore keyStore = null;

It may be better to define `keyStore` in the below for-loop.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 109:

> 107:         boolean foundPKCS12 = false;
> 108: 
> 109:         for (int i = 0, n = builders.size(); i < n; i++) {

The index `i` just be used for retrieving the elements from the list, then it can apply enhanced for-loop.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 339:

> 337:             return Arrays.equals(cachedCerts, newCerts);
> 338:         } catch (Exception e) {
> 339:             return false;

Should this exception be logged?

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 356:

> 354:         }
> 355: 
> 356:         PrivateKeyEntry privateKeyEntry = (PrivateKeyEntry) newEntry;

Would you like to apply pattern matching for `instanceof`?

if (!(newEntry instanceof PrivateKeyEntry privateKeyEntry)) {
    return false;
}

PrivateKey privateKey = privateKeyEntry.getPrivateKey();

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 410:

> 408:             return mapEntryUpdated;
> 409:         } catch (Exception e) {
> 410:             return false;

Should this exception be logged?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1529787871
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1529792043
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1529796340
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1529803092
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1529801037
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1529810729


From pkoppula at openjdk.org  Tue Mar 19 07:18:24 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Tue, 19 Mar 2024 07:18:24 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message
Message-ID: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>

JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.

According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.

https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

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

Commit messages:
 - JDK-8326643

Changes: https://git.openjdk.org/jdk/pull/18372/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326643
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18372.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18372/head:pull/18372

PR: https://git.openjdk.org/jdk/pull/18372


From jjiang at openjdk.org  Tue Mar 19 07:51:20 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 19 Mar 2024 07:51:20 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl
In-Reply-To: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
Message-ID: <lRrdvLbYE_EmhIS-o0VmwArdWaP5cm4DtKGd9I2H1mY=.5b583acc-1564-44be-9b93-8b8f43bdb08f@github.com>

On Thu, 22 Feb 2024 01:14:24 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
> 
> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
> 
> 1. Accept that PKIX+PKCS12 is slow.
> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
> 
> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
> 
> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   104.764 ?   3.237  ops/s
> SSLHandshak...

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 335:

> 333: 
> 334:             // Convert KeyStore certificates to X509Certificates
> 335:             X509Certificate[] newCerts = Arrays.copyOf(keyStoreCerts,

Does it have to convert `Certificate[]` to `X509Certificate[]`?
The doc for `Arrays::equals` states
> the two arrays are equal if they contain the same elements in the same order.

It looks this method doesn't care the types of the arrays themselves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1529840614


From djelinski at openjdk.org  Tue Mar 19 08:19:20 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Mar 2024 08:19:20 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message
In-Reply-To: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
Message-ID: <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>

On Tue, 19 Mar 2024 07:13:19 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

We should have a test for this; HelloRetryRequest is sent when the server refuses to use the client-offered key share. The client sends x25519 and secp256r1 key shares by default, so you could create a test where the server accepts only x448, secp384r1, or ffdhe2048.

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 804:

> 802:             shc.conContext.outputRecord.changeWriteCiphers(
> 803:                 SSLWriteCipher.nullTlsWriteCipher(),
> 804:                     (clientHello.sessionId.length() != 0));

Suggestion:

            if (clientHello.sessionId.length() != 0) {
                shc.conContext.outputRecord.encodeChangeCipherSpec();
            }

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

PR Review: https://git.openjdk.org/jdk/pull/18372#pullrequestreview-1945466479
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1529907249


From pkoppula at openjdk.org  Tue Mar 19 08:46:21 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Tue, 19 Mar 2024 08:46:21 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message
In-Reply-To: <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
Message-ID: <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>

On Tue, 19 Mar 2024 08:13:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 804:
> 
>> 802:             shc.conContext.outputRecord.changeWriteCiphers(
>> 803:                 SSLWriteCipher.nullTlsWriteCipher(),
>> 804:                     (clientHello.sessionId.length() != 0));
> 
> Suggestion:
> 
>             if (clientHello.sessionId.length() != 0) {
>                 shc.conContext.outputRecord.encodeChangeCipherSpec();
>             }

Unfortunately, we lack separate properties to control named groups in both the server and client. When running server and client threads in the same JVM, manipulating client hello packets to prompt the server to trigger HRR becomes exceedingly challenging.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1529948640


From djelinski at openjdk.org  Tue Mar 19 09:06:22 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Mar 2024 09:06:22 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message
In-Reply-To: <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
Message-ID: <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>

On Tue, 19 Mar 2024 08:43:38 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 804:
>> 
>>> 802:             shc.conContext.outputRecord.changeWriteCiphers(
>>> 803:                 SSLWriteCipher.nullTlsWriteCipher(),
>>> 804:                     (clientHello.sessionId.length() != 0));
>> 
>> Suggestion:
>> 
>>             if (clientHello.sessionId.length() != 0) {
>>                 shc.conContext.outputRecord.encodeChangeCipherSpec();
>>             }
>
> Unfortunately, we lack separate properties to control named groups in both the server and client. When running server and client threads in the same JVM, manipulating client hello packets to prompt the server to trigger HRR becomes exceedingly challenging.

since [JDK-8281236](https://bugs.openjdk.org/browse/JDK-8281236) / 5d4c71c8bd361af78c90777f17b79e95d8eb5afe / JDK 20 we have setNamedGroups function to control named groups on every endpoint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1529976574


From jjiang at openjdk.org  Tue Mar 19 09:44:20 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 19 Mar 2024 09:44:20 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl
In-Reply-To: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
Message-ID: <Y7zmDHafdqoD0rWPnE3vghON_Er6kmXmb2VJ_bpmLNw=.dd6dc4fc-ec3d-4b54-a40b-074850d531d3@github.com>

On Thu, 22 Feb 2024 01:14:24 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
> 
> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
> 
> 1. Accept that PKIX+PKCS12 is slow.
> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
> 
> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
> 
> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   104.764 ?   3.237  ops/s
> SSLHandshak...

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 358:

> 356:         PrivateKeyEntry privateKeyEntry = (PrivateKeyEntry) newEntry;
> 357:         PrivateKey privateKey = privateKeyEntry.getPrivateKey();
> 358:         Certificate[] certs = privateKeyEntry.getCertificateChain();

The method `getCertificateChain(String)` contains the below codes (line 211~213),

PrivateKeyEntry entry = getEntry(alias);
return entry == null ? null :
        (X509Certificate[])entry.getCertificateChain();

This method assumes `PrivateKeyEntry::getCertificateChain` should always return `X509Certificate[]`.

Then, could line 358 also cast the certificate chain to `X509Certificate[]` directly?
If so, the following codes can be simplified.
It may not need to check the certification type, and could not to convert the `Certificate[]` to `X509Certificate[]`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1530029806


From duke at openjdk.org  Tue Mar 19 11:22:33 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 11:22:33 GMT
Subject: RFR: JDK-8328501 Incorrect @since tags for security java security
 interfaces
Message-ID: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>

The override of `getParams` in these interfaces has an `@since 22`, but the method has been inherited to these interfaces for a long times,


As pointed out by my mentor Jan, 


import javax.crypto.interfaces.DHPublicKey;

public class DhkeyTest {

    public static void main(DHPublicKey key) {
        System.err.println(key.getParams());
    }
    
}


this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here


- the same goes for these other interfaces 

java.security.interfaces.DSAPublicKey
java.security.interfaces.XECPublicKey
java.security.interfaces.DSAPrivateKey
java.security.interfaces.ECPrivateKey
java.security.interfaces.XECPrivateKey
java.security.interfaces.EdECPrivateKey
java.security.interfaces.ECPublicKey
java.security.interfaces.EdECPublicKey
javax.crypto.interfaces.DHPrivateKey
javax.crypto.interfaces.DHPublicKey

- these two should, have @ since 11 though 

java.security.interfaces.RSAPublicKey
java.security.interfaces.RSAPrivateKey

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

Commit messages:
 - removed unnecessary @ since tags
 - fix rest of private/public since tags

Changes: https://git.openjdk.org/jdk/pull/18373/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328501
  Stats: 12 lines in 12 files changed: 0 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18373/head:pull/18373

PR: https://git.openjdk.org/jdk/pull/18373


From weijun at openjdk.org  Tue Mar 19 11:40:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 19 Mar 2024 11:40:24 GMT
Subject: RFR: 8327182: Move serverAlias into the loop [v2]
In-Reply-To: <9NCkcb2YnqfnEc757_Ie2IQH2UynuKmWzcFnJ_dAMDM=.f8cdd7c9-5876-419f-ac59-92a140678f7f@github.com>
References: <KOCjRA_Otz80MocaGnzodYQpJVaRneAdg18iZbjU8dw=.caa114bc-a599-4c1e-9410-60717339fe5a@github.com>
 <i0si2ncO1dvXq8XuCRIak2DO8kk5fjJdMR1-FdHatC4=.57a19856-5482-47bc-94f3-f89c5ae75d80@github.com>
 <43qXuMeOtjp7nLsbSjKK92lRF7jQ5GRPP59px3eQkBI=.38cbf0a5-5287-47ae-b22f-c299c4515931@github.com>
 <ECAWIAPmt1px0MXUBZ77J_z4k4BsaeZKEp9MLwWYEUI=.2c16ab27-4353-406f-aec4-b5b6984ab3ee@github.com>
 <Zji77OofMGtlU1eS8a3_9RC-unMNXcX80I8cfFQI6P8=.b91b0cad-733d-4c49-8ef9-8280b2eaaa6c@github.com>
 <9NCkcb2YnqfnEc757_Ie2IQH2UynuKmWzcFnJ_dAMDM=.f8cdd7c9-5876-419f-ac59-92a140678f7f@github.com>
Message-ID: <WNvJItk51TDZJAKqtbprCMK1nPU7WGQLVHP5MD9cQjc=.c5060731-b8c4-4ba1-8592-3fa6bc4d7153@github.com>

On Mon, 4 Mar 2024 09:14:23 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> At the beginning of a iteration, `km.chooseServerAlias` or `km.chooseEngineServerAlias` tries to find an alias. Then, `serverAlias` should be `null` or an existing alias in the key manager.
>> The `serverAlias` assigned by the last iteration should not used by the current iteration.
>> So, I don't see a bug at the moment.
>
> I know what I missed now. The interface `SSLTransport` only has two implementations `SSLSocketImpl` and `SSLEngineImpl`, so the `serverAlias` is always set at the beginning of the loop. Thanks for your kindly explanation.

A little late. But this means `SSLTransport` can be defined as `sealed` and the assignment here can be modified into a `switch` expression without `default`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18100#discussion_r1530199807


From weijun at openjdk.org  Tue Mar 19 13:23:20 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 19 Mar 2024 13:23:20 GMT
Subject: RFR: JDK-8328501 Incorrect @since tags for security java security
 interfaces
In-Reply-To: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
Message-ID: <Yd6YpbZaj558gO5ptgL_FOTxXMp8vX151knO060Si_A=.1e6a1234-0e58-4076-83a7-f00257598398@github.com>

On Tue, 19 Mar 2024 11:15:56 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> The override of `getParams` in these interfaces was added in java 22 has an `@since 22`, but the method has been inherited to these interfaces for a long times,
> As pointed out by my mentor Jan, 
> 
> 
> import javax.crypto.interfaces.DHPublicKey;
> 
> public class DhkeyTest {
> 
>     public static void main(DHPublicKey key) {
>         System.err.println(key.getParams());
>     }
>     
> }
> 
> 
> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
> 
> 
> - the same goes for these other interfaces 
> 
> java.security.interfaces.DSAPublicKey
> java.security.interfaces.XECPublicKey
> java.security.interfaces.DSAPrivateKey
> java.security.interfaces.ECPrivateKey
> java.security.interfaces.XECPrivateKey
> java.security.interfaces.EdECPrivateKey
> java.security.interfaces.ECPublicKey
> java.security.interfaces.EdECPublicKey
> javax.crypto.interfaces.DHPrivateKey
> javax.crypto.interfaces.DHPublicKey
> 
> - these two should, have @ since 11 though 
> 
> java.security.interfaces.RSAPublicKey
> java.security.interfaces.RSAPrivateKey

I'd like to hear opinions from compiler experts.

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

PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2007161883


From mullan at openjdk.org  Tue Mar 19 14:04:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 19 Mar 2024 14:04:26 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
Message-ID: <N6J_sqOUti_YHT281lP7aWi0GiVgXDCSHWSXyIRwfeY=.129bc187-3069-4cb8-8a5f-a64350114a0b@github.com>

On Fri, 23 Feb 2024 23:07:07 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Load root certificates from SystemRootCertificates.keychain

Is it practical to add a test as described in the bug?:

`java -Djavax.net.ssl.trustStoreType=KeychainStore-ROOT HttpsURLConnectionTest https://github.com/`

This could be added to the `test/jdk/security/infra` test directory since it depends on an external server.

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-2007261252


From duke at openjdk.org  Tue Mar 19 15:11:58 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Tue, 19 Mar 2024 15:11:58 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation [v2]
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <NPeYqZ9I7LkoDcNR45_dJnjLUSfxrDebZ5Vi6HlYEng=.c5db4818-2399-491b-89de-d94a390ae295@github.com>

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

rebarbora-mckvak has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into sunmscapi-8313367
 - 8313367: signHash finds a key in the local machine store
 - 8313367: Local Computer store is opened with max. allowed permissions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16687/files
  - new: https://git.openjdk.org/jdk/pull/16687/files/e1a0a22e..04a47361

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16687&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16687&range=00-01

  Stats: 680566 lines in 7619 files changed: 177754 ins; 178354 del; 324458 mod
  Patch: https://git.openjdk.org/jdk/pull/16687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16687/head:pull/16687

PR: https://git.openjdk.org/jdk/pull/16687


From duke at openjdk.org  Tue Mar 19 15:23:39 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Tue, 19 Mar 2024 15:23:39 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation [v3]
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <Hh1v82SxSC3ARrAL4QZJ53IB8zJRPkwX0WCrZ2kOWDU=.284d1668-3047-41ab-8fe9-a458da5c1830@github.com>

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

rebarbora-mckvak has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - 8313367: signHash finds a key in the local machine store
 - 8313367: Local Computer store is opened with max. allowed permissions

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

Changes: https://git.openjdk.org/jdk/pull/16687/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16687&range=02
  Stats: 12 lines in 1 file changed: 9 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16687/head:pull/16687

PR: https://git.openjdk.org/jdk/pull/16687


From duke at openjdk.org  Tue Mar 19 15:32:24 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Tue, 19 Mar 2024 15:32:24 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation [v3]
In-Reply-To: <Hh1v82SxSC3ARrAL4QZJ53IB8zJRPkwX0WCrZ2kOWDU=.284d1668-3047-41ab-8fe9-a458da5c1830@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <Hh1v82SxSC3ARrAL4QZJ53IB8zJRPkwX0WCrZ2kOWDU=.284d1668-3047-41ab-8fe9-a458da5c1830@github.com>
Message-ID: <C-LLpCl7bOU_HLJAZQDOrB8ujEGybnpItgnU4aGOL5Q=.73675916-eabb-418f-a56e-a1da26f7945c@github.com>

On Tue, 19 Mar 2024 15:23:39 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> rebarbora-mckvak has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8313367: signHash finds a key in the local machine store
>  - 8313367: Local Computer store is opened with max. allowed permissions

First, I am sorry I had to force-push the branch, because I accidentally clicked on some github UI and it merged `master` branch without asking for any confirmation.

I added another commit which fixes signing with some certificates. It seems it matters how the keys are imported in the local machine store and sometimes it means `signHash` is used and produced `Keyset does not exist` error.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-2007496748


From duke at openjdk.org  Tue Mar 19 15:33:34 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 15:33:34 GMT
Subject: RFR: JDK-8328501 Incorrect @since tags for security java security
 interfaces [v2]
In-Reply-To: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
Message-ID: <g5LI1GjpfkbPbv5Diz8ddwZtoEXKSqlHGA0fHSHGgIM=.a2c8d10d-d0d7-4446-b007-fb27edf5d015@github.com>

> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> if there's no `@since`:
> 
> - for methods, look at the `@since` from the method from supertype this method overrides. If there's none from the overridden method, or if the `@since` in the enclosing class is newer that the one from the overridden method, use the `@since`  from the enclosing element. Otherwise, use the `@since` from the overridden method.
> - otherwise, use the `@since` from the enclosing element.
> 
> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
> 
> As pointed out by my mentor Jan, 
> 
> 
> import javax.crypto.interfaces.DHPublicKey;
> 
> public class DhkeyTest {
> 
>     public static void main(DHPublicKey key) {
>         System.err.println(key.getParams());
>     }
>     
> }
> 
> 
> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
> 
> 
> - the same goes for these other interfaces 
> 
> java.security.interfaces.DSAPublicKey
> java.security.interfaces.XECPublicKey
> java.security.interfaces.DSAPrivateKey
> java.security.interfaces.ECPrivateKey
> java.security.interfaces.XECPrivateKey
> java.security.interfaces.EdECPrivateKey
> java.security.interfaces.ECPublicKey
> java.security.interfaces.EdECPublicKey
> javax.crypto.interfaces.DHPrivateKey
> javax.crypto.interfaces.DHPublicKey
> java.security.interfaces.RSAPublicKey
> java.security.interfaces.RSAPrivateKey

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  remove since tags

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18373/files
  - new: https://git.openjdk.org/jdk/pull/18373/files/b5589e40..7ef8b4ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18373/head:pull/18373

PR: https://git.openjdk.org/jdk/pull/18373


From contact at simonbernard.eu  Tue Mar 19 15:36:23 2024
From: contact at simonbernard.eu (Simon Bernard)
Date: Tue, 19 Mar 2024 16:36:23 +0100
Subject: Key Missing Feature for IoT
In-Reply-To: <CAMrH03KAzua0J=n1L7t5pQv_66_1ztT3zqfpCQW=Vb2Uh7tfAg@mail.gmail.com>
References: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>
 <CAMrH03+bc7PFjaS3mfZM8U4P_BDyPt9x0Nzmiu5ApP0YEOCxxw@mail.gmail.com>
 <33567a7b-49f0-4845-98ab-921f741a045a@simonbernard.eu>
 <CAMrH03+nLgSyZ8thtB+4m47hBk4=Rg6pt75ZOSQ=zjzbztRE=A@mail.gmail.com>
 <b0146018-0600-4f85-93c1-a438845bbae4@simonbernard.eu>
 <CAMrH03KAzua0J=n1L7t5pQv_66_1ztT3zqfpCQW=Vb2Uh7tfAg@mail.gmail.com>
Message-ID: <ff5e5561-8f13-46e5-9418-83da2175927d@simonbernard.eu>

> Well I think AES-CCM is a decent candidate to start.
OK, I will probably take time to see if this is something within my reach.
(I have limited time by week to give on that and not an expert on this 
topic, so this will be mid/long term task)

> Regarding PSK API, if you could put together a more complete proposal
> of the API changes, together with an example of how this would look
> from the API consumer side, this would be a good starting point for a
> discussion
I'm not sure a mail is a right way to do that, any recommendation or 
example of this kind of work ?
Eventually I can write some code/documentation in a personal github 
repository.

Regards,
Simon

Le 18/03/2024 ? 09:59, Daniel Jeli?ski a ?crit?:
> Well I think AES-CCM is a decent candidate to start. If you choose to
> work on this, you'll need to add support for AES/CCM to the JCE first.
> Most of the code is already there: AES is implemented, CTR and CBC are
> implemented, AEAD mode is implemented, so it's probably just a matter
> of wiring these things together, and adding some known-answer tests,
> which you can find here:
> https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/CAVP-TESTING-BLOCK-CIPHER-MODES
>
> Yes, you'll need the Oracle Contributor Agreement before you can
> contribute code to the JDK. Once you have it, you can open a PR. Use
> 8176395 in the PR title. The guide contains the instructions for
> running selected tests only.
>
> Regarding PSK API, if you could put together a more complete proposal
> of the API changes, together with an example of how this would look
> from the API consumer side, this would be a good starting point for a
> discussion. I know this is a lot to ask, but this is necessary to make
> progres on the PSK.
>
> Cheers,
> Daniel
>
> pt., 15 mar 2024 o 16:43 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>> Thx for all this clarification.
>>
>>   For example, how will the user configure the list of available PSKs?
>>
>> Regarding PSK API from other libraries :
>>
>> AdvancedPskStore from Scandium 3.x which is not so straight forward to use mainly because it supports async request : https://github.com/eclipse-californium/californium/blob/3.11.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/AdvancedPskStore.java
>>
>> PskStore from Scandium 2.x is more simple to understand but no async way to request PSK : https://github.com/eclipse-californium/californium/blob/2.8.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/PskStore.java
>>
>> PSKKeyManager from Concrypt is a more JSSE oriented API (no async too). I also understand that this API is available when coding for Android but I think there is a drawback a client is not able to select Identity based on InetSocketAddress of destination.
>>   - https://android.googlesource.com/platform/frameworks/base/+/ba12af5/core/java/android/net/PskKeyManager.java
>>   - https://github.com/google/conscrypt/blob/2.5.2/common/src/main/java/org/conscrypt/PSKKeyManager.java
>> Note that this class is deprecated in concrypt : I tried to get more about this : https://github.com/google/conscrypt/issues/1197
>>
>> TlsPSKIdentityManager is very simple and very limited API from Bouncy Castle : https://github.com/bcgit/bc-java/blob/1.72/tls/src/main/java/org/bouncycastle/tls/TlsPSKIdentityManager.java
>>
>> Note that most of them would probably have been thought with (D)TLS 1.2 in mind. I don't know if this is adapted for (D)TLS 1.3.
>>
>> Well, for AES-CCM a pull request would have been nice :)
>>
>> I'm not so familiar with JSSE API/SunJSSE provider design for now. Do you think AES-CCM is a good candidate to start ?
>> I guess if I want to try to help on this, I need to have a look at : https://openjdk.org/guide/ (and also Contribution agreement)
>> Oh and working on JSSE when it's time to build/running tests is there a more simple way than building/testing whole JDK ?
>>
>> Simon
>>
>> Le 15/03/2024 ? 13:16, Daniel Jeli?ski a ?crit :
>>
>> Hi Simon,
>> Yes, the cipher suites in CipherSuite class are available in both TLS
>> and DTLS by default. TLS 1.3 uses different cipher suites from TLS
>> 1.2, so both protocols need to be updated.
>>
>> Regarding backporting to other versions of Java, backports are
>> reviewed on a case-by-case basis. TLS changes are usually backported,
>> but that's not a given.
>>
>> RPK is not implemented either; we have a declaration for the relevant
>> handshake extensions here:
>> https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240,
>> but the producers and consumers aren't defined.
>>
>> Which kind of help do you need ? ?
>>
>> Well, for AES-CCM a pull request would have been nice :)
>> For the other topics, I think we'd need to agree on the scope of the
>> API changes needed. For example, how will the user configure the list
>> of available PSKs? Will we need an API change? If not, which of the
>> available APIs will we use to configure the keys?
>>
>> Cheers,
>> Daniel
>>
>>
>>
>>
>> pt., 15 mar 2024 o 11:58 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>>
>> Hi Daniel,
>>
>> Thx for quick answer.
>>
>> For PSK and AES, if this is added then this will be also for TLS ? (not only DTLS  right ?) and for version 1.2 and 1.3 ? and also when this feature will be added, would they be available on next JDK version OR also old version ? (e.g. I know some recent security feature was backported in java8)
>>
>> Today, I was looking at Raw Public Key support (RPK) and I understand this is not supported too. Am I right ?
>> RPK is also part of LWM2M specification and also refered in (RFC7925?Section4.3 - TLS / DTLS -Profiles for the Internet of Things) :
>> "The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is the first entry point into public key cryptography without having to pay the price of certificates and a public key infrastructure (PKI)."
>>
>>   Help is welcome.
>>
>> Which kind of help do you need ? ?
>>
>> Simon
>>
>> Le 15/03/2024 ? 11:38, Daniel Jeli?ski a ?crit :
>>
>> Hi Simon, welcome to security-dev!
>>
>> You got the situation of DTLS right:
>> - PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
>> - connection identifier is not implemented, and not on the to-do list yet;
>> - AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
>> understand correctly, this one should be relatively easier to
>> implement, using the implementation of the ChaCha20 cipher as an
>> example (see JDK-8140466, JDK-8204192).
>>
>> It makes perfect sense to add these features to the OpenJDK. They were
>> never high enough on the priority list to get implemented. Help is
>> welcome.
>>
>> Cheers,
>> Daniel
>>
>>
>> czw., 14 mar 2024 o 17:31 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>>
>> Hi all,
>>
>> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
>>
>> LWM2M is mainly based on coap and coap+tcp protocol.
>> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
>>
>> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
>>
>> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
>>
>> My understanding, DTLS 1.2 was added but there is still no support of :
>>
>> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925?Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
>> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
>> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
>>
>> If I missed something and one of those feature is already available let me know.
>>
>> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
>>
>> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
>> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
>> There is also possibility to bind native library but this is not so easy and also have drawback.
>> All that solution sounds not so good...
>>
>> So do you think it could make sense to add this kind of feature in OpenJDK ?
>> Or Maybe there is already plan to add it ?
>>
>> (I hope this is the right place for this kind of question)
>>
>> Thx,
>>
>> Simon
>>


From bhuang at openjdk.org  Tue Mar 19 17:58:46 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 19 Mar 2024 17:58:46 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/8472c31f..620f9259

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00-01

  Stats: 136 lines in 5 files changed: 36 ins; 13 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

PR: https://git.openjdk.org/jdk/pull/18352


From karl.scheibelhofer.75 at gmail.com  Sat Mar 16 09:36:29 2024
From: karl.scheibelhofer.75 at gmail.com (Karl Scheibelhofer)
Date: Sat, 16 Mar 2024 10:36:29 +0100
Subject: [External] : Re: PEM API github repo
In-Reply-To: <52811109-CCBA-4602-A3B2-B619A1F3A0F8@oracle.com>
References: <d8f11a64-9159-4bb4-83a3-30147886e0be@oracle.com>
 <CAMrH03J=wX-1Kp+LVasv0-R-NEWBy31_dkb+v4CFNXoksJRfwQ@mail.gmail.com>
 <9c42dd2d-00a2-470f-b319-c2cfb7c10de6@oracle.com>
 <CACSnhuU42nCK3kq1MTxavASOeW_gh_2e5m1=KJ41wy+JEpQ7hg@mail.gmail.com>
 <CACSnhuVUohWjR-WeiCQBBfB81M=322e7fikHznBF8RirGR+Gkg@mail.gmail.com>
 <52811109-CCBA-4602-A3B2-B619A1F3A0F8@oracle.com>
Message-ID: <CACSnhuWo4EDF=y4dx5hm0mQTqujx_BVhu0OzXeygFmdAv_dpdA@mail.gmail.com>

Hi Tony,

find my replies inline...

On Mon, Mar 11, 2024 at 6:13?AM Anthony Scarpino
<anthony.scarpino at oracle.com> wrote:
>
>
>
> On Mar 9, 2024, at 8:09?AM, Karl Scheibelhofer <karl.scheibelhofer.75 at gmail.com> wrote:
>
> ?
> ... try again from from my subscribed mail account...
>
>> Hi Tony,
>>
>> in my jdk fork, I created a branch named pem-feedback-karl.
>>
>> https://github.com/KarlScheibelhofer/jdk/tree/pem-feedback-karl
>>
>> It is based on the pem branch of your jdk fork.
>> In this pem-feedback-karl branch, I did some cleanup without changing
>> the API. Your tests pass as before.
>>
>> My original pem-keystore implementation for the SUN provider is in this branch
>>
>> https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore
>>
>> It did not use the PEM API.
>>
>> In the branch
>>
>> https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore-pem-api
>>
>> I modified the PEM keystore implementation to use the PEMDecoder and PEMEncoder.
>> To make it pass all tests, I had to fix some issues with the PEM api:
>>
>> * fix missing line-breaks when encoding certificates (and CRLs)
>> * use uniform line length for PEM encoding keys and certificates
>
>
> It sounds like I did my repo update to use MimeEncoder after you had pulled the changes.

In which repo can i see the version using MimeEncoder that you
mentioned? i can't find this in
https://github.com/ascarpino/jdk/commits/pem

>
>> During this work, I took some notes regarding the PEM api:
>>
>> * Consider decoupling the raw PEM encoding and decoding from SecurityObject.
>>   This would make the API usable for general purpose PEM encoding and
>> decoding, not just for keys and certificates, as it is now.
>
>
> There has been discussions about adding a generic PEM object that would have methods to return the header, footer, and PEM text, instead of processing into a class or KeySpec. Is there something more ?general purpose? you had it mind?

In addition to header, footer and PEM text, for my keystore
implementation, I would need the preceding PEM explanatory text lines,
i.e. the lines before the header line

>
>> * For this PEM keystore implementation it is essential to parse the
>> preceding explanatory text lines.
>>   The PEM decoder should support this.
>>   As it is now, the keystore implementation must parse the PEM objects
>> itself, including reading PEM header and footer lines.
>>   Having to handle half the work in the application diminishes the
>> value of the PEMDecoder.
>>   It only delegates the decoding of certificates and keys to the PEMDecoder.
>>
>> * PEMDecoder should be able to handle or pass through unknown PEM
>> objects gracefully.
>>   Otherwise the application has to check the PEM labels in advance
>> itself, which does not make sense.
>
>
> So do you not have a structured data file?  I expected the application would parse its own metadata, then when the structured code got to a PEM tag, it would pass the InputStream to PEMDecoder.
>
> I am concerned about a generic PEM object storing an unknown amount of application metadata and returning it back.  I feel handling non-PEM should be in the scope of the encoder/decoder.


No, there is no structured data file. Just a PEM file which contains
multiple PEM objects, typically certificates and private keys. It is
common practice to have related certificates and keys in a single
file. The explanatory text lines contain the name of the key, because
this is the place specified in PEM RFC to hold meta information like
this. To enable implementing a consistent Java Keystore with PEM
format, I see this necessary. At least, I found no other way for
handling key alias names as required  by Java Keystore. If you know
another way, please let me know.

The files that my keystore implementation reads and writes are just
completely PEM format, from first to last line.

>
>>
>> * Though supporting InputStream/OutputStream for reading and writing
>> makes sense,
>>   supporting Reader/Writer feels even more essential for robust
>> support for all character encodings.
>>   Multi-Byte character encodings won't work with InputStream/OutputStream.
>
>
> A Reader will read ahead, buffering the input data.  I saw this when I had `decode(Reader)` in the API.  It would return the first PEM object, but the read pointer was at the end of the file, missing the remaining PEM objects.

An application or a Keystore implementation gets a stream providing
multiple concatenated PEM objects that are in this keystore object. It
needs to get all the PEM objects handing in that stream, i.e. in
essence hand in the input stream and get out a list of pem objects
containing certificates, keys and their names.

>
> Is the multi-byte characters for the keystore metadata?  I don?t see how this affects Base64.

Try feeding in a UTF-16 encoded PEM file. I guess it won't work with
InputStream. Because the current implementation expects one character
in each byte.

>
>>
>> * The standard line separator for PEM is "\r\n".
>>   For PEM files stored in a typical linux file system, "\n" is
>> typically used, however.
>>   See the output of openssl, for example.
>>   Because there are still several command line utilities that do not
>> work well with "\r\n" line breaks.
>>   Supporting a different line-separator than "\r\n" is a good idea in
>> my opinion.
>>   Base64.getMimeEncoder also supports selecting a custom line separator.
>
>
> The standards I saw says the line separator is ?\r\n?.  I realize decoders have to be more flexible because many may not follow the line separators or cut-n-paste removes them.  I think having a configurable line separator for encoding is likely to create more incompatibility rather than lessen for cross-platform and using with other applications.

Yes, the PEM standard say"\r\n". But widely used tools like openssl
produce "\n". In practice, this is just the better solution. It goes
better with most other tools and version control.
I would opt for "\r\n" by default, but provide an option for "\n" only.
There must be a reason why Base64.getMimeEncoder supports custom line
separators.

>
>>
>> * The PEMEncoder encodes the predefined SecurityObjects only.
>>   There is no way to use it to PEM encoded any other type of object.
>>   Consider opening a path to generic use.
>
>
> The generic PEM object I mentioned previously I think fits this case.  It would still be a SecurityObject as I don?t see value in passing in any object.

I will have a look at it. Can you provide a link to your implementation?

>
>>
>> * If an application has a DER encoded certificate, it has to decode
>> and parse the certificate before
>>   it can encode it using PEMEncoder.
>>   This is inconvenient.
>
>
> Yeah, there isn?t an EncodedKeySpec equivalent.  I?d have to think if there is an easy way to do this without causing more problems.  Given the purpose is going between Java Objects and PEM, accepting random data isn?t a goal.  Maybe something that can be addressed with a generic PEM object.

As a fallback simply allow passing in a byte[] that is base64 encoded,
i.e. the result of Certificate.getEncoded().

Thank you!

Karl

...


From weijun at openjdk.org  Wed Mar 20 01:57:51 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 01:57:51 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v7]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <2WzsZtBsmeZkMUZKZS_4IGdfxGH19xrE88_uzSgRVLg=.1229163e-adb6-418e-be61-7eab69e1ed32@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - years and comments
 - Merge branch 'master' into 8296244
 - revert changes to MBeanServerFileAccessController.java
 - Merge branch 'master' into 8296244
 - revert some test changes, spec change for subject
 - fix MBeanServerFileAccessController, more test in SM
 - JMX needs SM
 - Resolve Alan's comments
 - remove exe bits
 - remove x bit
 - ... and 1 more: https://git.openjdk.org/jdk/compare/bb164794...dfa22af0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/80810b54..dfa22af0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=05-06

  Stats: 384142 lines in 1493 files changed: 18191 ins; 81433 del; 284518 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472


From mbalao at redhat.com  Wed Mar 20 02:24:42 2024
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 19 Mar 2024 22:24:42 -0400
Subject: KDF JEP for the Java Platform
In-Reply-To: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
References: <349FFB87-C096-4BBD-A74E-91DDD0AAE25D@oracle.com>
Message-ID: <0a405748-7dff-4ce0-b7c1-0ba5714624be@redhat.com>

Hi Kevin,

I implemented a prototype for HKDF derivation with SunPKCS11. This was 
tested with the NSS Software Token v3.90, both in FIPS and non-FIPS 
configurations. Testing includes the 7 vectors in RFC 5869 (*), 
derivation of a DH base key, derivation of a ECDH base key and use of 
derived keys for Cipher and Mac services. In each case I did key and 
data derivation under the following modes: extraction-expansion, 
extraction and expansion. All of this should be enough coverage of TLS 
1.3 key derivation. I'll adjust this prototype to the final API ?once we 
have it? and make a proposal.

I would like to add two more pieces of feedback from the SunPKCS11 side:

For TLS 1.3 derivation, it would be desirable to handle the salt as a 
Key object in the HKDFParameterSpec (instead of a byte[]). The TLS 1.3 
key schedule [1] takes the salt from a previous key derivation ?so it's 
naturally a key?, except for the Early Secret where it's all 0's. For 
SunPKCS11 this has 2 concrete benefits: 1) we don't need to re-build the 
salt as a key each time and 2) we can operate in FIPS-compliant mode.

Different implementations of the API may need similar consistency checks 
over the derivation parameters. Would be good if these checks are done 
at HKDFParameterSpec construction time. For example, output length has 
to be greater than 0.

Regards,
Martin.-

--
(*) Vector #1 does not work in FIPS mode because the salt's length is 
too small.
[1] - https://datatracker.ietf.org/doc/html/rfc8446#section-7.1


On 7/20/23 16:05, Kevin Driver wrote:
> As a newly minted committer and Oracle employee tasked with the 
> following, I thought I should send an introductory mail to the list and 
> start a discussion on adding a standard API for key derivation functions 
> (KDFs) to the Java Platform. You may have noticed the KEM [1] APIs and 
> associated implementation coming in JDK 21. KDF [2] is another building 
> block in support of HPKE [3] (which requires KEM and KDF as 
> dependencies/primitives). HPKE will become important during the 
> transition to post-quantum cryptography.
> 
> The concept of a KDF implementation within the security libraries is not 
> entirely new (a JEP was put forth previously but withdrawn [4]); however 
> it is time to formalize an API, add some additional implementations, and 
> make some older implementations available for use in a more standard way.
> 
> We look forward to your feedback on the below proposal and would be 
> interested in any thoughts on the design considerations listed at the end.
> 
> To wit, I?ll try to give a brief overview of the following:
> 
> - high level design
> - current status
> - design considerations
> 
> **High Level Design**
> 
> In general, this diagram encapsulates a lot of our intended trajectory 
> (see attached diagram).
> 
> The new KDF APIs will serve as an umbrella over an RFC 5869 [5] 
> implementation of HKDF, existing PBE implementations, and future 
> implementations. However, our current plans are to allow algorithms, 
> such as PBE, to continue to be accessible in the manner they are today 
> (with possible deprecation at some point in the future).
> 
> In addition, JSSE has a ?sibling? implementation of something very 
> similar to RFC 5869 (but perhaps somewhat specialized for the JSSE 
> use-cases), so it will likely be merged into the ?proper?/main RFC 5869 
> implementation and called/utilized in a fashion similar to how JSSE does 
> today. One goal is certainly to be minimally disruptive to JSSE 
> implementation code where possible, so as to not incur a massive 
> retesting/validation effort for TLS.
> 
> Also related to JSSE, one of the reasons for the Tls* classes (mentioned 
> in the SunJCE provider) being located in restricted packages, I?m told, 
> is because there was not yet a KDF API available. The classes described 
> are in:
> 
> ? sun.security.internal.interfaces
> ? sun.security.internal.spec
> 
> A side-goal/benefit of this work will be to relocate the above classes 
> out of their restricted packages (ie - not in sun.security.internal any 
> longer).
> 
> **Current Status**
> 
> Currently we (Oracle) have a set of KDF framework APIs as well as an 
> implementation of RFC 5869 and a TLSPrfKDF implementation, which were 
> developed previously but not yet made available. I have taken up this 
> work, and I?m working through suggested modifications and/or 
> improvements. There are, however, a few ongoing points of discussion, a 
> couple of which I will be bringing forward today.
> 
> **Design Considerations**
> 
> ? What, if any, JSSE implementations are there outside of Oracle which 
> might be affected by the choice to relocate the Tls* classes from their 
> SunJCE restricted packages? We are interested in speaking with those 
> affected by this potential change.
> ? APIs in JCE have historically been ?multi-phased? (ie - Cipher?s init, 
> update, doFinal). However, it is also somewhat en vogue to lean toward 
> immutability as much as possible. We?re weighing the relative merits of 
> a ?one and done? style API with lots of parameters vs a more 
> ?traditional? multi-phased approach.
> 
> [1]?https://openjdk.org/jeps/452
> [2]?https://en.wikipedia.org/wiki/Key_derivation_function
> [3]?https://www.rfc-editor.org/rfc/rfc9180.html
> [4]?https://bugs.openjdk.org/browse/JDK-8189808
> [5]?https://www.rfc-editor.org/rfc/rfc5869.html
> 
> I will followup in a few weeks with more detail and will look forward to 
> your feedback in the meantime. Thanks for your interest/participation!
> 
> Kevin Driver
> Mobile: +1.512.431.5690
> Java Security Libraries
> 
> 
> 



From valeriep at openjdk.org  Wed Mar 20 02:48:32 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 20 Mar 2024 02:48:32 GMT
Subject: RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are
 problematic
Message-ID: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>

Existing legacy mechanism check disables mechanism(s) when the support is partial, e.g. supports decryption but not encryption, or supports verification but not signing. Some mechanisms can be used for both encryption/decryption and sign/verify such as RSA related ones. If the particular mechanism supports sign/verify/decryption but not encryption, it'd be disabled as a result. Fine tune the legacy mechanism check with the service type, i.e. supports encryption for Cipher,  sign for Signature, so the mechanism is disabled based on the service type.
For completeness sake, I also added a PKCS11 provider configuration option to control this check (default is true, disable mechanisms with partial support).

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

Commit messages:
 - 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are problematic

Changes: https://git.openjdk.org/jdk/pull/18387/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18387&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293345
  Stats: 51 lines in 2 files changed: 25 ins; 25 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18387/head:pull/18387

PR: https://git.openjdk.org/jdk/pull/18387


From mbalao at openjdk.org  Wed Mar 20 03:44:44 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 20 Mar 2024 03:44:44 GMT
Subject: RFR: 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS
 Software Token
Message-ID: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>

Hi,

I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token". See more details in the JBS ticket [1].

No regressions observed in jdk/sun/security/pkcs11.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.org/browse/JDK-8328556

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

Commit messages:
 - 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token

Changes: https://git.openjdk.org/jdk/pull/18389/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18389&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328556
  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18389.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18389/head:pull/18389

PR: https://git.openjdk.org/jdk/pull/18389


From jwaters at openjdk.org  Wed Mar 20 06:07:22 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 20 Mar 2024 06:07:22 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v9]
In-Reply-To: <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
 <tiWDP4SUdXm3xYLAp6l5JH1unz1qJgbZG1WxAHyOF2Y=.d6804d0b-347b-4715-a753-0bce5df00d8e@github.com>
Message-ID: <0BawZnIsRa8G1r1SB-kUR-LxIMQg4D_VRQ3M9vMQ2Zo=.21a4c2d0-3f20-4e47-bc25-62e8a9215c6f@github.com>

On Fri, 19 Jan 2024 01:57:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   std:: qualifier sspi.cpp

Don't close. I plan on figuring out an acceptable solution to this, one way or another

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

PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-2008710212


From pkoppula at openjdk.org  Wed Mar 20 07:39:53 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 07:39:53 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v2]
In-Reply-To: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
Message-ID: <YfdMRwWOScIBY37nLtg0v6xq7oxhe6hA1v1ZwQcI9ec=.6ff8a6b5-8841-4657-9ced-93f2808a0938@github.com>

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8326643

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18372/files
  - new: https://git.openjdk.org/jdk/pull/18372/files/01de06d6..40051354

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=00-01

  Stats: 289 lines in 1 file changed: 289 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18372.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18372/head:pull/18372

PR: https://git.openjdk.org/jdk/pull/18372


From pkoppula at openjdk.org  Wed Mar 20 07:39:53 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 07:39:53 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v2]
In-Reply-To: <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
Message-ID: <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>

On Tue, 19 Mar 2024 09:03:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Unfortunately, we lack separate properties to control named groups in both the server and client. When running server and client threads in the same JVM, manipulating client hello packets to prompt the server to trigger HRR becomes exceedingly challenging.
>
> since [JDK-8281236](https://bugs.openjdk.org/browse/JDK-8281236) / 5d4c71c8bd361af78c90777f17b79e95d8eb5afe / JDK 20 we have setNamedGroups function to control named groups on every endpoint.

Thank you, I added a test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531620236


From pkoppula at openjdk.org  Wed Mar 20 07:46:20 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 07:46:20 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v2]
In-Reply-To: <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
Message-ID: <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>

On Wed, 20 Mar 2024 07:36:29 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> since [JDK-8281236](https://bugs.openjdk.org/browse/JDK-8281236) / 5d4c71c8bd361af78c90777f17b79e95d8eb5afe / JDK 20 we have setNamedGroups function to control named groups on every endpoint.
>
> Thank you, I added a test

> 

IMO, utilizing shc.conContext.outputRecord.changeWriteCiphers() is a cleaner approach, and we've used the same method in other instances.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531626263


From pkoppula at openjdk.org  Wed Mar 20 07:55:33 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 07:55:33 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v3]
In-Reply-To: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
Message-ID: <aIk66eubrb3qqXCnEo6EJYuUvS6WiKQjckRqZOr5Nh4=.f4e82d84-902e-4b18-a1dd-ab6c91e5380d@github.com>

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8326643

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18372/files
  - new: https://git.openjdk.org/jdk/pull/18372/files/40051354..8250dc60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/18372


From djelinski at openjdk.org  Wed Mar 20 08:16:19 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Mar 2024 08:16:19 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v3]
In-Reply-To: <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
Message-ID: <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>

On Wed, 20 Mar 2024 07:44:01 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> Thank you, I added a test
>
>> 
> 
> IMO, utilizing shc.conContext.outputRecord.changeWriteCiphers() is a cleaner approach, and we've used the same method in other instances.

Thanks for adding the test.

My main concern with using changeWriteCiphers here is that it sends the wrong message to the future readers of this code. It suggests that we want to actually change the cipher, and sending CCS is just a side effect. Note that all other uses of changeWriteCiphers actually change the write ciphers. If you don't want to use the other method, at least add a comment explaining why you're using it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531654271


From pkoppula at openjdk.org  Wed Mar 20 08:29:21 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 08:29:21 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v3]
In-Reply-To: <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
Message-ID: <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>

On Wed, 20 Mar 2024 08:13:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> 
>> 
>> IMO, utilizing shc.conContext.outputRecord.changeWriteCiphers() is a cleaner approach, and we've used the same method in other instances.
>
> Thanks for adding the test.
> 
> My main concern with using changeWriteCiphers here is that it sends the wrong message to the future readers of this code. It suggests that we want to actually change the cipher, and sending CCS is just a side effect. Note that all other uses of changeWriteCiphers actually change the write ciphers. If you don't want to use the other method, at least add a comment explaining why you're using it here.

Thanks for the review, in the comments I mentioned that,  this call sends a dummy change_cipher_spec (CCS) record. I hope, It explains why we are calling it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531668446


From pkoppula at openjdk.org  Wed Mar 20 08:48:34 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 08:48:34 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v4]
In-Reply-To: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
Message-ID: <v_4XgQ7rwtRGzKCNlMnsXLOFiP58q9fJ1WqOFY3lDes=.05d930e9-7ec7-408f-9ae2-95ba7289f45b@github.com>

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8326643

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18372/files
  - new: https://git.openjdk.org/jdk/pull/18372/files/8250dc60..a5232303

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/18372


From djelinski1 at gmail.com  Wed Mar 20 09:19:07 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Wed, 20 Mar 2024 10:19:07 +0100
Subject: Key Missing Feature for IoT
In-Reply-To: <ff5e5561-8f13-46e5-9418-83da2175927d@simonbernard.eu>
References: <eb8f6b21-5eeb-4830-af83-d3b5301feb71@simonbernard.eu>
 <CAMrH03+bc7PFjaS3mfZM8U4P_BDyPt9x0Nzmiu5ApP0YEOCxxw@mail.gmail.com>
 <33567a7b-49f0-4845-98ab-921f741a045a@simonbernard.eu>
 <CAMrH03+nLgSyZ8thtB+4m47hBk4=Rg6pt75ZOSQ=zjzbztRE=A@mail.gmail.com>
 <b0146018-0600-4f85-93c1-a438845bbae4@simonbernard.eu>
 <CAMrH03KAzua0J=n1L7t5pQv_66_1ztT3zqfpCQW=Vb2Uh7tfAg@mail.gmail.com>
 <ff5e5561-8f13-46e5-9418-83da2175927d@simonbernard.eu>
Message-ID: <CAMrH03LHP3aC+RYx00McTbdOtBMknwwbwVNGxugEzG3LWOkoTA@mail.gmail.com>

> any recommendation or example of this kind of work?

Check out these JEPs, the description section:
https://openjdk.org/jeps/329
https://openjdk.org/jeps/8245551
https://openjdk.org/jeps/8281710

In the PSK case the main question is, how is the user going to
configure the keys?
Cheers,
Daniel

wt., 19 mar 2024 o 16:36 Simon Bernard <contact at simonbernard.eu> napisa?(a):
>
> > Well I think AES-CCM is a decent candidate to start.
> OK, I will probably take time to see if this is something within my reach.
> (I have limited time by week to give on that and not an expert on this
> topic, so this will be mid/long term task)
>
> > Regarding PSK API, if you could put together a more complete proposal
> > of the API changes, together with an example of how this would look
> > from the API consumer side, this would be a good starting point for a
> > discussion
> I'm not sure a mail is a right way to do that, any recommendation or
> example of this kind of work ?
> Eventually I can write some code/documentation in a personal github
> repository.
>
> Regards,
> Simon
>
> Le 18/03/2024 ? 09:59, Daniel Jeli?ski a ?crit :
> > Well I think AES-CCM is a decent candidate to start. If you choose to
> > work on this, you'll need to add support for AES/CCM to the JCE first.
> > Most of the code is already there: AES is implemented, CTR and CBC are
> > implemented, AEAD mode is implemented, so it's probably just a matter
> > of wiring these things together, and adding some known-answer tests,
> > which you can find here:
> > https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/CAVP-TESTING-BLOCK-CIPHER-MODES
> >
> > Yes, you'll need the Oracle Contributor Agreement before you can
> > contribute code to the JDK. Once you have it, you can open a PR. Use
> > 8176395 in the PR title. The guide contains the instructions for
> > running selected tests only.
> >
> > Regarding PSK API, if you could put together a more complete proposal
> > of the API changes, together with an example of how this would look
> > from the API consumer side, this would be a good starting point for a
> > discussion. I know this is a lot to ask, but this is necessary to make
> > progres on the PSK.
> >
> > Cheers,
> > Daniel
> >
> > pt., 15 mar 2024 o 16:43 Simon Bernard <contact at simonbernard.eu> napisa?(a):
> >> Thx for all this clarification.
> >>
> >>   For example, how will the user configure the list of available PSKs?
> >>
> >> Regarding PSK API from other libraries :
> >>
> >> AdvancedPskStore from Scandium 3.x which is not so straight forward to use mainly because it supports async request : https://github.com/eclipse-californium/californium/blob/3.11.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/AdvancedPskStore.java
> >>
> >> PskStore from Scandium 2.x is more simple to understand but no async way to request PSK : https://github.com/eclipse-californium/californium/blob/2.8.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/PskStore.java
> >>
> >> PSKKeyManager from Concrypt is a more JSSE oriented API (no async too). I also understand that this API is available when coding for Android but I think there is a drawback a client is not able to select Identity based on InetSocketAddress of destination.
> >>   - https://android.googlesource.com/platform/frameworks/base/+/ba12af5/core/java/android/net/PskKeyManager.java
> >>   - https://github.com/google/conscrypt/blob/2.5.2/common/src/main/java/org/conscrypt/PSKKeyManager.java
> >> Note that this class is deprecated in concrypt : I tried to get more about this : https://github.com/google/conscrypt/issues/1197
> >>
> >> TlsPSKIdentityManager is very simple and very limited API from Bouncy Castle : https://github.com/bcgit/bc-java/blob/1.72/tls/src/main/java/org/bouncycastle/tls/TlsPSKIdentityManager.java
> >>
> >> Note that most of them would probably have been thought with (D)TLS 1.2 in mind. I don't know if this is adapted for (D)TLS 1.3.
> >>
> >> Well, for AES-CCM a pull request would have been nice :)
> >>
> >> I'm not so familiar with JSSE API/SunJSSE provider design for now. Do you think AES-CCM is a good candidate to start ?
> >> I guess if I want to try to help on this, I need to have a look at : https://openjdk.org/guide/ (and also Contribution agreement)
> >> Oh and working on JSSE when it's time to build/running tests is there a more simple way than building/testing whole JDK ?
> >>
> >> Simon
> >>
> >> Le 15/03/2024 ? 13:16, Daniel Jeli?ski a ?crit :
> >>
> >> Hi Simon,
> >> Yes, the cipher suites in CipherSuite class are available in both TLS
> >> and DTLS by default. TLS 1.3 uses different cipher suites from TLS
> >> 1.2, so both protocols need to be updated.
> >>
> >> Regarding backporting to other versions of Java, backports are
> >> reviewed on a case-by-case basis. TLS changes are usually backported,
> >> but that's not a given.
> >>
> >> RPK is not implemented either; we have a declaration for the relevant
> >> handshake extensions here:
> >> https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240,
> >> but the producers and consumers aren't defined.
> >>
> >> Which kind of help do you need ? ?
> >>
> >> Well, for AES-CCM a pull request would have been nice :)
> >> For the other topics, I think we'd need to agree on the scope of the
> >> API changes needed. For example, how will the user configure the list
> >> of available PSKs? Will we need an API change? If not, which of the
> >> available APIs will we use to configure the keys?
> >>
> >> Cheers,
> >> Daniel
> >>
> >>
> >>
> >>
> >> pt., 15 mar 2024 o 11:58 Simon Bernard <contact at simonbernard.eu> napisa?(a):
> >>
> >> Hi Daniel,
> >>
> >> Thx for quick answer.
> >>
> >> For PSK and AES, if this is added then this will be also for TLS ? (not only DTLS  right ?) and for version 1.2 and 1.3 ? and also when this feature will be added, would they be available on next JDK version OR also old version ? (e.g. I know some recent security feature was backported in java8)
> >>
> >> Today, I was looking at Raw Public Key support (RPK) and I understand this is not supported too. Am I right ?
> >> RPK is also part of LWM2M specification and also refered in (RFC7925?Section4.3 - TLS / DTLS -Profiles for the Internet of Things) :
> >> "The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is the first entry point into public key cryptography without having to pay the price of certificates and a public key infrastructure (PKI)."
> >>
> >>   Help is welcome.
> >>
> >> Which kind of help do you need ? ?
> >>
> >> Simon
> >>
> >> Le 15/03/2024 ? 11:38, Daniel Jeli?ski a ?crit :
> >>
> >> Hi Simon, welcome to security-dev!
> >>
> >> You got the situation of DTLS right:
> >> - PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
> >> - connection identifier is not implemented, and not on the to-do list yet;
> >> - AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
> >> understand correctly, this one should be relatively easier to
> >> implement, using the implementation of the ChaCha20 cipher as an
> >> example (see JDK-8140466, JDK-8204192).
> >>
> >> It makes perfect sense to add these features to the OpenJDK. They were
> >> never high enough on the priority list to get implemented. Help is
> >> welcome.
> >>
> >> Cheers,
> >> Daniel
> >>
> >>
> >> czw., 14 mar 2024 o 17:31 Simon Bernard <contact at simonbernard.eu> napisa?(a):
> >>
> >> Hi all,
> >>
> >> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
> >>
> >> LWM2M is mainly based on coap and coap+tcp protocol.
> >> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
> >>
> >> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
> >>
> >> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
> >>
> >> My understanding, DTLS 1.2 was added but there is still no support of :
> >>
> >> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925?Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
> >> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
> >> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
> >>
> >> If I missed something and one of those feature is already available let me know.
> >>
> >> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
> >>
> >> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
> >> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
> >> There is also possibility to bind native library but this is not so easy and also have drawback.
> >> All that solution sounds not so good...
> >>
> >> So do you think it could make sense to add this kind of feature in OpenJDK ?
> >> Or Maybe there is already plan to add it ?
> >>
> >> (I hope this is the right place for this kind of question)
> >>
> >> Thx,
> >>
> >> Simon
> >>


From ssahoo at openjdk.org  Wed Mar 20 09:28:21 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 20 Mar 2024 09:28:21 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v4]
In-Reply-To: <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
Message-ID: <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>

On Wed, 20 Mar 2024 08:26:58 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> Thanks for adding the test.
>> 
>> My main concern with using changeWriteCiphers here is that it sends the wrong message to the future readers of this code. It suggests that we want to actually change the cipher, and sending CCS is just a side effect. Note that all other uses of changeWriteCiphers actually change the write ciphers. If you don't want to use the other method, at least add a comment explaining why you're using it here.
>
> Thanks for the review, in the comments I mentioned that,  this call sends a dummy change_cipher_spec (CCS) record. I hope, It explains why we are calling it here.

Will it produce 2 ChangeCipherSpec record. One after HRR and other after SH?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531741964


From djelinski at openjdk.org  Wed Mar 20 09:31:20 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Mar 2024 09:31:20 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v4]
In-Reply-To: <v_4XgQ7rwtRGzKCNlMnsXLOFiP58q9fJ1WqOFY3lDes=.05d930e9-7ec7-408f-9ae2-95ba7289f45b@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <v_4XgQ7rwtRGzKCNlMnsXLOFiP58q9fJ1WqOFY3lDes=.05d930e9-7ec7-408f-9ae2-95ba7289f45b@github.com>
Message-ID: <ZMnXLmrhCB4caK1JyPZHX0jOde_0R5dGhQWDZGFp2fU=.a1bda514-5525-4552-a6dc-b688ddff6c34@github.com>

On Wed, 20 Mar 2024 08:48:34 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18372#pullrequestreview-1948344082


From pkoppula at openjdk.org  Wed Mar 20 09:36:19 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 09:36:19 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v4]
In-Reply-To: <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
 <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
Message-ID: <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>

On Wed, 20 Mar 2024 09:25:35 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Thanks for the review, in the comments I mentioned that,  this call sends a dummy change_cipher_spec (CCS) record. I hope, It explains why we are calling it here.
>
> Will it produce 2 ChangeCipherSpec record. One after HRR and other after SH?

Yes, the server produces 2 CCS records in the case of HRR. According to RFC:

"Either side can send change_cipher_spec at any time during the handshake, as they must be ignored by the peer, but if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this
appendix."

https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531754373


From pkoppula at openjdk.org  Wed Mar 20 09:55:34 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 09:55:34 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
Message-ID: <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8326643

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18372/files
  - new: https://git.openjdk.org/jdk/pull/18372/files/a5232303..61fef264

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/18372


From ssahoo at openjdk.org  Wed Mar 20 09:55:34 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 20 Mar 2024 09:55:34 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
 <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
 <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>
Message-ID: <CjviYtXsnkvlZJh2XNSvBx-YxEiZxrZUT07EtW9pfHo=.608e3d93-a056-4251-a458-19b9a6c8ff72@github.com>

On Wed, 20 Mar 2024 09:33:56 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> Will it produce 2 ChangeCipherSpec record. One after HRR and other after SH?
>
> Yes, the server produces 2 CCS records in the case of HRR. According to RFC:
> 
> "Either side can send change_cipher_spec at any time during the handshake, as they must be ignored by the peer, but if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this
> appendix."
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

I am not an expert in this field and expressing one of my thought here and my assumption could be wrong too.
Shouldn't it check "SSLConfiguration.useCompatibilityMode" for any change applicable to solve middlebox issue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531783071


From pkoppula at openjdk.org  Wed Mar 20 10:02:23 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 20 Mar 2024 10:02:23 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <CjviYtXsnkvlZJh2XNSvBx-YxEiZxrZUT07EtW9pfHo=.608e3d93-a056-4251-a458-19b9a6c8ff72@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
 <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
 <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>
 <CjviYtXsnkvlZJh2XNSvBx-YxEiZxrZUT07
 EtW9pfHo=.608e3d93-a056-4251-a458-19b9a6c8ff72@github.com>
Message-ID: <FhzuKM1P5xFhj1oPpovjxYZYZTZdbziGobJ9TAunoBM=.0113fb3c-4eba-42f2-a384-17cea6789e7f@github.com>

On Wed, 20 Mar 2024 09:52:40 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Yes, the server produces 2 CCS records in the case of HRR. According to RFC:
>> 
>> "Either side can send change_cipher_spec at any time during the handshake, as they must be ignored by the peer, but if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this
>> appendix."
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> I am not an expert in this field and expressing one of my thought here and my assumption could be wrong too.
> Shouldn't it check "SSLConfiguration.useCompatibilityMode" or similar for any change applicable to solve middlebox compatibility issue?

(clientHello.sessionId.length() != 0) condition checks for same

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531793243


From ssahoo at openjdk.org  Wed Mar 20 10:07:22 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 20 Mar 2024 10:07:22 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <FhzuKM1P5xFhj1oPpovjxYZYZTZdbziGobJ9TAunoBM=.0113fb3c-4eba-42f2-a384-17cea6789e7f@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
 <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
 <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>
 <CjviYtXsnkvlZJh2XNSvBx-YxEiZxrZUT07
 EtW9pfHo=.608e3d93-a056-4251-a458-19b9a6c8ff72@github.com>
 <FhzuKM1P5xFhj1oPpovjxYZYZTZdbziGobJ9TAunoBM=.0113fb3c-4eba-42f2-a384-17cea6789e7f@github.com>
Message-ID: <SP0ySng5zS416yzSuhtWHNk44nbvClombJypFkBWSf8=.baf0e64e-590d-462c-9529-d87b784322aa@github.com>

On Wed, 20 Mar 2024 09:59:14 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> I am not an expert in this field and expressing one of my thought here and my assumption could be wrong too.
>> Shouldn't it check "SSLConfiguration.useCompatibilityMode" or similar for any change applicable to solve middlebox compatibility issue?
>
> (clientHello.sessionId.length() != 0) condition checks for same

Got it. Thanks.. CH legacy_session_id uses this check for non-empty sessionId.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531800010


From egahlin at openjdk.org  Wed Mar 20 10:27:22 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 20 Mar 2024 10:27:22 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <E9ekmv_5nb6r5rq1GBtSGAtKe8odMuOy153p42a3kzQ=.20d60bba-892c-4566-8323-8a25e10891d8@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

Speaking for JFR, we should probably just create a normal file, possibly with a filename to indicate subtest and iteration. That said, test changes for JFR looks fine, and fixing the filename is outside the scope of this bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2009218768


From ssahoo at openjdk.org  Wed Mar 20 10:55:21 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 20 Mar 2024 10:55:21 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
Message-ID: <PUKYcdn2ZawOUyE862SrwlVVpByPrELP2nGo0janY0w=.f72b13c1-cdbe-455c-90c6-2a80de86f222@github.com>

On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 98:

> 96: 
> 97:             // client consumes ServerHello/HelloRetryRequest
> 98:             clientResult = clientEngine.unwrap(sTOc, clientIn);

May be it would be nice to ensure it really received a HRR record when isHRRTest=true by checking the Handshake record attribute content Random=?cf21ad74e59a6111be1d8c021e65b891c2a211167abb8c5e079e09e2c8a8339c? which is SHA-256("HelloRetryRequest")

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 112:

> 110:             if (isTlsMessage(sTOc, TLS_RECTYPE_CCS)) {
> 111:                 System.out.println("=========== CCS found ===========");
> 112:             }

"else" alignment issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531860384
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531847062


From coffeys at openjdk.org  Wed Mar 20 11:58:23 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 20 Mar 2024 11:58:23 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
Message-ID: <PCW2COJDpKqAILvKVmVKTSrz2jId2eqf236KzHNyrEo=.7bdd4666-be47-40aa-a2d2-12eff61c14dd@github.com>

On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 797:

> 795:             shc.handshakeOutput.flush();
> 796: 
> 797:             // In the Middlebox Compatibility Mode the server sends a

maybe this reads better:
// In TLS1.3 middlebox compatibility mode the server sends a

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 801:

> 799:             // first handshake message. This may either be after
> 800:             // a ServerHello or a HelloRetryRequest.
> 801:             //(RFC 8446, Appendix D.4)

minor nit - space: ` // (RFC 8446, Appendix D.4)`

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 802:

> 800:             // a ServerHello or a HelloRetryRequest.
> 801:             //(RFC 8446, Appendix D.4)
> 802:             shc.conContext.outputRecord.changeWriteCiphers(

the JDK exposes middlebox compatibility mode via the `jdk.tls.client.useCompatibilityMode` property. Is that a factor for this fix ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531953580
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531954119
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531955972


From coffeys at openjdk.org  Wed Mar 20 12:08:19 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 20 Mar 2024 12:08:19 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <SP0ySng5zS416yzSuhtWHNk44nbvClombJypFkBWSf8=.baf0e64e-590d-462c-9529-d87b784322aa@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
 <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
 <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>
 <CjviYtXsnkvlZJh2XNSvBx-YxEiZxrZUT07
 EtW9pfHo=.608e3d93-a056-4251-a458-19b9a6c8ff72@github.com>
 <FhzuKM1P5xFhj1oPpovjxYZYZTZdbziGobJ9TAunoBM=.0113fb3c-4eba-42f2-a384-17cea6789e7f@github.com>
 <SP0ySng5zS416yzSuhtWHNk44nbvClombJypFkBWSf8=.baf0e64e-590d-462c-9529-d87b784322aa@github.com>
Message-ID: <5lg-IU6kLDgc18yNbDpqrqNHHjgkBtfxrGd-CfG11Ko=.e5df92f1-7de7-4a8d-8b63-b65dc6851201@github.com>

On Wed, 20 Mar 2024 10:03:22 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> (clientHello.sessionId.length() != 0) condition checks for same
>
> Got it. Thanks.. CH legacy_session_id uses this check for non-empty sessionId.

just see this comment regards `useCompatibilityMode` - I'd a similar concern. shouldn't useCompatibilityMode be checked no matter what value we get for `clientHello.sessionId.length() `?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531968258


From djelinski at openjdk.org  Wed Mar 20 12:33:20 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Mar 2024 12:33:20 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <5lg-IU6kLDgc18yNbDpqrqNHHjgkBtfxrGd-CfG11Ko=.e5df92f1-7de7-4a8d-8b63-b65dc6851201@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
 <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
 <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>
 <CjviYtXsnkvlZJh2XNSvBx-YxEiZxrZUT07
 EtW9pfHo=.608e3d93-a056-4251-a458-19b9a6c8ff72@github.com>
 <FhzuKM1P5xFhj1oPpovjxYZYZTZdbziGobJ9TAunoBM=.0113fb3c-4eba-42f2-a384-17cea6789e7f@github.com>
 <SP0ySng5zS416yzSuhtWHNk44nbvClombJypFkBWSf8=.baf0e64e-590d-462c-9529-d87b784322aa@github.com>
 <5lg-IU6kLDgc18yNbDpqrqNHHjgkBtfxrGd-CfG11Ko=.e5df92f1-7de7-4a8d-8b63-b65dc6851201@github.com>
Message-ID: <efgdrcW3egomUdpt8pHXiPtqLOzz3unYlXkEeW4FjqY=.e0aca9ba-0397-4b9f-b6a7-76030afa008d@github.com>

On Wed, 20 Mar 2024 12:05:47 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Got it. Thanks.. CH legacy_session_id uses this check for non-empty sessionId.
>
> just see this comment regards `useCompatibilityMode` - I'd a similar concern. shouldn't useCompatibilityMode be checked no matter what value we get for `clientHello.sessionId.length() `?

`useCompatibilityMode` is a client-side setting. See [the spec](https://www.rfc-editor.org/rfc/rfc8446#page-141):
> if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this appendix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531998441


From coffeys at openjdk.org  Wed Mar 20 12:47:20 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 20 Mar 2024 12:47:20 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <efgdrcW3egomUdpt8pHXiPtqLOzz3unYlXkEeW4FjqY=.e0aca9ba-0397-4b9f-b6a7-76030afa008d@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
 <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
 <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>
 <CjviYtXsnkvlZJh2XNSvBx-YxEiZxrZUT07
 EtW9pfHo=.608e3d93-a056-4251-a458-19b9a6c8ff72@github.com>
 <FhzuKM1P5xFhj1oPpovjxYZYZTZdbziGobJ9TAunoBM=.0113fb3c-4eba-42f2-a384-17cea6789e7f@github.com>
 <SP0ySng5zS416yzSuhtWHNk44nbvClombJypFkBWSf8=.baf0e64e-590d-462c-9529-d87b784322aa@github.com>
 <5lg-IU6kLDgc18yNbDpqrqNHHjgkBtfxrGd-CfG11Ko=.e5df92f1-7de7-4a8d-8b63-b65dc6851201@github.com>
 <efgdrcW3egomUdpt8pHXiPtqLOzz3unYlXkEeW4FjqY=.e0aca9ba-0397-4b9f-b6a7-76030afa008d@github.com>
Message-ID: <4_WY5AmznrskZQIv2hqC-oq8MPn6oIci7E41Ao7Egsg=.21e481d0-3ad8-4aab-ba4d-195dcd7a12de@github.com>

On Wed, 20 Mar 2024 12:31:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> just see this comment regards `useCompatibilityMode` - I'd a similar concern. shouldn't useCompatibilityMode be checked no matter what value we get for `clientHello.sessionId.length() `?
>
> `useCompatibilityMode` is a client-side setting. See [the spec](https://www.rfc-editor.org/rfc/rfc8446#page-141):
>> if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this appendix.

thanks - I'd missed that this is used on client side only

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1532015664


From jjiang at openjdk.org  Wed Mar 20 13:09:22 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 20 Mar 2024 13:09:22 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
Message-ID: <6e8eoZBX71KpxQaSdesTMPZTOIGfxtB7ezlrfTGab2I=.e83deabe-9130-4b88-a5a5-f395a06176e3@github.com>

On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 39:

> 37: import javax.net.ssl.SSLParameters;
> 38: 
> 39: 

You may want to remove the redundant blank lines.

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 61:

> 59:     }
> 60: 
> 61:     public static void main(String args[]) throws Exception{

I suppose Java generally uses `String[] args`.

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 62:

> 60: 
> 61:     public static void main(String args[]) throws Exception{
> 62:         if(args.length > 0 && args[0].compareTo("isHRRTest") == 0){

new EngineOutOfSeqCCS().runDemo(args.length > 0 && args[0].equals("isHRRTest"));

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 263:

> 261:      */
> 262:     private static void dumpByteBuffer(String header, ByteBuffer bBuf) {
> 263:         if (dumpBufs == false) {

if (!dumpBufs)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531853750
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531864040
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531856780
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1531862260


From weijun at openjdk.org  Wed Mar 20 14:45:50 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 14:45:50 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

  more allow and years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/dfa22af0..1e6a7982

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=06-07

  Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472


From weijun at openjdk.org  Wed Mar 20 15:02:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 15:02:25 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
Message-ID: <Lj2dIOon8EcxXTrhY7aevB-F-M6xQvnHHjezGoRkfBU=.c403d499-21ea-4256-a3bd-21f2d3f296f4@github.com>

On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more allow and years

There is no source code change to `java.management` anymore inside this PR. They will be resolved with new bugs at [JDK-8327618](https://bugs.openjdk.org/browse/JDK-8327618) and [JDK-8328263](https://bugs.openjdk.org/browse/JDK-8328263). There are test changes in these areas in this PR to force them running with SM allowed. Ideally, these changes can be reverted when the 2 new bugs are resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/17472#issuecomment-2009779837


From jjiang at openjdk.org  Wed Mar 20 16:45:27 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 20 Mar 2024 16:45:27 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
Message-ID: <AuEXGoBn-7DfCntK2TiHr7Uz7K-7hdS8fF6p3ZAIK3o=.e08c38f0-70c0-400d-a222-571ccf708fad@github.com>

On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 71:

> 69:     private void runDemo(boolean isHRRTest) throws Exception {
> 70: 
> 71:             if(isHRRTest){

need a space between `if` and `(`.

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 113:

> 111:                 System.out.println("=========== CCS found ===========");
> 112:             }
> 113:             else{

need a space between `else` and `{`

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 192:

> 190:                                     "Test for Handshake requires only HS type");
> 191:                             } else {
> 192:                                 // Go into the first handhshake message in the

typo: handhshake -> handshake

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 253:

> 251:     }
> 252: 
> 253:     private static void log(String str) {

I suggest method `log` accepts `String...` instead of `String`.
This method can concatenate the strings, then its callers don't need to use so many `+` to concatenate the log.

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 280:

> 278:             log("===== " + header + " (" + tlsRecType(type) + " / " +
> 279:                 ver_major + "." + ver_minor + " / " +
> 280:                 bufLen + " bytes) =====");

Do you want to print `recLen` or `bufLen`? `recLen` is not used yet.

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 284:

> 282:             for (int i = 0; i < bufLen; i++) {
> 283:                 if (i != 0 && i % 16 == 0) {
> 284:                     System.out.print("\n");

Just `System.out.println()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1532439209
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1532437657
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1532258153
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1532420679
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1532357089
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1532361801


From ssahoo at openjdk.org  Wed Mar 20 18:58:24 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 20 Mar 2024 18:58:24 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
Message-ID: <WO-tzHxL0NIXYg1OjvBBsK1KEt4wvnjSHuDhvpz2lpY=.b87e4aaa-c242-4dfa-a8ea-c9bbb5a81c27@github.com>

On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

Can you please add a new Test to have a TLSv1.3 complete connection by setting  jdk.tls.client.useCompatibilityMode=true|false.
You may ignore if such Test exist and point that Test name.

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

PR Comment: https://git.openjdk.org/jdk/pull/18372#issuecomment-2010371047


From weijun at openjdk.org  Wed Mar 20 19:48:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 19:48:24 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation [v3]
In-Reply-To: <Hh1v82SxSC3ARrAL4QZJ53IB8zJRPkwX0WCrZ2kOWDU=.284d1668-3047-41ab-8fe9-a458da5c1830@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <Hh1v82SxSC3ARrAL4QZJ53IB8zJRPkwX0WCrZ2kOWDU=.284d1668-3047-41ab-8fe9-a458da5c1830@github.com>
Message-ID: <in786IV2u7vFd4wZOyR5MRAfQT1lEQWOxLngANB6J50=.b020d31e-ffef-445d-9c33-e024beaa3d33@github.com>

On Tue, 19 Mar 2024 15:23:39 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> rebarbora-mckvak has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8313367: signHash finds a key in the local machine store
>  - 8313367: Local Computer store is opened with max. allowed permissions

src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 806:

> 804:             {
> 805:                 // If the key is in a local machine store, we need to try again with CRYPT_MACHINE flag.
> 806:                 // See https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/cryptacquirecontext-troubleshooting

Since you said "if the key is in a local machine store", do you need to check if this is true before retrying with the `CRYPT_MACHINE_KEYSET` flag?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16687#discussion_r1532753649


From shade at openjdk.org  Wed Mar 20 20:02:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 20 Mar 2024 20:02:31 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests
Message-ID: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>

See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change.

Additional testing:
 - [x] `jdk_security` passes (includes new test config)

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/18408/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18408&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328638
  Stats: 36 lines in 2 files changed: 32 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18408/head:pull/18408

PR: https://git.openjdk.org/jdk/pull/18408


From mullan at openjdk.org  Wed Mar 20 20:45:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 20 Mar 2024 20:45:21 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
Message-ID: <6q9lWdNP10bPYE7_UAGZmKwOGgA4UqHwcZmh4jTsjRI=.7ebc2d0d-a7c3-4f89-948e-bdacaec5f355@github.com>

On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more allow and years

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17472#pullrequestreview-1950109209


From abakhtin at openjdk.org  Wed Mar 20 21:08:39 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 20 Mar 2024 21:08:39 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v8]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <Ao0YWfCDJTeSRsgcxrqwwQiERJM1Fmu5Dvq-OnoF6rM=.9191b66d-be5a-46a3-af7c-faac310aff56@github.com>

> Please review the proposed fix.
> 
> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store only.

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

  Add HttpsURLConnectionTest test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/24ca1206..507a636a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=06-07

  Stats: 49 lines in 1 file changed: 49 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16722/head:pull/16722

PR: https://git.openjdk.org/jdk/pull/16722


From abakhtin at openjdk.org  Wed Mar 20 21:08:39 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 20 Mar 2024 21:08:39 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <N6J_sqOUti_YHT281lP7aWi0GiVgXDCSHWSXyIRwfeY=.129bc187-3069-4cb8-8a5f-a64350114a0b@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <N6J_sqOUti_YHT281lP7aWi0GiVgXDCSHWSXyIRwfeY=.129bc187-3069-4cb8-8a5f-a64350114a0b@github.com>
Message-ID: <bedmgFkhcXthNl8xypBHnclf3iQirxaDk3v3bhEHnaA=.eea75f7d-e031-4120-8dde-2c45d0ffb822@github.com>

On Tue, 19 Mar 2024 14:01:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Load root certificates from SystemRootCertificates.keychain
>
> Is it practical to add a test as described in the bug?:
> 
> `java -Djavax.net.ssl.trustStoreType=KeychainStore-ROOT HttpsURLConnectionTest https://github.com/`
> 
> This could be added to the `test/jdk/security/infra` test directory since it depends on an external server.

Hi @seanjmullan
Thank you for review
I've added the test

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-2010636796


From weijun at openjdk.org  Wed Mar 20 21:28:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 21:28:29 GMT
Subject: Integrated: 8296244: Alternate implementation of user-based
 authorization Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security
 Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <sVQNg8PJbPuUovgGQYsvAzGqhH0l7cSKf6bJcrEuN60=.67048ca0-828e-49ce-9deb-d06b727ecc60@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

This pull request has now been integrated.

Changeset: d32746ef
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d32746ef4a0ce6fec558274244321991be141698
Stats:     622 lines in 17 files changed: 477 ins; 27 del; 118 mod

8296244: Alternate implementation of user-based authorization Subject APIs that doesn?t depend on Security Manager APIs

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/17472


From abakhtin at openjdk.org  Wed Mar 20 22:53:40 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 20 Mar 2024 22:53:40 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v9]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <B0HtjT5gMCSUQGTjCj52YjHVFeDAF77Sov6km-ALh2k=.eda0c1b1-261e-4516-a2fe-3591a349b808@github.com>

> Please review the proposed fix.
> 
> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store only.

Alexey Bakhtin 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 one new commit since the last revision:

  Add HttpsURLConnectionTest test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/507a636a..e2237c72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=07-08

  Stats: 14 lines in 1 file changed: 3 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16722/head:pull/16722

PR: https://git.openjdk.org/jdk/pull/16722


From pkoppula at openjdk.org  Thu Mar 21 01:30:38 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 21 Mar 2024 01:30:38 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v6]
In-Reply-To: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
Message-ID: <jmgqJ5k4m7nS0aK6wNgdKbiwCUtbkI-C-mNhNUUBYgw=.cfe5fa1c-036f-4ac3-bf6f-43e308c23ea8@github.com>

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8326643

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18372/files
  - new: https://git.openjdk.org/jdk/pull/18372/files/61fef264..02bb8ddf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/18372


From pkoppula at openjdk.org  Thu Mar 21 01:33:20 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 21 Mar 2024 01:33:20 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <PCW2COJDpKqAILvKVmVKTSrz2jId2eqf236KzHNyrEo=.7bdd4666-be47-40aa-a2d2-12eff61c14dd@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
 <PCW2COJDpKqAILvKVmVKTSrz2jId2eqf236KzHNyrEo=.7bdd4666-be47-40aa-a2d2-12eff61c14dd@github.com>
Message-ID: <uUhq3p2ri1K7ZB8qEOLLWg0Icm3KoJTv6vMRSCONlGM=.4aea66eb-3277-4ccb-b8b9-0e153efcb318@github.com>

On Wed, 20 Mar 2024 11:55:36 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8326643
>
> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 802:
> 
>> 800:             // a ServerHello or a HelloRetryRequest.
>> 801:             //(RFC 8446, Appendix D.4)
>> 802:             shc.conContext.outputRecord.changeWriteCiphers(
> 
> the JDK exposes middlebox compatibility mode via the `jdk.tls.client.useCompatibilityMode` property. Is that a factor for this fix ?

No, in that case, clientHello.sessionId.length() will be zero, and it won't send CCS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533128211


From pkoppula at openjdk.org  Thu Mar 21 02:03:39 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 21 Mar 2024 02:03:39 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v7]
In-Reply-To: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
Message-ID: <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8326643

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18372/files
  - new: https://git.openjdk.org/jdk/pull/18372/files/02bb8ddf..8507c444

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18372&range=05-06

  Stats: 17 lines in 1 file changed: 0 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18372.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18372/head:pull/18372

PR: https://git.openjdk.org/jdk/pull/18372


From pkoppula at openjdk.org  Thu Mar 21 02:07:21 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 21 Mar 2024 02:07:21 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <AuEXGoBn-7DfCntK2TiHr7Uz7K-7hdS8fF6p3ZAIK3o=.e08c38f0-70c0-400d-a222-571ccf708fad@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
 <AuEXGoBn-7DfCntK2TiHr7Uz7K-7hdS8fF6p3ZAIK3o=.e08c38f0-70c0-400d-a222-571ccf708fad@github.com>
Message-ID: <fqTPeQYu5WjFjCyqm-AO_eZV3vhZi-Ib0hBEwgLNKTo=.5a5b5988-302b-4bb1-aece-fe0f6f81d91d@github.com>

On Wed, 20 Mar 2024 15:56:22 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8326643
>
> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 280:
> 
>> 278:             log("===== " + header + " (" + tlsRecType(type) + " / " +
>> 279:                 ver_major + "." + ver_minor + " / " +
>> 280:                 bufLen + " bytes) =====");
> 
> Do you want to print `recLen` or `bufLen`? `recLen` is not used yet.

Its bufLen

> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 284:
> 
>> 282:             for (int i = 0; i < bufLen; i++) {
>> 283:                 if (i != 0 && i % 16 == 0) {
>> 284:                     System.out.print("\n");
> 
> Just `System.out.println()`?

For readability, Intentionally added "\n"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533147793
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533148397


From pkoppula at openjdk.org  Thu Mar 21 02:13:24 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 21 Mar 2024 02:13:24 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <PUKYcdn2ZawOUyE862SrwlVVpByPrELP2nGo0janY0w=.f72b13c1-cdbe-455c-90c6-2a80de86f222@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
 <PUKYcdn2ZawOUyE862SrwlVVpByPrELP2nGo0janY0w=.f72b13c1-cdbe-455c-90c6-2a80de86f222@github.com>
Message-ID: <8c2XcIuXYc7u_jI_Y-Am4ltUJxMvMyf28Qp_GW5LGCc=.ceb4c650-54fc-4184-8498-c93a2cf8fc83@github.com>

On Wed, 20 Mar 2024 10:49:55 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8326643
>
> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 98:
> 
>> 96: 
>> 97:             // client consumes ServerHello/HelloRetryRequest
>> 98:             clientResult = clientEngine.unwrap(sTOc, clientIn);
> 
> May be it would be nice to ensure it really received a HRR record when isHRRTest=true by checking the Handshake record attribute content Random=?cf21ad74e59a6111be1d8c021e65b891c2a211167abb8c5e079e09e2c8a8339c? which is SHA-256("HelloRetryRequest")

Great suggestion. According to the RFC, in middlebox compatibility mode, the Server should send CCS for all the first handshake messages. Currently, those include HRR and SH. I don't think it's wise to validate all the first handshake messages from the Server in this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533153847


From pkoppula at openjdk.org  Thu Mar 21 02:26:21 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 21 Mar 2024 02:26:21 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <AuEXGoBn-7DfCntK2TiHr7Uz7K-7hdS8fF6p3ZAIK3o=.e08c38f0-70c0-400d-a222-571ccf708fad@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
 <AuEXGoBn-7DfCntK2TiHr7Uz7K-7hdS8fF6p3ZAIK3o=.e08c38f0-70c0-400d-a222-571ccf708fad@github.com>
Message-ID: <pAucqU2FL8977mhCG28Ib4nTzCoTdRdlHQbO1Kke2sA=.9ec855f4-a451-444e-baae-94dfc8b79651@github.com>

On Wed, 20 Mar 2024 16:32:30 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8326643
>
> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 253:
> 
>> 251:     }
>> 252: 
>> 253:     private static void log(String str) {
> 
> I suggest method `log` accepts `String...` instead of `String`.
> This method can concatenate the strings, then its callers don't need to use so many `+` to concatenate the log.

We have multiple options to pass String ('+')/ String[]/ String../.join()/StringBuilder/.. I thought using '+'is not a bad idea

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533168431


From jjiang at openjdk.org  Thu Mar 21 02:59:20 2024
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 21 Mar 2024 02:59:20 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <pAucqU2FL8977mhCG28Ib4nTzCoTdRdlHQbO1Kke2sA=.9ec855f4-a451-444e-baae-94dfc8b79651@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
 <AuEXGoBn-7DfCntK2TiHr7Uz7K-7hdS8fF6p3ZAIK3o=.e08c38f0-70c0-400d-a222-571ccf708fad@github.com>
 <pAucqU2FL8977mhCG28Ib4nTzCoTdRdlHQbO1Kke2sA=.9ec855f4-a451-444e-baae-94dfc8b79651@github.com>
Message-ID: <-Ty-TlxScwFRsj01qkanoE43KsEoyf2Mek9U8R2KkwQ=.c688802c-7509-4f9a-a177-c9d256533d19@github.com>

On Thu, 21 Mar 2024 02:23:20 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 253:
>> 
>>> 251:     }
>>> 252: 
>>> 253:     private static void log(String str) {
>> 
>> I suggest method `log` accepts `String...` instead of `String`.
>> This method can concatenate the strings, then its callers don't need to use so many `+` to concatenate the log.
>
> We have multiple options to pass String ('+')/ String[]/ String../.join()/StringBuilder/.. I thought using '+'is not a bad idea

I didn't mean `+` is bad.
Method `log` can use `+` to join the elements in a string array, then the method callers don't need to concatenate the strings, instead, they only pass the strings themselves into `log`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533186515


From jjiang at openjdk.org  Thu Mar 21 03:30:23 2024
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 21 Mar 2024 03:30:23 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v7]
In-Reply-To: <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
Message-ID: <92PuShYy6_pZqTU3mMNEjEHWlyJE4-5IOQh0DPlBeVU=.43bdafe7-8874-448c-84d4-365fc85e7993@github.com>

On Thu, 21 Mar 2024 02:03:39 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 141:

> 139:         boolean foundMsg = false;
> 140: 
> 141:         if (srcRecord.hasRemaining()) {

If `srcRecord` has no more content, the method could return immediately, then no need this big `if` block.

if (!srcRecord.hasRemaining()) {
    return false;
}

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 152:

> 150:                 // For any zero-length recParams, making sure the requested
> 151:                 // type is sufficient.
> 152:                 if (recParams.length == 0) {

I'm confused by the method `isTlsMessage`.

It looks `recParams` always empty, since line 105 doesn't pass any value to this parameter.
And `reqRecType` is only `TLS_RECTYPE_CCS`, then what's the purpose of the below switch block (line 155-196)?

test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 192:

> 190:                                 int msgType = (msgHdr >> 24) & 0x000000FF;
> 191:                                 if (msgType == recParams[0]) {
> 192:                                 foundMsg = true;

Looks 192-195 lines have indent issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533192360
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533203800
PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533193256


From ssahoo at openjdk.org  Thu Mar 21 05:21:22 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Thu, 21 Mar 2024 05:21:22 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v5]
In-Reply-To: <8c2XcIuXYc7u_jI_Y-Am4ltUJxMvMyf28Qp_GW5LGCc=.ceb4c650-54fc-4184-8498-c93a2cf8fc83@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <t3IoopFL6xPOl7wRD1TbJ5EdtOYnqKVxC00lBmaFZQU=.d2db8adf-1bdc-428e-bc13-299a1411d409@github.com>
 <PUKYcdn2ZawOUyE862SrwlVVpByPrELP2nGo0janY0w=.f72b13c1-cdbe-455c-90c6-2a80de86f222@github.com>
 <8c2XcIuXYc7u_jI_Y-Am4ltUJxMvMyf28Qp_GW5LGCc=.ceb4c650-54fc-4184-8498-c93a2cf8fc83@github.com>
Message-ID: <kh1rOxP01LGDaV1zCwoU5Rb4LDHTFrgjNFBIH8tthzM=.966b135f-55c8-469e-9490-2f8ed36a2cb0@github.com>

On Thu, 21 Mar 2024 02:10:35 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 98:
>> 
>>> 96: 
>>> 97:             // client consumes ServerHello/HelloRetryRequest
>>> 98:             clientResult = clientEngine.unwrap(sTOc, clientIn);
>> 
>> May be it would be nice to ensure it really received a HRR record when isHRRTest=true by checking the Handshake record attribute content Random=?cf21ad74e59a6111be1d8c021e65b891c2a211167abb8c5e079e09e2c8a8339c? which is SHA-256("HelloRetryRequest")
>
> Great suggestion. According to the RFC, in middlebox compatibility mode, the Server should send CCS for all the first handshake messages. Currently, those include HRR and SH. I don't think it's wise to validate all the first handshake messages from the Server in this test.

I think it would be nice to have. Here is the reason,
The Test has 2 cases. 
First, generate HRR because it set "secp384r1" as NamedGroup which makes client guess wrong and in-turn the server send HRR.
Second, generate SH because client guess of NamedGroup is correct.

What if "secp384r1" added to default NamedGroup tomorrow. In that case both Test case will be executing Second case. i.e. SH will always sent for both cases and the HRR will never sent. As the test will always pass for that change no-one will care to correct the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533260753


From djelinski at openjdk.org  Thu Mar 21 05:51:19 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Mar 2024 05:51:19 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v7]
In-Reply-To: <4_WY5AmznrskZQIv2hqC-oq8MPn6oIci7E41Ao7Egsg=.21e481d0-3ad8-4aab-ba4d-195dcd7a12de@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <SEGtqM1mIA3-pd3Tav6IMj-liAKYIenBUVq7pBS6b84=.cdc1e1ab-16ec-4ce8-9827-76956ec48935@github.com>
 <5CbSRRuUV9YMONdUduFJf2NqHZc1O8omwa4cTS2Z_1w=.99f0a231-0982-4033-b982-e0b34c858651@github.com>
 <fd0eQ_GX5Q5Ss6hiWuHYAolqjTkLXrlnG2bLu_-KmRI=.29f085e4-ad5c-47b9-9982-6ed1ca5e16ea@github.com>
 <zq8lHH8z2Ak0FWx_JjlpvVTZuZsWAdqXR_LbKkkZgm8=.9afa1e64-8b58-4599-ba81-27654baecf9d@github.com>
 <yldmbx2DYFInyChrbeUDUlFtD-6-ELrmTKC51tEkyqM=.e607c9ac-49fd-4970-b6c1-2fafaee23de9@github.com>
 <8-NnDVJxAS6Gbj235yF62i6MxWtODHhYerlk_67PmvE=.10cbebc2-19d9-44be-96e8-0c4c4ce59a79@github.com>
 <ymm7VqdFWOhTm7i_OPhlkFwX2Ht12Bu4fQJG0JKtda0=.9d4d36dd-e2c2-47ac-881e-2c5ea8ca22ab@github.com>
 <CFZVTqoBglXYPLneIGhW64NyUpuuv1vm46FzSw83p5A=.5b3dec56-f777-47c3-a013-cdded60efc64@github.com>
 <VUYw4h8co8FrkK5frFjYGhPjbJWMSsMGcyA_KfzoKjQ=.b3c84660-e1ba-4473-8519-3b345d1bd91e@github.com>
 <CjviYtXsnkvlZJh2XNSvBx-YxEiZxrZUT07
 EtW9pfHo=.608e3d93-a056-4251-a458-19b9a6c8ff72@github.com>
 <FhzuKM1P5xFhj1oPpovjxYZYZTZdbziGobJ9TAunoBM=.0113fb3c-4eba-42f2-a384-17cea6789e7f@github.com>
 <SP0ySng5zS416yzSuhtWHNk44nbvClombJypFkBWSf8=.baf0e64e-590d-462c-9529-d87b784322aa@github.com>
 <5lg-IU6kLDgc18yNbDpqrqNHHjgkBtfxrGd-CfG11Ko=.e5df92f1-7de7-4a8d-8b63-b65dc6851201@github.com>
 <efgdrcW3egomUdpt8pHXiPtqLOzz3unYlXkEeW4FjqY=.e0aca9ba-0397-4b9f-b6a7-76030afa008d@github.com>
 <4_WY5AmznrskZQIv2hqC-oq8MPn6oIci7E41Ao7Egsg=.21e481d0-3ad8-4aab-ba4d-195dcd7a12de@github.com>
Message-ID: <PFZ19kRkU64Ngv-_16kq3Z2z-KNEvOPp2QY8HqRKBv8=.20d4835e-ffc9-4b62-9c78-03ae63e0aea1@github.com>

On Wed, 20 Mar 2024 12:44:55 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> `useCompatibilityMode` is a client-side setting. See [the spec](https://www.rfc-editor.org/rfc/rfc8446#page-141):
>>> if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this appendix.
>
> thanks - I'd missed that this is used on client side only

Just for completeness, QUIC is using a non-null cipher for client/server hello, so setting a null cipher here would break it. But then, QUIC forbids middlebox compatibility mode, so this shouldn't be an issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533280143


From djelinski at openjdk.org  Thu Mar 21 06:35:19 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Mar 2024 06:35:19 GMT
Subject: RFR: 8328556: Do not extract large CKO_SECRET_KEY keys from the
 NSS Software Token
In-Reply-To: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
References: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
Message-ID: <2QWNayHK6Vkz6Y0TzITZj7bRFv96YnC28dvdOeJ4Ky0=.c03de8f8-ecfb-47fe-9cb6-4687304415c7@github.com>

On Wed, 20 Mar 2024 03:39:58 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hi,
> 
> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token". See more details in the JBS ticket [1].
> 
> No regressions observed in jdk/sun/security/pkcs11.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.org/browse/JDK-8328556

Would it be possible to add a regression test for this? I think you should be able to trigger a failure by calculating a HMAC using the same key two times.

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

PR Comment: https://git.openjdk.org/jdk/pull/18389#issuecomment-2011311294


From coffeys at openjdk.org  Thu Mar 21 07:26:21 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 21 Mar 2024 07:26:21 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v7]
In-Reply-To: <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
Message-ID: <ezSSHi8wLdkcNUV0cZ9lj5L5BW22OCryxq_tXeapjgs=.696fad50-cf65-40ac-bc46-9dbee7006f0a@github.com>

On Thu, 21 Mar 2024 02:03:39 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

LGTM. The `isTlsMessage` test method seems to be repeated across a few tests now. Any fix up here is lost on the other tests calling identical code.

In a follow on PR, it might be an idea to extract that out into a test library utility call.

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18372#pullrequestreview-1950937483


From jjiang at openjdk.org  Thu Mar 21 08:31:22 2024
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 21 Mar 2024 08:31:22 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v7]
In-Reply-To: <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
Message-ID: <1IuEKYqR7CXwYct7pQllKbN0plDZO8az8-3Ae1VMlvQ=.9ea7fdde-0ef4-4c4e-9d0f-47d65683a3c6@github.com>

On Thu, 21 Mar 2024 02:03:39 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

@coffeys 
Thanks for your clarification!

If just keep the current style, I have no more comment.

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

Marked as reviewed by jjiang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18372#pullrequestreview-1951176255


From pkumaraswamy at openjdk.org  Thu Mar 21 09:31:31 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Thu, 21 Mar 2024 09:31:31 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
Message-ID: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>

This fix intends to eliminate additional library call to C_EncryptInit or C_DecryptInit for Ciphers running through the CKM_AES_GCM.

Background: 

There are two types of CK_GCM_PARAMS struct that are used, one with IV bits and the other without it.

Initially there was issue in NSS library, due to the struct being different in header and spec version.
NSS was using version from header but Solaris and SoftHsm was using normative version from spec.
To maintain compatibility Java used to try library call with non-normative (header) version first and then upon failure retrial was made with updated GCM struct with IV bits.

Note: Trying normative (spec) version first with NSS library results in JVM crash.

Refer below for more information:
https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11gcm2.h#L36  

However NSS has fixed this to use normative/spec version since 3.52 which has spec version 2.40
Solaris and SoftHSM was already complying to the version mentioned in spec 2.40

The fix now check if spec version is 2.40 and then makes library call with appropriate structure.

Internal testing is green, further I have done internal testing manually with NSS library 3.96, 3.76, 3.51 (non-normative spec), 3.52 and 3.53
Results are attached [nss_logs.zip](https://github.com/openjdk/jdk/files/14692787/nss_logs.zip)

Our existing tests like sun/security/pkcs11/Cipher/TestKATForGCM.java already tests the functionality and I have used the same for internal testing

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

Commit messages:
 - 8261433: Better pkcs11 performance for libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit

Changes: https://git.openjdk.org/jdk/pull/18425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8261433
  Stats: 144 lines in 3 files changed: 138 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18425/head:pull/18425

PR: https://git.openjdk.org/jdk/pull/18425


From jpai at openjdk.org  Thu Mar 21 14:44:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 14:44:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57:

> 55: 
> 56:             File flagsFile = File.createTempFile("CheckOriginFlags", null);
> 57:             flagsFile.deleteOnExit();

Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary).
Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do:


File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile();

and don't need any explicit deletions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534054951


From jpai at openjdk.org  Thu Mar 21 15:05:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:05:26 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <-LZotlcsvx3EbHNNn0DO-u7HsWB302dYqZ33vFTf0UA=.9728ca78-a90f-4705-8b81-de5c61d342ca@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/java/nio/channels/unixdomain/Bind.java line 201:

> 199:                 System.out.println("Null server address: " + server.getLocalAddress());
> 200:             } finally {
> 201:                 Files.deleteIfExists(usa.getPath());

`usa` can be `null` here, if it never got assigned due to some exception in the prior lines, which can lead to a `NullPointerException` here.

test/jdk/java/nio/channels/unixdomain/Bind.java line 341:

> 339:                 assertAddress(client.getRemoteAddress(), usa, "server");
> 340:             } finally {
> 341:                 Files.deleteIfExists(usa.getPath());

Same applies here about potential NullPointerException and some other places in other files as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534092806
PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534095046


From jpai at openjdk.org  Thu Mar 21 15:09:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:09:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95:

> 93: 
> 94:         // ensure that the archive is still readable, and the date is 1979-11-30
> 95:         Path path = Utils.createTempFile("out", ".zip");

So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534105420


From mullan at openjdk.org  Thu Mar 21 15:25:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 15:25:25 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <N6J_sqOUti_YHT281lP7aWi0GiVgXDCSHWSXyIRwfeY=.129bc187-3069-4cb8-8a5f-a64350114a0b@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <N6J_sqOUti_YHT281lP7aWi0GiVgXDCSHWSXyIRwfeY=.129bc187-3069-4cb8-8a5f-a64350114a0b@github.com>
Message-ID: <VXIsKPZbHzWjNpFvkn1AvIIilVUX4GwSLx8m3RqSAvQ=.dccca709-6109-4fbb-b919-9a525850a9c8@github.com>

On Tue, 19 Mar 2024 14:01:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Load root certificates from SystemRootCertificates.keychain
>
> Is it practical to add a test as described in the bug?:
> 
> `java -Djavax.net.ssl.trustStoreType=KeychainStore-ROOT HttpsURLConnectionTest https://github.com/`
> 
> This could be added to the `test/jdk/security/infra` test directory since it depends on an external server.

> Hi @seanjmullan Thank you for review I've added the test

Thanks. @rhalade Is this an acceptable place (security/infra) to put a test that makes external network connections?

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-2012619601


From mbalao at openjdk.org  Thu Mar 21 16:27:20 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 21 Mar 2024 16:27:20 GMT
Subject: RFR: 8328556: Do not extract large CKO_SECRET_KEY keys from the
 NSS Software Token
In-Reply-To: <2QWNayHK6Vkz6Y0TzITZj7bRFv96YnC28dvdOeJ4Ky0=.c03de8f8-ecfb-47fe-9cb6-4687304415c7@github.com>
References: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
 <2QWNayHK6Vkz6Y0TzITZj7bRFv96YnC28dvdOeJ4Ky0=.c03de8f8-ecfb-47fe-9cb6-4687304415c7@github.com>
Message-ID: <wcZ0WfObGiXsrFIXP61iVIpJG6UiPFLM7ZolKhFntRs=.063f2b11-5a4f-4724-aac2-3884d095ef19@github.com>

On Thu, 21 Mar 2024 06:32:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Would it be possible to add a regression test for this? I think you should be able to trigger a failure by calculating a HMAC using the same key two times.

May be possible. To create a large secret key we can use a DH derivation + TLS pre-master generation trick as shown in the TestLargeKeys.java reproducer that I attached to JDK-8328556. Other attempts to create a large secret key may fail due to NSS checks. Then we would need to configure the NSS Software Token in FIPS mode. This is currently not supported by the PKCS11Test library, so we would need to extend it. Notice that there is currently one FIPS standalone test (FipsModeTLS12.java) but the right approach would be to do refactoring in PKCS11Test. The reason why FIPS mode is necessary is because, otherwise, the mechanism for rebuilding keys in the token would be C_CreateObject instead of C_UnwrapKey. Actually, it's not FIPS mode strictly what we need but keys with CKA_SENSITIVE = CK_TRUE. Perhaps we can modify the NSS configuration to set this attribute, but that would be a shortcut and the use case is better represented by FIPS mode. If there is interest in supporting FIPS scena
 rios, I can do this work. I didn't go this far in my proposal because this bug, in my view, is not very likely to be hit ?as far as I know, it haven't been for years since the introduction of JDK-6913047? and the fix is trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/18389#issuecomment-2012876315


From rhalade at openjdk.org  Thu Mar 21 16:27:24 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 21 Mar 2024 16:27:24 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <VXIsKPZbHzWjNpFvkn1AvIIilVUX4GwSLx8m3RqSAvQ=.dccca709-6109-4fbb-b919-9a525850a9c8@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@github.com>
 <N6J_sqOUti_YHT281lP7aWi0GiVgXDCSHWSXyIRwfeY=.129bc187-3069-4cb8-8a5f-a64350114a0b@github.com>
 <VXIsKPZbHzWjNpFvkn1AvIIilVUX4GwSLx8m3RqSAvQ=.dccca709-6109-4fbb-b919-9a525850a9c8@github.com>
Message-ID: <jamLCX5aZXgP67pH-xly0Ovx1rz27vXVYHvf3ujK2II=.37ce5688-3bdd-48f3-a0f9-a736324aeada@github.com>

On Thu, 21 Mar 2024 15:23:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > Hi @seanjmullan Thank you for review I've added the test
> 
> Thanks. @rhalade Is this an acceptable place (security/infra) to put a test that makes external network connections?

Yes, it is correct place to add this infra test. @alexeybakhtin please update https://github.com/openjdk/jdk/blob/master/test/jdk/TEST.groups#L254 definition to include this test. Update could be:

jdk_security_infra = \
    security/infra

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-2012879216


From bhuang at openjdk.org  Thu Mar 21 16:54:21 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 16:54:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
Message-ID: <AW72Q2T6TyFJRUkyTjV-eZJdV0KUGZ-YFQa_ZatithQ=.bfd1c59b-1823-4c87-aa5f-5473959f4278@github.com>

On Thu, 21 Mar 2024 14:41:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57:
> 
>> 55: 
>> 56:             File flagsFile = File.createTempFile("CheckOriginFlags", null);
>> 57:             flagsFile.deleteOnExit();
> 
> Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary).
> Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do:
> 
> 
> File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile();
> 
> and don't need any explicit deletions?

Hi Jaikiran, I think both solutions work for this bug. I personally prefer to place the files in the scratch directory for the ease of debugging. 
In addition, for this specific test, I am considering using File.createTempFile("CheckOriginaFlags", null, Path.of(".").toFile) instead of Files.createTempFile for consistency purposes, as Files.createTempFile may have more restrictive access permissions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534283105


From bhuang at openjdk.org  Thu Mar 21 16:59:20 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 16:59:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
Message-ID: <5fp1NwbiBibdMUnZA8mIj76MLVvTxdA2m_z9IM8dUEc=.28d46052-8e8d-4ede-96ac-5da5d7a568a9@github.com>

On Thu, 21 Mar 2024 15:06:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments
>
> test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95:
> 
>> 93: 
>> 94:         // ensure that the archive is still readable, and the date is 1979-11-30
>> 95:         Path path = Utils.createTempFile("out", ".zip");
> 
> So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`?

Yes, you are right. We don't need explicit deletion for these files by using this util method, Utils.createTempFile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534290137


From bhuang at openjdk.org  Thu Mar 21 17:13:46 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 17:13:46 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Fixed potential NPE issues.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/620f9259..2517f756

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=01-02

  Stats: 11 lines in 4 files changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

PR: https://git.openjdk.org/jdk/pull/18352


From mbalao at openjdk.org  Thu Mar 21 17:17:41 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 21 Mar 2024 17:17:41 GMT
Subject: RFR: 8328556: Do not extract large CKO_SECRET_KEY keys from the
 NSS Software Token [v2]
In-Reply-To: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
References: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
Message-ID: <4ZfgMip66djQg-Bbo3UQzL8Bca2XUY9WX81g_UrDj5o=.e000a362-ba7d-4336-aa71-5daea9293420@github.com>

> Hi,
> 
> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token". See more details in the JBS ticket [1].
> 
> No regressions observed in jdk/sun/security/pkcs11.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.org/browse/JDK-8328556

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  Test TestLargeSecretKeys added.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18389/files
  - new: https://git.openjdk.org/jdk/pull/18389/files/b3c7bfa0..6d93a82c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18389&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18389&range=00-01

  Stats: 72 lines in 1 file changed: 72 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18389.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18389/head:pull/18389

PR: https://git.openjdk.org/jdk/pull/18389


From mbalao at openjdk.org  Thu Mar 21 17:20:21 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 21 Mar 2024 17:20:21 GMT
Subject: RFR: 8328556: Do not extract large CKO_SECRET_KEY keys from the
 NSS Software Token [v2]
In-Reply-To: <4ZfgMip66djQg-Bbo3UQzL8Bca2XUY9WX81g_UrDj5o=.e000a362-ba7d-4336-aa71-5daea9293420@github.com>
References: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
 <4ZfgMip66djQg-Bbo3UQzL8Bca2XUY9WX81g_UrDj5o=.e000a362-ba7d-4336-aa71-5daea9293420@github.com>
Message-ID: <5zmAARyomWVrdkkHu8CDjGMPrdoI3f5WjwUmO6GORmY=.0ff65036-bcd7-4e15-9039-f42e34a702e2@github.com>

On Thu, 21 Mar 2024 17:17:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hi,
>> 
>> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token". See more details in the JBS ticket [1].
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.org/browse/JDK-8328556
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test TestLargeSecretKeys added.

Update: I found that an existing PKCS11Test configuration (p11-nss-sensitive.txt) sets CKA_SENSITIVE to CK_TRUE for secret keys. Combining this with the DH large secret key derivation trick led to a viable reproducer without having to introduce a FIPS configuration.

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

PR Comment: https://git.openjdk.org/jdk/pull/18389#issuecomment-2013100964


From mbalao at openjdk.org  Thu Mar 21 17:23:44 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 21 Mar 2024 17:23:44 GMT
Subject: RFR: 8328556: Do not extract large CKO_SECRET_KEY keys from the
 NSS Software Token [v3]
In-Reply-To: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
References: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
Message-ID: <iBrhkiK0DVrj2AMDdu2XFYk0v2uVRorYXsRNIHxMqqA=.859616e2-d765-40bc-ac12-7039d636989b@github.com>

> Hi,
> 
> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token". See more details in the JBS ticket [1].
> 
> No regressions observed in jdk/sun/security/pkcs11.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.org/browse/JDK-8328556

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  Type in a TestLargeSecretKeys test comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18389/files
  - new: https://git.openjdk.org/jdk/pull/18389/files/6d93a82c..c319b214

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18389&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18389&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/18389


From mullan at openjdk.org  Thu Mar 21 17:46:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 17:46:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <H3UoDTth09CIdHaBVX8occDp0THRZY-SI9UrWHnTN0c=.c3e8aaf5-0e94-4599-9862-5a8cdc09f3be@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

The bug should have a `noreg-self` label.

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2013158192


From abakhtin at openjdk.org  Thu Mar 21 18:34:38 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 21 Mar 2024 18:34:38 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore
 [v10]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <azDado7_ptzYltiBaNan8YzNexwh0-d3CQS1cb0VBb4=.15d78fbf-2b9b-4612-93ed-43e3aaca7ad9@github.com>

> Please review the proposed fix.
> 
> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store only.

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

  Add HttpsURLConnectionTest into jdk_security_infra test group

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/e2237c72..b92e21b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=08-09

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

PR: https://git.openjdk.org/jdk/pull/16722


From mullan at openjdk.org  Thu Mar 21 18:42:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 18:42:25 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore
 [v10]
In-Reply-To: <azDado7_ptzYltiBaNan8YzNexwh0-d3CQS1cb0VBb4=.15d78fbf-2b9b-4612-93ed-43e3aaca7ad9@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <azDado7_ptzYltiBaNan8YzNexwh0-d3CQS1cb0VBb4=.15d78fbf-2b9b-4612-93ed-43e3aaca7ad9@github.com>
Message-ID: <15o1TcDpslpJeeQ3jbWKZqaIORpGz7H6LWSYwUoqxGk=.505e7dd7-f6dc-43ef-9722-34328828f3a2@github.com>

On Thu, 21 Mar 2024 18:34:38 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add HttpsURLConnectionTest into jdk_security_infra test group

I only reviewed HttpsURLConnectionTest.java and had one minor comment (typo).

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16722#pullrequestreview-1952557572


From mullan at openjdk.org  Thu Mar 21 18:42:27 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 18:42:27 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v9]
In-Reply-To: <B0HtjT5gMCSUQGTjCj52YjHVFeDAF77Sov6km-ALh2k=.eda0c1b1-261e-4516-a2fe-3591a349b808@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <B0HtjT5gMCSUQGTjCj52YjHVFeDAF77Sov6km-ALh2k=.eda0c1b1-261e-4516-a2fe-3591a349b808@github.com>
Message-ID: <VKhsRb5xoGKoWf1CrhEISfIcyvl6hWygD824IJTfJOM=.db086d9e-4f9c-4de3-a78b-c584c369feff@github.com>

On Wed, 20 Mar 2024 22:53:40 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the proposed fix.
>> 
>> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store only.
>
> Alexey Bakhtin 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 one new commit since the last revision:
> 
>   Add HttpsURLConnectionTest test

test/jdk/security/infra/javax/net/ssl/HttpsURLConnectionTest.java line 27:

> 25:  * @test
> 26:  * @bug 8320362
> 27:  * @summary Verifies successfull connection to external server with

Typo: successful

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1534129404


From coffeys at openjdk.org  Thu Mar 21 19:39:36 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 21 Mar 2024 19:39:36 GMT
Subject: RFR: 8051959: Add decorator options for java.security.debug output
 [v3]
In-Reply-To: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
Message-ID: <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>

> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
> 
> examples:
> format without patch :
> 
> 
> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info included:
> 
> 
> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info and timestamp:
> 
> 
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
> 
> 
> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
> 
> current proposal is to keep the thread and timestamp information off (make it opt in)
> 
> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
> 
> e.g 
> 
> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
> 
> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - merge in krb5 debug changes and implement extra functionality. enhance krb5 test
 - krb5 debug merge
 - Merge branch 'master' into 8051959-tracing
 - Move help section higher. Add code comment
 - more test coverage
 - unused variable
 - use default hex output
 - static dateTimeFormatInitialized
 - Merge branch 'master' into 8051959-tracing
 - Holder class idiom
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8ee39e01...5628bc22

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18084/files
  - new: https://git.openjdk.org/jdk/pull/18084/files/d89308b5..5628bc22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=01-02

  Stats: 389833 lines in 1609 files changed: 20981 ins; 83675 del; 285177 mod
  Patch: https://git.openjdk.org/jdk/pull/18084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18084/head:pull/18084

PR: https://git.openjdk.org/jdk/pull/18084


From coffeys at openjdk.org  Thu Mar 21 19:44:23 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 21 Mar 2024 19:44:23 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v3]
In-Reply-To: <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>
Message-ID: <FtOM2bn9yMiEobXUzwjj6lJPsaqJE8_N4M455wKoO94=.c07623a1-6e15-40eb-a9dd-97fff39eceb1@github.com>

On Thu, 21 Mar 2024 19:39:36 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - merge in krb5 debug changes and implement extra functionality. enhance krb5 test
>  - krb5 debug merge
>  - Merge branch 'master' into 8051959-tracing
>  - Move help section higher. Add code comment
>  - more test coverage
>  - unused variable
>  - use default hex output
>  - static dateTimeFormatInitialized
>  - Merge branch 'master' into 8051959-tracing
>  - Holder class idiom
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/7fb32dee...5628bc22

@wangweij 
Updated the PR to incorporate extra changes as a result JDK-8327818 
Would appreciate if you can take a look

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

PR Comment: https://git.openjdk.org/jdk/pull/18084#issuecomment-2013508350


From mullan at openjdk.org  Thu Mar 21 20:20:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 20:20:20 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests
In-Reply-To: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
Message-ID: <5AypAzH7vFmyIv08P3S6ZMyi7H1oQTMOAi-Qdz5enPI=.6580750d-5336-412c-b2e4-8bd7ca19d8de@github.com>

On Wed, 20 Mar 2024 19:48:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
> 
> Additional testing:
>  - [x] `jdk_security` passes out of the box (includes new test config)
>  - [x]  `jdk_security` passes with flag override
>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override

Thanks for doing this - I think it is a fine idea to have a fallback option to use GET. It does need a CSR though since you are introducing a new system property.

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2013649890


From mullan at openjdk.org  Thu Mar 21 20:28:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 20:28:19 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests
In-Reply-To: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
Message-ID: <eXp17ImOhLfoSyhf2nccup0APPr1LTbxeDrrMkC685A=.0f768e9f-b5b3-4755-86dc-08ad2fbca73b@github.com>

On Wed, 20 Mar 2024 19:48:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
> 
> Additional testing:
>  - [x] `jdk_security` passes out of the box (includes new test config)
>  - [x]  `jdk_security` passes with flag override
>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override

Ideally, we should also modify the tests in `test/jdk/security/infra/java/security/cert/CertPathValidator/certification` to test OCSP with POST. I think it should be easy enough to add an additional line to each test like:

` * @run main/othervm/timeout=180 -Djava.security.debug=certpath -Dcom.sun.security.ocsp.useget=false ActalisCA OCSP`
 
 This means we would be testing real OCSP responders supported by CAs in the Java Root Program, and not just a test responder that we created.
 
 @rhalade would this change be ok with you?

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2013663116


From abakhtin at openjdk.org  Thu Mar 21 20:29:38 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 21 Mar 2024 20:29:38 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore
 [v11]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <lErj5q-qgdc6nMmAY45TLMT_ZCKbeTChKkYjk-0VH-0=.47f3baa0-c289-4e3e-970b-6d7711a9b5b5@github.com>

> Please review the proposed fix.
> 
> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store only.

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

  Fixed typo in HttpsURLConnectionTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/b92e21b9..0c7f061b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=09-10

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

PR: https://git.openjdk.org/jdk/pull/16722


From abakhtin at openjdk.org  Thu Mar 21 20:29:39 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 21 Mar 2024 20:29:39 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v9]
In-Reply-To: <VKhsRb5xoGKoWf1CrhEISfIcyvl6hWygD824IJTfJOM=.db086d9e-4f9c-4de3-a78b-c584c369feff@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <B0HtjT5gMCSUQGTjCj52YjHVFeDAF77Sov6km-ALh2k=.eda0c1b1-261e-4516-a2fe-3591a349b808@github.com>
 <VKhsRb5xoGKoWf1CrhEISfIcyvl6hWygD824IJTfJOM=.db086d9e-4f9c-4de3-a78b-c584c369feff@github.com>
Message-ID: <U7J_L56a1BgdJEYCIjXRxmaCYcWC7HuK1UyKV249KRs=.bc53e5b3-4504-4c8a-b005-47236c69efdd@github.com>

On Thu, 21 Mar 2024 15:20:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Alexey Bakhtin 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 one new commit since the last revision:
>> 
>>   Add HttpsURLConnectionTest test
>
> test/jdk/security/infra/javax/net/ssl/HttpsURLConnectionTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8320362
>> 27:  * @summary Verifies successfull connection to external server with
> 
> Typo: successful

Thank you. Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1534629555


From weijun at openjdk.org  Thu Mar 21 20:41:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 21 Mar 2024 20:41:25 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v3]
In-Reply-To: <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>
Message-ID: <YBhVF7k1lHkSXaqYjA28i8l5iYaq2NkSN5C8KTrkq_c=.b3ad4c0e-530f-4c85-bbbf-5c34524013fb@github.com>

On Thu, 21 Mar 2024 19:39:36 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - merge in krb5 debug changes and implement extra functionality. enhance krb5 test
>  - krb5 debug merge
>  - Merge branch 'master' into 8051959-tracing
>  - Move help section higher. Add code comment
>  - more test coverage
>  - unused variable
>  - use default hex output
>  - static dateTimeFormatInitialized
>  - Merge branch 'master' into 8051959-tracing
>  - Holder class idiom
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a33f4bde...5628bc22

src/java.base/share/classes/sun/security/util/Debug.java line 191:

> 189:         if (printDateTime && !dateTimeFormatInitialized) {
> 190:             // trigger loading of Locale service impl now to avoid
> 191:             // possible bootstrap recursive class load issue

Does this need to be manually loaded? I thought the `FormatHolder` field will be automatically loaded when it's first accessed and only once.

src/java.base/share/classes/sun/security/util/Debug.java line 206:

> 204: 
> 205:     // parse an option string to determine if extra details
> 206:     // (like thread and timestamp) should be printed

I find this method (and maybe also `configureOptions`) a little confusing. The `option` argument is the option name for `getInstance` but the property value for `of`. You can see that in this method there is completely no shared code between `ofInstance` being true or false.

src/java.base/share/classes/sun/security/util/Debug.java line 257:

> 255:      * }
> 256:      * @param prefix the debug option name
> 257:      * @param property debug setting for this option

Please add some words on the format that `property`can take.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1534645297
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1534645506
PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1534645944


From abakhtin at openjdk.org  Thu Mar 21 22:30:31 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 21 Mar 2024 22:30:31 GMT
Subject: Integrated: 8320362: Load anchor certificates from Keychain keystore
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <MJ0wd1r1d8muuEjB9QKyEvlG7THPZ2yJtxOrp-O2Lc8=.225927ee-e6f0-4de9-bdbc-539c1834309f@github.com>

On Sat, 18 Nov 2023 02:41:05 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the proposed fix.
> 
> The patch loads system root certificates from the MacOS Keychain with TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store only.

This pull request has now been integrated.

Changeset: 4210e507
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4210e507a0e65de00fab50e0584aa82cd7b3bf27
Stats:     405 lines in 6 files changed: 299 ins; 43 del; 63 mod

8320362: Load anchor certificates from Keychain keystore

Reviewed-by: weijun, mullan

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

PR: https://git.openjdk.org/jdk/pull/16722


From ascarpino at openjdk.org  Fri Mar 22 05:34:22 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 22 Mar 2024 05:34:22 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v7]
In-Reply-To: <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
Message-ID: <1anWeCNTIe6EDmD0TBftMSY8IKLvLeAFxmBo3AzHUzc=.1ded4f71-28a2-4cfd-91ab-13d65a2c5a11@github.com>

On Thu, 21 Mar 2024 02:03:39 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

The changes look good

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18372#pullrequestreview-1953977421


From pkoppula at openjdk.org  Fri Mar 22 05:42:22 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Fri, 22 Mar 2024 05:42:22 GMT
Subject: RFR: 8326643: JDK server does not send a dummy change_cipher_spec
 record after HelloRetryRequest message [v7]
In-Reply-To: <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
 <woNv4gtaGesKYhBQh8b8-Iu_sLSbDmUe62oTnnSMNoc=.12ea5777-b904-4fac-99b0-669bcc72d3d6@github.com>
Message-ID: <RJZg_Fyyf1XvdMV9AfjOoLILoAMjD00ClpDKGrd2abg=.216508c3-b824-492a-ae03-142d03e23b9c@github.com>

On Thu, 21 Mar 2024 02:03:39 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
>> 
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326643

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18372#issuecomment-2014394707


From hchao at openjdk.org  Fri Mar 22 06:56:33 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 22 Mar 2024 06:56:33 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v2]
In-Reply-To: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
Message-ID: <rRsPUlHLR3jxwyiMwBoY0W4-02zbgKNgwdRqreGhaOg=.6e97b8d2-5c5d-4c58-82f6-67de0c2d2b86@github.com>

> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
> 
> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
> 
> 1. Accept that PKIX+PKCS12 is slow.
> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
> 
> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
> 
> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   104.764 ?   3.237  ops/s
> SSLHandshak...

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Updated with John's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17956/files
  - new: https://git.openjdk.org/jdk/pull/17956/files/c3eb3be8..a45fe0e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17956&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17956&range=00-01

  Stats: 35 lines in 1 file changed: 8 ins; 19 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17956/head:pull/17956

PR: https://git.openjdk.org/jdk/pull/17956


From hchao at openjdk.org  Fri Mar 22 06:56:33 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 22 Mar 2024 06:56:33 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v2]
In-Reply-To: <yK9bcsiM--LTenRxL-VYBBFqIAPL02ghyojkeAgtpYo=.a374fab5-866f-4ae5-a9d3-26e246307ea6@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <yK9bcsiM--LTenRxL-VYBBFqIAPL02ghyojkeAgtpYo=.a374fab5-866f-4ae5-a9d3-26e246307ea6@github.com>
Message-ID: <KI1nCnHmnEHPHNC2uNSERq95qIg0npfkuqROnNpx5Ws=.90f74767-71c9-4b54-9601-03c2f1be3bb4@github.com>

On Tue, 19 Mar 2024 06:20:53 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with John's comments
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 82:
> 
>> 80:     private final Map<String,Reference<PrivateKeyEntry>> entryCacheMap;
>> 81: 
>> 82:     private boolean ksP12;
> 
> Could `ksP12` also be `final`?

Made it final.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 106:
> 
>> 104:         this.builders = builders;
>> 105:         uidCounter = new AtomicLong();
>> 106:         KeyStore keyStore = null;
> 
> It may be better to define `keyStore` in the below for-loop.

Done.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 109:
> 
>> 107:         boolean foundPKCS12 = false;
>> 108: 
>> 109:         for (int i = 0, n = builders.size(); i < n; i++) {
> 
> The index `i` just be used for retrieving the elements from the list, then it can apply enhanced for-loop.

Done.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 335:
> 
>> 333: 
>> 334:             // Convert KeyStore certificates to X509Certificates
>> 335:             X509Certificate[] newCerts = Arrays.copyOf(keyStoreCerts,
> 
> Does it have to convert `Certificate[]` to `X509Certificate[]`?
> The doc for `Arrays::equals` states
>> the two arrays are equal if they contain the same elements in the same order.
> 
> It looks this method doesn't care the types of the arrays themselves.

Removed conversion.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 339:
> 
>> 337:             return Arrays.equals(cachedCerts, newCerts);
>> 338:         } catch (Exception e) {
>> 339:             return false;
> 
> Should this exception be logged?

Done.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 356:
> 
>> 354:         }
>> 355: 
>> 356:         PrivateKeyEntry privateKeyEntry = (PrivateKeyEntry) newEntry;
> 
> Would you like to apply pattern matching for `instanceof`?
> 
> if (!(newEntry instanceof PrivateKeyEntry privateKeyEntry)) {
>     return false;
> }
> 
> PrivateKey privateKey = privateKeyEntry.getPrivateKey();

Done.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 358:
> 
>> 356:         PrivateKeyEntry privateKeyEntry = (PrivateKeyEntry) newEntry;
>> 357:         PrivateKey privateKey = privateKeyEntry.getPrivateKey();
>> 358:         Certificate[] certs = privateKeyEntry.getCertificateChain();
> 
> The method `getCertificateChain(String)` contains the below codes (line 211~213),
> 
> PrivateKeyEntry entry = getEntry(alias);
> return entry == null ? null :
>         (X509Certificate[])entry.getCertificateChain();
> 
> This method assumes `PrivateKeyEntry::getCertificateChain` should always return `X509Certificate[]`.
> 
> Then, could line 358 also cast the certificate chain to `X509Certificate[]` directly?
> If so, the following codes can be simplified.
> It may not need to check the certification type, and could not to convert the `Certificate[]` to `X509Certificate[]`.

Changed to cast the certificate chain.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 410:
> 
>> 408:             return mapEntryUpdated;
>> 409:         } catch (Exception e) {
>> 410:             return false;
> 
> Should this exception be logged?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1535125307
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1535125365
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1535125397
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1535125509
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1535125456
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1535125429
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1535125548
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1535125483


From pkoppula at openjdk.org  Fri Mar 22 07:05:29 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Fri, 22 Mar 2024 07:05:29 GMT
Subject: Integrated: 8326643: JDK server does not send a dummy
 change_cipher_spec record after HelloRetryRequest message
In-Reply-To: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
References: <tkt7Ck3fcnaXFLPQ24mw00fzkFkY0jvBOEYKJNz__ws=.d43edde8-8a0e-46bb-a64a-49fc765be0f2@github.com>
Message-ID: <xmFPKDEMURM7ErvYiiBw73aYusEekKjF4nEXivAKCpA=.1139720b-04f6-4f0d-a35a-a995cc163b7b@github.com>

On Tue, 19 Mar 2024 07:13:19 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

> JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message.
> 
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a non-empty session ID in the ClientHello message, the server sends a dummy change_cipher_spec (CCS) record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
> 
> https://datatracker.ietf.org/doc/html/rfc8446#appendix-D.4

This pull request has now been integrated.

Changeset: d44aaa37
Author:    Prasadrao Koppula <pkoppula at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d44aaa37f98dd383aebbec097427feb1f1c29b74
Stats:     294 lines in 2 files changed: 293 ins; 0 del; 1 mod

8326643: JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message

Reviewed-by: djelinski, coffeys, jjiang, ascarpino

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

PR: https://git.openjdk.org/jdk/pull/18372


From shade at openjdk.org  Fri Mar 22 07:54:21 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 22 Mar 2024 07:54:21 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests
In-Reply-To: <5AypAzH7vFmyIv08P3S6ZMyi7H1oQTMOAi-Qdz5enPI=.6580750d-5336-412c-b2e4-8bd7ca19d8de@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <5AypAzH7vFmyIv08P3S6ZMyi7H1oQTMOAi-Qdz5enPI=.6580750d-5336-412c-b2e4-8bd7ca19d8de@github.com>
Message-ID: <HUK29yZKx6YJ94aIyoetaGcQ2auXPkDFZ4Nxw16knIc=.8408e610-8525-405b-a515-03bd2678804b@github.com>

On Thu, 21 Mar 2024 20:17:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Thanks for doing this - I think it is a fine idea to have a fallback option to use POST. It does need a CSR though since you are introducing a new system property.

All right, good! How do you feel about the option name? Would like to arrive to consensus for it before I plaster it all over CSR text and tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2014529345


From djelinski at openjdk.org  Fri Mar 22 08:47:21 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 22 Mar 2024 08:47:21 GMT
Subject: RFR: 8328556: Do not extract large CKO_SECRET_KEY keys from the
 NSS Software Token [v3]
In-Reply-To: <iBrhkiK0DVrj2AMDdu2XFYk0v2uVRorYXsRNIHxMqqA=.859616e2-d765-40bc-ac12-7039d636989b@github.com>
References: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
 <iBrhkiK0DVrj2AMDdu2XFYk0v2uVRorYXsRNIHxMqqA=.859616e2-d765-40bc-ac12-7039d636989b@github.com>
Message-ID: <9uNib3pWE_pad3eNaHGSImEQsnEO8-VmuRRdlsFN4bQ=.dd824ecf-0c8c-4291-ac14-33242d8c8e1f@github.com>

On Thu, 21 Mar 2024 17:23:44 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hi,
>> 
>> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token". See more details in the JBS ticket [1].
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.org/browse/JDK-8328556
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Type in a TestLargeSecretKeys test comment.

Thanks for adding the test, the proposed changes look good to me.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18389#pullrequestreview-1954247399


From coffeys at openjdk.org  Fri Mar 22 09:39:25 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 22 Mar 2024 09:39:25 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v3]
In-Reply-To: <YBhVF7k1lHkSXaqYjA28i8l5iYaq2NkSN5C8KTrkq_c=.b3ad4c0e-530f-4c85-bbbf-5c34524013fb@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>
 <YBhVF7k1lHkSXaqYjA28i8l5iYaq2NkSN5C8KTrkq_c=.b3ad4c0e-530f-4c85-bbbf-5c34524013fb@github.com>
Message-ID: <-5n3LqrSODPSmbPbDSCBHcpi9llOeTmwo_4PTNIgFZo=.48e4e4bd-927e-4c30-946b-546813731ccd@github.com>

On Thu, 21 Mar 2024 20:38:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - merge in krb5 debug changes and implement extra functionality. enhance krb5 test
>>  - krb5 debug merge
>>  - Merge branch 'master' into 8051959-tracing
>>  - Move help section higher. Add code comment
>>  - more test coverage
>>  - unused variable
>>  - use default hex output
>>  - static dateTimeFormatInitialized
>>  - Merge branch 'master' into 8051959-tracing
>>  - Holder class idiom
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/892daf98...5628bc22
>
> src/java.base/share/classes/sun/security/util/Debug.java line 191:
> 
>> 189:         if (printDateTime && !dateTimeFormatInitialized) {
>> 190:             // trigger loading of Locale service impl now to avoid
>> 191:             // possible bootstrap recursive class load issue
> 
> Does this need to be manually loaded? I thought the `FormatHolder` field will be automatically loaded when it's first accessed and only once.

It's still necessary I'm afraid. During an early classloader operation, the Security class can be triggered which causes security properties to be read. If debugging is enabled, this triggers loading of CLDR service. Quite a long stack trace but I'll paste it here for history.

I agree on your other comments - I'll try a clean up and will come back to you then.


 stderr: [Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
        at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:193)
        at java.base/sun.util.locale.provider.LocaleServiceProviderPool.findProviders(LocaleServiceProviderPool.java:311)
        at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:283)
        at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:245)
        at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197)
        at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:120)
        at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.getDisplayName(DateTimeFormatterBuilder.java:4484)
        at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.format(DateTimeFormatterBuilder.java:4535)
        at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2537)
        at java.base/java.time.format.DateTimeFormatter.formatTo(DateTimeFormatter.java:1905)
        at java.base/java.time.format.DateTimeFormatter.format(DateTimeFormatter.java:1879)
        at java.base/sun.security.util.Debug.extraInfo(Debug.java:345)
        at java.base/sun.security.util.Debug.println(Debug.java:299)
        at java.base/java.security.Security.loadProps(Security.java:161)
        at java.base/java.security.Security.initialize(Security.java:103)
        at java.base/java.security.Security.lambda$static$0(Security.java:84)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.base/java.security.Security.<clinit>(Security.java:83)
        at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
        at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
        at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
        at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
        at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
        at java.base/java.io.FilePermission.init(FilePermission.java:319)
        at java.base/java.io.FilePermission.<init>(FilePermission.java:490)
        at java.base/sun.net.www.protocol.file.FileURLConnection.getPermission(FileURLConnection.java:223)
        at java.base/sun.security.util.LazyCodeSourcePermissionCollection.ensureAdded(LazyCodeSourcePermissionCollection.java:69)
        at java.base/sun.security.util.LazyCodeSourcePermissionCollection.toString(LazyCodeSourcePermissionCollection.java:115)
        at java.base/java.lang.String.valueOf(String.java:4509)
        at java.base/java.lang.StringBuilder.append(StringBuilder.java:173)
        at java.base/java.security.ProtectionDomain.toString(ProtectionDomain.java:434)
        at java.base/java.lang.String.valueOf(String.java:4509)
        at java.base/java.lang.StringBuilder.append(StringBuilder.java:173)
        at java.base/java.security.SecureClassLoader$1.apply(SecureClassLoader.java:231)
        at java.base/java.security.SecureClassLoader$1.apply(SecureClassLoader.java:222)
        at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1713)
        at java.base/java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:222)
        at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
        at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:578)
        at java.base/java.lang.Class.forName(Class.java:557)
        at java.base/sun.launcher.LauncherHelper.loadMainClass(LauncherHelper.java:847)
        at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:732)
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:74)
        at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:502)
        at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
        at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:182)
        ... 48 more
Caused by: java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
        at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:193)
        at java.base/sun.util.locale.provider.LocaleServiceProviderPool.findProviders(LocaleServiceProviderPool.java:311)
        at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:283)
        at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:245)
        at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197)
        at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:120)
        at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.getDisplayName(DateTimeFormatterBuilder.java:4484)
        at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.format(DateTimeFormatterBuilder.java:4535)
        at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2537)
        at java.base/java.time.format.DateTimeFormatter.formatTo(DateTimeFormatter.java:1905)
        at java.base/java.time.format.DateTimeFormatter.format(DateTimeFormatter.java:1879)
        at java.base/sun.security.util.Debug.extraInfo(Debug.java:345)
        at java.base/sun.security.util.Debug.println(Debug.java:299)
        at java.base/java.security.SecureClassLoader$1.apply(SecureClassLoader.java:231)
        at java.base/java.security.SecureClassLoader$1.apply(SecureClassLoader.java:222)
        at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1713)
        at java.base/java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:222)
        at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:182)
        at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:821)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:640)
        at java.base/java.lang.Class.forName(Class.java:669)
        at java.base/java.lang.Class.forName(Class.java:644)
        at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:855)
        at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1080)
        at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
        at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1391)
        at java.base/sun.util.cldr.CLDRLocaleProviderAdapter.lambda$new$0(CLDRLocaleProviderAdapter.java:84)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
        at java.base/sun.util.cldr.CLDRLocaleProviderAdapter.<init>(CLDRLocaleProviderAdapter.java:83)
        at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
        ... 51 more
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:74)
        at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:502)
        at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
        at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:182)
        ... 82 more
Caused by: java.lang.IllegalStateException: Recursive update
        at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1768)
        at java.base/java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:222)
        at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:182)
        at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:821)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:640)
        at java.base/java.lang.Class.forName(Class.java:669)
        at java.base/java.lang.Class.forName(Class.java:644)
        at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:855)
        at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1080)
        at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
        at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1391)
        at java.base/sun.util.cldr.CLDRLocaleProviderAdapter.lambda$new$0(CLDRLocaleProviderAdapter.java:84)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
        at java.base/sun.util.cldr.CLDRLocaleProviderAdapter.<init>(CLDRLocaleProviderAdapter.java:83)
        at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
        ... 85 more
]

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1535303163


From coffeys at openjdk.org  Fri Mar 22 12:21:24 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 22 Mar 2024 12:21:24 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v3]
In-Reply-To: <-5n3LqrSODPSmbPbDSCBHcpi9llOeTmwo_4PTNIgFZo=.48e4e4bd-927e-4c30-946b-546813731ccd@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>
 <YBhVF7k1lHkSXaqYjA28i8l5iYaq2NkSN5C8KTrkq_c=.b3ad4c0e-530f-4c85-bbbf-5c34524013fb@github.com>
 <-5n3LqrSODPSmbPbDSCBHcpi9llOeTmwo_4PTNIgFZo=.48e4e4bd-927e-4c30-946b-546813731ccd@github.com>
Message-ID: <9KNjEPMBkhCWYT84XEDRY45pd_cWSZN4yvMA0TZuB7U=.31846f39-2d8e-4afd-9321-e594f8400ae5@github.com>

On Fri, 22 Mar 2024 09:36:35 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Debug.java line 191:
>> 
>>> 189:         if (printDateTime && !dateTimeFormatInitialized) {
>>> 190:             // trigger loading of Locale service impl now to avoid
>>> 191:             // possible bootstrap recursive class load issue
>> 
>> Does this need to be manually loaded? I thought the `FormatHolder` field will be automatically loaded when it's first accessed and only once.
>
> It's still necessary I'm afraid. During an early classloader operation, the Security class can be triggered which causes security properties to be read. If debugging is enabled, this triggers loading of CLDR service. Quite a long stack trace but I'll paste it here for history.
> 
> I agree on your other comments - I'll try a clean up and will come back to you then.
> 
> 
>  stderr: [Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
>         at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:193)
>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.findProviders(LocaleServiceProviderPool.java:311)
>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:283)
>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:245)
>         at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197)
>         at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:120)
>         at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.getDisplayName(DateTimeFormatterBuilder.java:4484)
>         at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.format(DateTimeFormatterBuilder.java:4535)
>         at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2537)
>         at java.base/java.time.format.DateTimeFormatter.formatTo(DateTimeFormatter.java:1905)
>         at java.base/java.time.format.DateTimeFormatter.format(DateTimeFormatter.java:1879)
>         at java.base/sun.security.util.Debug.extraInfo(Debug.java:345)
>         at java.base/sun.security.util.Debug.println(Debug.java:299)
>         at java.base/java.security.Security.loadProps(Security.java:161)
>         at java.base/java.security.Security.initialize(Security.java:103)
>         at java.base/java.security.Security.lambda$static$0(Security.java:84)
>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
>         at java.base/java.security.Security.<clinit>(Security.java:83)
>         at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProper...

Turns out that it's the `java.time.format.DateTimeFormatterBuilder.ZoneTextPrinterParser#format` call that triggers the early initialization of the CLDR service (via a `getDisplayName` call)

We can avoid this call if we print time data without timezone ID - i.e. 
using a pattern of "yyyy-MM-dd kk:mm:ss.SSS" rather than "yyyy-MM-dd kk:mm:ss.SSS z"

example of change: (no UTC printed)
(with display name) :
` properties[2024-03-22 09:55:48.985 UTC]: Initial security property: keystore.type.compat=true`

(without):
 `properties[2024-03-22 09:55:48.985]: Initial security property: keystore.type.compat=true`

I think we can live without the display name detail. Most logs relate to local timezone systems. It shortens the print also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1535486081


From weijun at openjdk.org  Fri Mar 22 13:31:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 22 Mar 2024 13:31:25 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v3]
In-Reply-To: <9KNjEPMBkhCWYT84XEDRY45pd_cWSZN4yvMA0TZuB7U=.31846f39-2d8e-4afd-9321-e594f8400ae5@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>
 <YBhVF7k1lHkSXaqYjA28i8l5iYaq2NkSN5C8KTrkq_c=.b3ad4c0e-530f-4c85-bbbf-5c34524013fb@github.com>
 <-5n3LqrSODPSmbPbDSCBHcpi9llOeTmwo_4PTNIgFZo=.48e4e4bd-927e-4c30-946b-546813731ccd@github.com>
 <9KNjEPMBkhCWYT84XEDRY45pd_cWSZN4yvMA0TZuB7U=.31846f39-2d8e-4afd-9321-e594f8400ae5@github.com>
Message-ID: <GRl7k2pRU8xXJU1NxxHTDKNyZRUrxFG3_Ulfm3s-1gI=.3baf612c-94da-41d5-9ec6-d42670665b5b@github.com>

On Fri, 22 Mar 2024 12:18:49 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> It's still necessary I'm afraid. During an early classloader operation, the Security class can be triggered which causes security properties to be read. If debugging is enabled, this triggers loading of CLDR service. Quite a long stack trace but I'll paste it here for history.
>> 
>> I agree on your other comments - I'll try a clean up and will come back to you then.
>> 
>> 
>>  stderr: [Error: A JNI error has occurred, please check your installation and try again
>> Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
>>         at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:193)
>>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.findProviders(LocaleServiceProviderPool.java:311)
>>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:283)
>>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:245)
>>         at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197)
>>         at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:120)
>>         at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.getDisplayName(DateTimeFormatterBuilder.java:4484)
>>         at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.format(DateTimeFormatterBuilder.java:4535)
>>         at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2537)
>>         at java.base/java.time.format.DateTimeFormatter.formatTo(DateTimeFormatter.java:1905)
>>         at java.base/java.time.format.DateTimeFormatter.format(DateTimeFormatter.java:1879)
>>         at java.base/sun.security.util.Debug.extraInfo(Debug.java:345)
>>         at java.base/sun.security.util.Debug.println(Debug.java:299)
>>         at java.base/java.security.Security.loadProps(Security.java:161)
>>         at java.base/java.security.Security.initialize(Security.java:103)
>>         at java.base/java.security.Security.lambda$static$0(Security.java:84)
>>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
>>         at java.base/java.security.Security.<clinit>(Security.java:83)
>>         at java.base/sun.security.util.Secu...
>
> Turns out that it's the `java.time.format.DateTimeFormatterBuilder.ZoneTextPrinterParser#format` call that triggers the early initialization of the CLDR service (via a `getDisplayName` call)
> 
> We can avoid this call if we print time data without timezone ID - i.e. 
> using a pattern of "yyyy-MM-dd kk:mm:ss.SSS" rather than "yyyy-MM-dd kk:mm:ss.SSS z"
> 
> example of change: (no UTC printed)
> (with display name) :
> ` properties[2024-03-22 09:55:48.985 UTC]: Initial security property: keystore.type.compat=true`
> 
> (without):
>  `properties[2024-03-22 09:55:48.985]: Initial security property: keystore.type.compat=true`
> 
> I think we can live without the display name detail. Most logs relate to local timezone systems. It shortens the print also.

Yes, using local timezone is OK. Your new test adds a `-Duser.timezone=UTC` and I doubt anyone is likely to change that.

Back to my comment, I don't understand how this could fix the recursion. This check is also done very early and why doesn't that `FormatHolder.DATE_TIME_FORMATTER.format(Instant.now())` trigger a similar error?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1535572519


From weijun at openjdk.org  Fri Mar 22 13:38:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 22 Mar 2024 13:38:24 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v3]
In-Reply-To: <GRl7k2pRU8xXJU1NxxHTDKNyZRUrxFG3_Ulfm3s-1gI=.3baf612c-94da-41d5-9ec6-d42670665b5b@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <jkG061r2K2N84q2e3u2dpvsFX-jtu-5ywHcrf-XAdhw=.56702df8-e47e-4bd5-acea-ac9c2a9b5a49@github.com>
 <YBhVF7k1lHkSXaqYjA28i8l5iYaq2NkSN5C8KTrkq_c=.b3ad4c0e-530f-4c85-bbbf-5c34524013fb@github.com>
 <-5n3LqrSODPSmbPbDSCBHcpi9llOeTmwo_4PTNIgFZo=.48e4e4bd-927e-4c30-946b-546813731ccd@github.com>
 <9KNjEPMBkhCWYT84XEDRY45pd_cWSZN4yvMA0TZuB7U=.31846f39-2d8e-4afd-9321-e594f8400ae5@github.com>
 <GRl7k2pRU8xXJU1NxxHTDKNyZRUrxFG3_Ulfm3s-1gI=.3baf612c-94da-41d5-9ec6-d42670665b5b@github.com>
Message-ID: <wexNUBthf6ihxb2nMDfsGwDnp3ulr5X3x3yUYdJuDvQ=.6e07ac96-47f4-4a75-820c-6b91ca5d363d@github.com>

On Fri, 22 Mar 2024 13:29:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Turns out that it's the `java.time.format.DateTimeFormatterBuilder.ZoneTextPrinterParser#format` call that triggers the early initialization of the CLDR service (via a `getDisplayName` call)
>> 
>> We can avoid this call if we print time data without timezone ID - i.e. 
>> using a pattern of "yyyy-MM-dd kk:mm:ss.SSS" rather than "yyyy-MM-dd kk:mm:ss.SSS z"
>> 
>> example of change: (no UTC printed)
>> (with display name) :
>> ` properties[2024-03-22 09:55:48.985 UTC]: Initial security property: keystore.type.compat=true`
>> 
>> (without):
>>  `properties[2024-03-22 09:55:48.985]: Initial security property: keystore.type.compat=true`
>> 
>> I think we can live without the display name detail. Most logs relate to local timezone systems. It shortens the print also.
>
> Yes, using local timezone is OK. Your new test adds a `-Duser.timezone=UTC` and I doubt anyone is likely to change that.
> 
> Back to my comment, I don't understand how this could fix the recursion. This check is also done very early and why doesn't that `FormatHolder.DATE_TIME_FORMATTER.format(Instant.now())` trigger a similar error?

In fact, I just tried `java -Djava.security.debug=all+timestamp sun.security.util.Debug` and there is an error no matter the if block is there or not.

I'm running with an exploded build. Hopefully that makes no difference.

And, both case are fine if the `Z` is removed from `PATTERN`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1535578787


From mullan at openjdk.org  Fri Mar 22 13:49:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 22 Mar 2024 13:49:21 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests
In-Reply-To: <HUK29yZKx6YJ94aIyoetaGcQ2auXPkDFZ4Nxw16knIc=.8408e610-8525-405b-a515-03bd2678804b@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <5AypAzH7vFmyIv08P3S6ZMyi7H1oQTMOAi-Qdz5enPI=.6580750d-5336-412c-b2e4-8bd7ca19d8de@github.com>
 <HUK29yZKx6YJ94aIyoetaGcQ2auXPkDFZ4Nxw16knIc=.8408e610-8525-405b-a515-03bd2678804b@github.com>
Message-ID: <328xuLpv12JPbL6_TrXiTbaBMsxoR-81i9-ylSNta80=.f9abb162-ad75-40aa-904f-005410d6deaa@github.com>

On Fri, 22 Mar 2024 07:52:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Thanks for doing this - I think it is a fine idea to have a fallback option to use POST. It does need a CSR though since you are introducing a new system property.
> 
> All right, good! How do you feel about the option name? Would like to arrive to consensus for it before I plaster it all over CSR text and tests.

Yes, I am fine with the name.

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2015145314


From shade at openjdk.org  Fri Mar 22 14:04:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 22 Mar 2024 14:04:34 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v2]
In-Reply-To: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
Message-ID: <XeHG2D8YkTM_6VIgK1JWN1TXU2iiAU5hqpv5FknUujw=.0863a061-ad74-4d5b-9f57-f6d0c7f4aa9d@github.com>

> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
> 
> Additional testing:
>  - [x] `jdk_security` passes out of the box (includes new test config)
>  - [x]  `jdk_security` passes with flag override
>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Amend CAInterop test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18408/files
  - new: https://git.openjdk.org/jdk/pull/18408/files/40c91409..ddf989e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18408&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18408&range=00-01

  Stats: 47 lines in 1 file changed: 47 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18408/head:pull/18408

PR: https://git.openjdk.org/jdk/pull/18408


From shade at openjdk.org  Fri Mar 22 14:23:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 22 Mar 2024 14:23:36 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v3]
In-Reply-To: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
Message-ID: <IYeKoYnqhP67VO1ax8v9rcCkw61FbWEYCVMgzusa2A0=.e2c3bb94-f2a3-4abe-93b2-055c59a237ca@github.com>

> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
> 
> Additional testing:
>  - [x] `jdk_security` passes out of the box (includes new test config)
>  - [x]  `jdk_security` passes with flag override
>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8328638-ocsp-post
 - Amend CAInterop test
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18408/files
  - new: https://git.openjdk.org/jdk/pull/18408/files/ddf989e0..0e239341

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18408&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18408&range=01-02

  Stats: 52703 lines in 2267 files changed: 7683 ins; 3769 del; 41251 mod
  Patch: https://git.openjdk.org/jdk/pull/18408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18408/head:pull/18408

PR: https://git.openjdk.org/jdk/pull/18408


From shade at openjdk.org  Fri Mar 22 14:23:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 22 Mar 2024 14:23:36 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v2]
In-Reply-To: <XeHG2D8YkTM_6VIgK1JWN1TXU2iiAU5hqpv5FknUujw=.0863a061-ad74-4d5b-9f57-f6d0c7f4aa9d@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <XeHG2D8YkTM_6VIgK1JWN1TXU2iiAU5hqpv5FknUujw=.0863a061-ad74-4d5b-9f57-f6d0c7f4aa9d@github.com>
Message-ID: <ZU-I6IpD7XmkzWYqzMnR5LAZq9obxunONERF4ySaOps=.7d49d218-4a25-4807-8075-f79a6ab8bef1@github.com>

On Fri, 22 Mar 2024 14:04:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
>> 
>> Additional testing:
>>  - [x] `jdk_security` passes out of the box (includes new test config)
>>  - [x]  `jdk_security` passes with flag override
>>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Amend CAInterop test

I amended the `CAInterop` test (unfortunately, it fails even without the patch, I think due to [JDK-8324583](https://bugs.openjdk.org/browse/JDK-8324583)), and filed the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2015207459


From mbalao at openjdk.org  Fri Mar 22 15:30:30 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 22 Mar 2024 15:30:30 GMT
Subject: Integrated: 8328556: Do not extract large CKO_SECRET_KEY keys from the
 NSS Software Token
In-Reply-To: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
References: <h_Y1BtTaOHHdB_hetNdQsHSL2g-bYS9iqrDETmVDnjw=.a56b8cce-ca68-415e-b95d-7233be44218f@github.com>
Message-ID: <K2frCChkHTtnXrkVPCowjkL2X5RQ06laDmrySBRj5QI=.fdaeeaec-3f29-437b-a983-0d3c9402d825@github.com>

On Wed, 20 Mar 2024 03:39:58 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hi,
> 
> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token". See more details in the JBS ticket [1].
> 
> No regressions observed in jdk/sun/security/pkcs11.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.org/browse/JDK-8328556

This pull request has now been integrated.

Changeset: 13cf0707
Author:    Martin Balao <mbalao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13cf0707f903609c9bda99a9bf7511f494f9feae
Stats:     83 lines in 2 files changed: 83 ins; 0 del; 0 mod

8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token

Reviewed-by: djelinski

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

PR: https://git.openjdk.org/jdk/pull/18389


From coffeys at openjdk.org  Fri Mar 22 16:27:38 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 22 Mar 2024 16:27:38 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v4]
In-Reply-To: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
Message-ID: <vvlwRA_B_9OoYWSs9q37hVWnqcplKZe316H13475Zi4=.e797ec83-652f-45f4-aefc-37ec9ff9c20d@github.com>

> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
> 
> examples:
> format without patch :
> 
> 
> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info included:
> 
> 
> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info and timestamp:
> 
> 
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
> 
> 
> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
> 
> current proposal is to keep the thread and timestamp information off (make it opt in)
> 
> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
> 
> e.g 
> 
> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
> 
> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Remove display name in format output. Simplify config checks. Test updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18084/files
  - new: https://git.openjdk.org/jdk/pull/18084/files/5628bc22..e88e663b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=02-03

  Stats: 105 lines in 3 files changed: 24 ins; 35 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/18084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18084/head:pull/18084

PR: https://git.openjdk.org/jdk/pull/18084


From coffeys at openjdk.org  Fri Mar 22 16:47:25 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 22 Mar 2024 16:47:25 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v4]
In-Reply-To: <vvlwRA_B_9OoYWSs9q37hVWnqcplKZe316H13475Zi4=.e797ec83-652f-45f4-aefc-37ec9ff9c20d@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <vvlwRA_B_9OoYWSs9q37hVWnqcplKZe316H13475Zi4=.e797ec83-652f-45f4-aefc-37ec9ff9c20d@github.com>
Message-ID: <1LJIGjrI2gNF9u2JrROcxQ7yTmBhwvqFjyrt16HXd2o=.a63de998-f413-4dad-832e-1a5559644199@github.com>

On Fri, 22 Mar 2024 16:27:38 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove display name in format output. Simplify config checks. Test updates

Updates pushed to incorporate review comments to date. As mentioned, the CLDR JNI issue is triggered via the display name lookup (e.g. "UTC") - we can edit the date string format to not include this data. I've removed the early lookup workaround code as a result.

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

PR Comment: https://git.openjdk.org/jdk/pull/18084#issuecomment-2015488223


From rhalade at openjdk.org  Fri Mar 22 18:03:53 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 22 Mar 2024 18:03:53 GMT
Subject: RFR: 8328825: Google CAInterop test failures
Message-ID: <reL99fRUC5O9EkyxbE3hD8ZXK98rX3QiCCYZa8alCtw=.54989b5b-f093-4122-816a-8238f56ee2cf@github.com>

Fix updates these tests to use OCSP or CRL revocation check with failover enabled. Intermediate root CA "WE3" doesn't specify OCSP responder in AIA extension. Check https://good.gsr4.demo.pki.goog/ for example.

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

Commit messages:
 - Googles CAInterop test failures

Changes: https://git.openjdk.org/jdk/pull/18459/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18459&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328825
  Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18459.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18459/head:pull/18459

PR: https://git.openjdk.org/jdk/pull/18459


From duke at openjdk.org  Fri Mar 22 18:50:26 2024
From: duke at openjdk.org (MustavData)
Date: Fri, 22 Mar 2024 18:50:26 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <u3gvzAbO1pRBjFKHUmnzKfLMhngOa9sLcpIXLUrsBzo=.1588be67-dfc4-4c03-a1b5-a4c5a3b73a71@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <u3gvzAbO1pRBjFKHUmnzKfLMhngOa9sLcpIXLUrsBzo=.1588be67-dfc4-4c03-a1b5-a4c5a3b73a71@github.com>
Message-ID: <LOPmJcbprh72q4ayt6H8tzii7ceAcM9gqXR-AzivPSQ=.77757582-c191-4d34-864e-8b9280b26c01@github.com>

On Thu, 14 Mar 2024 15:53:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> I also noticed a different problem. No matter if privileged or unprivileged, `keytool -genkeypair -storetype Windows-My-LOCALMACHINE` works successfully but the entries are actually created in Windows-MY-CURRENTUSER. This is unrelated to this code change and I filed https://bugs.openjdk.org/browse/JDK-8328184.

@wangweij - Regarding your test environment issues:

Your Windows 2016 systems needs its UAC enabled.   Here is an MS Community remedy for that:
[cmd.exe always runs as Administrator, how do I make it stop?](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiT4bLQrIiFAxW0M1kFHQTrCVMQrAIoAHoECDkQAQ&url=https%3A%2F%2Fanswers.microsoft.com%2Fen-us%2Fwindows%2Fforum%2Fall%2Fcmdexe-always-runs-as-administrator-how-do-i-make%2F63ac20c1-f1a3-4876-8199-cc02c6a5725d&usg=AOvVaw0nipY6czBotcTThwVvaWjv&opi=89978449)

With UAC enabled, you can switch between your user and administrator roles as a developer would.  In a secured production environment, by contrast, that is not allowed.    Instead, roles are performed by separate users who are assigned the minimum accesses required due to their respective roles.   The primary end user is a build engineer or automated process (_This is like the "java app" described in the Jan 17 reply by @rebarbora-mckvak ._) responsible for writing a code signature to a local file.  And, since that user would never create or install the local code signing certificate, read-only access is assigned.

-------
The unexpected signtool error for Step 2 is likely caused by using signtool's "/i" option to locate the certificate in the Windows keystore.   For repeatability across configurations, you should instead use the "/sha1" option which takes the code signing certificate's thumbprint value.   To retrieve the thumbprint:

1. Run the elevated MMC as before and navigate to "Local Computer / Personal / Certificates".
2. Double click the certificte, and click the Details tab.
3. Scroll to the bottom and click the Thumbprint field.
4. Copy the Thumbprint string that appears in the client area (a long hex string).
5. Paste it to your command line or script.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-2015702711


From weijun at openjdk.org  Fri Mar 22 20:10:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 22 Mar 2024 20:10:24 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation
In-Reply-To: <LOPmJcbprh72q4ayt6H8tzii7ceAcM9gqXR-AzivPSQ=.77757582-c191-4d34-864e-8b9280b26c01@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <u3gvzAbO1pRBjFKHUmnzKfLMhngOa9sLcpIXLUrsBzo=.1588be67-dfc4-4c03-a1b5-a4c5a3b73a71@github.com>
 <LOPmJcbprh72q4ayt6H8tzii7ceAcM9gqXR-AzivPSQ=.77757582-c191-4d34-864e-8b9280b26c01@github.com>
Message-ID: <qCiEzx4iM1-INxmxK1IFnv_jXXV08t-Tl0sh6uSDDJ4=.9a13051a-d274-4c41-875a-37543dd14037@github.com>

On Fri, 22 Mar 2024 18:43:11 GMT, MustavData <duke at openjdk.org> wrote:

>> I also noticed a different problem. No matter if privileged or unprivileged, `keytool -genkeypair -storetype Windows-My-LOCALMACHINE` works successfully but the entries are actually created in Windows-MY-CURRENTUSER. This is unrelated to this code change and I filed https://bugs.openjdk.org/browse/JDK-8328184.
>
> @wangweij - Regarding your test environment issues:
> 
> Your Windows 2016 systems needs its UAC enabled.   Here is an MS Community remedy for that:
> [cmd.exe always runs as Administrator, how do I make it stop?](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiT4bLQrIiFAxW0M1kFHQTrCVMQrAIoAHoECDkQAQ&url=https%3A%2F%2Fanswers.microsoft.com%2Fen-us%2Fwindows%2Fforum%2Fall%2Fcmdexe-always-runs-as-administrator-how-do-i-make%2F63ac20c1-f1a3-4876-8199-cc02c6a5725d&usg=AOvVaw0nipY6czBotcTThwVvaWjv&opi=89978449)
> 
> With UAC enabled, you can switch between your user and administrator roles as a developer would.  In a secured production environment, by contrast, that is not allowed.    Instead, roles are performed by separate users who are assigned the minimum accesses required due to their respective roles.   The primary end user is a build engineer or automated process (_This is like the "java app" described in the Jan 17 reply by @rebarbora-mckvak ._) responsible for writing a code signature to a local file.  And, since that user would never create or install the local code signing certificate, read-only access is assigned.
> 
> -------
> The unexpected signtool error for Step 2 is likely caused by using signtool's "/i" option to locate the certificate in the Windows keystore.   For repeatability across configurations, you should instead use the "/sha1" option which takes the code signing certificate's thumbprint value as an argument.   To retrieve the thumbprint:
> 
> 1. Run the elevated MMC as before and navigate to "Local Computer / Personal / Certificates".
> 2. Double click the certificte, and click the Details tab.
> 3. Scroll to the bottom and click the Thumbprint field.
> 4. Copy the Thumbprint string that appears in the client area (a long hex string).
> 5. Paste it to your command line or script.

@MustavData Thanks a lot for your help. I'll try the steps.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-2015826488


From duke at openjdk.org  Fri Mar 22 21:41:29 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Fri, 22 Mar 2024 21:41:29 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation [v3]
In-Reply-To: <in786IV2u7vFd4wZOyR5MRAfQT1lEQWOxLngANB6J50=.b020d31e-ffef-445d-9c33-e024beaa3d33@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <Hh1v82SxSC3ARrAL4QZJ53IB8zJRPkwX0WCrZ2kOWDU=.284d1668-3047-41ab-8fe9-a458da5c1830@github.com>
 <in786IV2u7vFd4wZOyR5MRAfQT1lEQWOxLngANB6J50=.b020d31e-ffef-445d-9c33-e024beaa3d33@github.com>
Message-ID: <s9rIUxeSFxQRw5vN4kw12O43SinqIpRzFcEwxXJugKc=.9f4ff821-c068-4db0-8c3b-4a50989c0060@github.com>

On Wed, 20 Mar 2024 19:45:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> rebarbora-mckvak has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - 8313367: signHash finds a key in the local machine store
>>  - 8313367: Local Computer store is opened with max. allowed permissions
>
> src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 806:
> 
>> 804:             {
>> 805:                 // If the key is in a local machine store, we need to try again with CRYPT_MACHINE flag.
>> 806:                 // See https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/cryptacquirecontext-troubleshooting
> 
> Since you said "if the key is in a local machine store", do you need to check if this is true before retrying with the `CRYPT_MACHINE_KEYSET` flag?

I am fairly new to Windows crypto API, so I will try to describe what happens on my test system and hopefully it will help to answer your question:

> loading store: Windows-MY-LOCALMACHINE
> MSCAPI (483): --------------------------

my keystore has two private key pairs, the following is loaded using MSCAPI by `..._loadKeysOrCertificateChains`

> MSCAPI (542): CAPI hCryptProv=2599423712528 hUserKey=2599426935088
> MSCAPI (632): stepan-cert: 1.2.840.113549.1.1.1

the second key pair is loaded using CNG:

> MSCAPI (483): --------------------------
> MSCAPI (527): CNG 2599431325072
> MSCAPI (632): Stepan-user: 1.2.840.113549.1.1.1

Now I try to sign data using the first key (CAPI):

> Alias: stepan-cert
> testing private key on SHA256withRSA
> MSCAPI (779): CryptCreateHash error: 80090008 (hCryptProv=2599423712528, hCryptKey=2599426935088), will try PROV_RSA_AES container: {48A88AAD-5CC2-4BBB-A26B-D64BF6A07D21}

`..._signHash` called `CryptCreateHash`, but it failed (NTE_BAD_ALGID), because the provider does not support SHA256. The original code tries to get the name of a container using `CryptGetProvParam(..., PP_CONTAINER, ...)` and tries to acquire a context.

> MSCAPI (788): CryptAcquireContext error: 80090016, may try PROV_RSA_AES (CRYPT_MACHINE)

That fails again with _Keyset does not exist_ error. Here comes my code trying to acquire a context again now with `CRYPT_MACHINE_KEYSET` flag set and that finally succeeds and signs the data.

I did a bit more of digging in Crypto API and it seems we can call `CryptGetProvParam(..., PP_KEYSET_TYPE, ...)` to get the information where the key is stored (user/machine store). I will modify the code in that way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16687#discussion_r1536248403


From duke at openjdk.org  Fri Mar 22 22:25:47 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Fri, 22 Mar 2024 22:25:47 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation [v4]
In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
Message-ID: <kMeqWZq3PDHeNw4_GXLHcHEK826UOvYBrGzujFW9Gek=.dfd9d95f-b9ee-4ce2-bfc8-90273362f149@github.com>

> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
> 
> If the process does not have write permissions, the store is opened as read-only (instead of failing).
> 
> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.

rebarbora-mckvak has updated the pull request incrementally with one additional commit since the last revision:

  8313367: signHash looks for a key in either user or machine store

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16687/files
  - new: https://git.openjdk.org/jdk/pull/16687/files/7f5c04fe..ab60267b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16687&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16687&range=02-03

  Stats: 15 lines in 1 file changed: 4 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16687/head:pull/16687

PR: https://git.openjdk.org/jdk/pull/16687


From duke at openjdk.org  Fri Mar 22 22:44:29 2024
From: duke at openjdk.org (rebarbora-mckvak)
Date: Fri, 22 Mar 2024 22:44:29 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation [v4]
In-Reply-To: <kMeqWZq3PDHeNw4_GXLHcHEK826UOvYBrGzujFW9Gek=.dfd9d95f-b9ee-4ce2-bfc8-90273362f149@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <kMeqWZq3PDHeNw4_GXLHcHEK826UOvYBrGzujFW9Gek=.dfd9d95f-b9ee-4ce2-bfc8-90273362f149@github.com>
Message-ID: <6ftXOjleqdwiO9RQo2gUrF5VAeGG6MGB7jtPpfSRbOk=.134a8e03-087e-4df7-ae45-b2ada67a2170@github.com>

On Fri, 22 Mar 2024 22:25:47 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> rebarbora-mckvak has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313367: signHash looks for a key in either user or machine store

The new code tested with keys in user and machine store:

> loading store: Windows-MY
> MSCAPI (542): CAPI hCryptProv=2240584244800 hUserKey=2240588561616
> MSCAPI (632): testkey: 1.2.840.113549.1.1.1
> Alias: testkey
> testing private key on SHA256withRSA
> MSCAPI (783): CryptCreateHash error: 80090008 (hCryptProv=2240584244800, hCryptKey=2240588561616), will try PROV_RSA_AES container: {A66FC309-D9F5-40ED-BFD9-6AC8D28A94D3}, keysetType=0
> SUCCESS, siglen: 256

Note the detected keysetType is 0 i.e. user's store.

> loading store: Windows-MY-LOCALMACHINE
> MSCAPI (542): CAPI hCryptProv=2240584244032 hUserKey=2240588562624
> MSCAPI (632): stepan-cert: 1.2.840.113549.1.1.1
> Alias: stepan-cert
> testing private key on SHA256withRSA
> MSCAPI (783): CryptCreateHash error: 80090008 (hCryptProv=2240584244032, hCryptKey=2240588562624), will try PROV_RSA_AES container: {48A88AAD-5CC2-4BBB-A26B-D64BF6A07D21}, keysetType=20
> SUCCESS, siglen: 256

Note the detected keysetType is 0x20 i.e. machine store.

BTW, I believe https://bugs.openjdk.org/browse/JDK-8328184 is caused by not passing `CRYPT_MACHINE_KEYSET` to `CryptAcquireContext` when the key is created in the store.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-2016040585


From valeriep at openjdk.org  Fri Mar 22 23:20:21 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 22 Mar 2024 23:20:21 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
In-Reply-To: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
References: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
Message-ID: <xKYkKZBj2uprRcbjPM_jn4g9fsn6X2ZGa_UQT6uAFt8=.da89ec59-b57b-4e2f-bc12-4c22b4136505@github.com>

On Thu, 21 Mar 2024 09:23:43 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> This fix intends to eliminate additional library call to C_EncryptInit or C_DecryptInit for Ciphers running through the CKM_AES_GCM.
> 
> Background: 
> 
> There are two types of CK_GCM_PARAMS struct that are used, one with IV bits and the other without it.
> 
> Initially there was issue in NSS library, due to the struct being different in header and spec version.
> NSS was using version from header but Solaris and SoftHsm was using normative version from spec.
> To maintain compatibility Java used to try library call with non-normative (header) version first and then upon failure retrial was made with updated GCM struct with IV bits.
> 
> Note: Trying normative (spec) version first with NSS library results in JVM crash.
> 
> Refer below for more information:
> https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11gcm2.h#L36  
> 
> However NSS has fixed this to use normative/spec version since 3.52 which has spec version 2.40
> Solaris and SoftHSM was already complying to the version mentioned in spec 2.40
> 
> The fix now check if spec version is 2.40 and then makes library call with appropriate structure.
> 
> Internal testing is green, further I have done internal testing manually with NSS library 3.96, 3.76, 3.51 (non-normative spec), 3.52 and 3.53
> Results are attached [nss_logs.zip](https://github.com/openjdk/jdk/files/14692787/nss_logs.zip)
> 
> Our existing tests like sun/security/pkcs11/Cipher/TestKATForGCM.java already tests the functionality and I have used the same for internal testing

Now that we are going with the normative version first, maybe we should make additional changes to clean up the flow further?Say,

1.  update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, CK_ULONG *pLength)` to allocate the normative structure instead. 
2.  enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to return a copy of mech pointer containing the non-normative structure.

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

PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2016094415


From duke at openjdk.org  Sat Mar 23 00:14:25 2024
From: duke at openjdk.org (Bernd)
Date: Sat, 23 Mar 2024 00:14:25 GMT
Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o
 Windows elevation [v4]
In-Reply-To: <kMeqWZq3PDHeNw4_GXLHcHEK826UOvYBrGzujFW9Gek=.dfd9d95f-b9ee-4ce2-bfc8-90273362f149@github.com>
References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com>
 <kMeqWZq3PDHeNw4_GXLHcHEK826UOvYBrGzujFW9Gek=.dfd9d95f-b9ee-4ce2-bfc8-90273362f149@github.com>
Message-ID: <ebJFxRhSlxKVcvTmD54W3woNoBMq5EEm4KJQg0DFFT8=.43a568b8-52d8-4740-a858-7b9ae134c347@github.com>

On Fri, 22 Mar 2024 22:25:47 GMT, rebarbora-mckvak <duke at openjdk.org> wrote:

>> This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> rebarbora-mckvak has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313367: signHash looks for a key in either user or machine store

Gm, Are those tests actually checking CAPI and CryptoNG providers? (Due to better key isolation the later one is much more interesting and might also be mandatory for some machine identity keys tied to platform security). Which Is the script which creates the keys, would like to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-2016205940


From pkumaraswamy at openjdk.org  Mon Mar 25 06:37:21 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Mon, 25 Mar 2024 06:37:21 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
In-Reply-To: <xKYkKZBj2uprRcbjPM_jn4g9fsn6X2ZGa_UQT6uAFt8=.da89ec59-b57b-4e2f-bc12-4c22b4136505@github.com>
References: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
 <xKYkKZBj2uprRcbjPM_jn4g9fsn6X2ZGa_UQT6uAFt8=.da89ec59-b57b-4e2f-bc12-4c22b4136505@github.com>
Message-ID: <idj5xyjZr3uPWG2yV6nSvd6sZYHi3NiJA9Tk6pCTrHU=.2347eb26-0e44-433a-88d2-1c4d4163fb60@github.com>

On Fri, 22 Mar 2024 23:17:51 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Now that we are going with the normative version first, maybe we should make additional changes to clean up the flow further?Say,
> 
> 1. update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, CK_ULONG *pLength)` to allocate the normative structure instead.
> 2. enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to return a copy of mech pointer containing the non-normative structure.

If PKCS11 spec version is less than 2.40, we are retaining the same logic as it exists today. 
If we make the above changes then there will be a crash in NSS version 3.51 and below where PKCS11 2.20 spec is used.

However, I can optimze the code by introducing new boolean variable in C_DecryptInit and C_EncryptInit to indicate if we need to send normative struct. If so, I'll add a goto statement to updateGCM params.
I did not do this initially because in 11u and above I have seen goto being removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2017320516


From jjiang at openjdk.org  Mon Mar 25 08:35:30 2024
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 25 Mar 2024 08:35:30 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v2]
In-Reply-To: <rRsPUlHLR3jxwyiMwBoY0W4-02zbgKNgwdRqreGhaOg=.6e97b8d2-5c5d-4c58-82f6-67de0c2d2b86@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <rRsPUlHLR3jxwyiMwBoY0W4-02zbgKNgwdRqreGhaOg=.6e97b8d2-5c5d-4c58-82f6-67de0c2d2b86@github.com>
Message-ID: <-OQL2W7DJ8a90DEaeIwBTuuNIN1HbNsPGnCSpGoWETU=.29b81163-683c-42ba-8251-907f6184febf@github.com>

On Fri, 22 Mar 2024 06:56:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
>> 
>> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
>> 
>> 1. Accept that PKIX+PKCS12 is slow.
>> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
>> 
>> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
>> 
>> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
>> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
>> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
>> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
>> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
>> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
>> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
>> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
>> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   ...
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with John's comments

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 168:

> 166:                     boolean mapEntryUpdated = processCredentials(builder,
> 167:                             i, alias);
> 168:                     if (!mapEntryUpdated){

Nit: need a space between `)` and `{`.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 191:

> 189:     @Override
> 190:     public X509Certificate[] getCertificateChain(String alias) {
> 191:         if (ksP12) {

It looks the new codes in method `getCertificateChain` and `getPrivateKey` are quite similar.
They both mainly retrieve the `X509Credentials` from the cached map, though finally the former returns certificate chain and the latter returns the private key.
So, it may be better to abstract a method for retrieving the `X509Credentials`, and this new method can be shared by the `getCertificateChain` and `getPrivateKey`.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 302:

> 300:     //
> 301: 
> 302:     private String removeAliasIndex (String alias){

Nit: the space between `x` and `(` can be removed; a space is needed between `)` and `{`.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 368:

> 366:         credentialsMap.put(builderAlias, cred);
> 367: 
> 368:         if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {

The method `processCredentials` itself logs for the success, however the callers log for the failure (see line 169 and 388).
Especially, the logs on successful and failed cases display different contents.
The log for the failed case doesn't contain the builder index and entry alias.

Could it also log the failed cases in the body of this method?
That should log the messages before returning false.
Then, the callers may not need to log for the method.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 369:

> 367: 
> 368:         if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 369:             SSLLogger.fine("found key for : " +

May not need the space between `for` and `:`.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 371:

> 369:             SSLLogger.fine("found key for : " +
> 370:                     "keystore builder index = " + builderIndex +
> 371:                     " alias = " + alias, (Object[]) certs);

Suggestion: add a `,` after the first `"`. That can separate the parameters `index` and `alias` clearly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1536987602
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1537029010
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1537000363
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1537178746
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1537120663
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1537139654


From shade at openjdk.org  Mon Mar 25 10:34:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 25 Mar 2024 10:34:52 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v4]
In-Reply-To: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
Message-ID: <-Y2Vf79KqRvIfmZMoB9WANJJiKHTrzFy6amU_tHsIYM=.19bf81bf-1791-412c-a9e9-2ae8bcf27f66@github.com>

> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
> 
> Additional testing:
>  - [x] `jdk_security` passes out of the box (includes new test config)
>  - [x]  `jdk_security` passes with flag override
>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override

Aleksey Shipilev 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 four additional commits since the last revision:

 - Merge branch 'master' into JDK-8328638-ocsp-post
 - Merge branch 'master' into JDK-8328638-ocsp-post
 - Amend CAInterop test
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18408/files
  - new: https://git.openjdk.org/jdk/pull/18408/files/0e239341..32a92a06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18408&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18408&range=02-03

  Stats: 2796 lines in 47 files changed: 1607 ins; 1040 del; 149 mod
  Patch: https://git.openjdk.org/jdk/pull/18408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18408/head:pull/18408

PR: https://git.openjdk.org/jdk/pull/18408


From djelinski at openjdk.org  Mon Mar 25 10:58:22 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 25 Mar 2024 10:58:22 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
In-Reply-To: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
References: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
Message-ID: <ApMwD7hSDatZinUiHxezZJc8ShK5rUFAouykHYiP_wU=.2959d892-76a3-4051-ad61-2331ce696fcf@github.com>

On Thu, 21 Mar 2024 09:23:43 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> This fix intends to eliminate additional library call to C_EncryptInit or C_DecryptInit for Ciphers running through the CKM_AES_GCM.
> 
> Background: 
> 
> There are two types of CK_GCM_PARAMS struct that are used, one with IV bits and the other without it.
> 
> Initially there was issue in NSS library, due to the struct being different in header and spec version.
> NSS was using version from header but Solaris and SoftHsm was using normative version from spec.
> To maintain compatibility Java used to try library call with non-normative (header) version first and then upon failure retrial was made with updated GCM struct with IV bits.
> 
> Note: Trying normative (spec) version first with NSS library results in JVM crash.
> 
> Refer below for more information:
> https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11gcm2.h#L36  
> 
> However NSS has fixed this to use normative/spec version since 3.52 which has spec version 2.40
> Solaris and SoftHSM was already complying to the version mentioned in spec 2.40
> 
> The fix now check if spec version is 2.40 and then makes library call with appropriate structure.
> 
> Internal testing is green, further I have done internal testing manually with NSS library 3.96, 3.76, 3.51 (non-normative spec), 3.52 and 3.53
> Results are attached [nss_logs.zip](https://github.com/openjdk/jdk/files/14692787/nss_logs.zip)
> 
> Our existing tests like sun/security/pkcs11/Cipher/TestKATForGCM.java already tests the functionality and I have used the same for internal testing

Does this PR actually improve the performance of AES/GCM? I'm asking because NSS documentation states that the newer NSS versions actually support both forms of the parameters, so I'd expect no performance penalty for using the old version. Is this on some other provider?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 464:

> 462:              * additional field ulvIV bits and then invoke C_EncryptInit
> 463:              */
> 464:             CK_VERSION cryptokiVersion = token.p11.C_GetInfo().cryptokiVersion;

use p11.getVersion() instead

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

PR Review: https://git.openjdk.org/jdk/pull/18425#pullrequestreview-1957308754
PR Review Comment: https://git.openjdk.org/jdk/pull/18425#discussion_r1537336036


From shade at openjdk.org  Mon Mar 25 11:55:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 25 Mar 2024 11:55:23 GMT
Subject: RFR: 8328825: Google CAInterop test failures
In-Reply-To: <reL99fRUC5O9EkyxbE3hD8ZXK98rX3QiCCYZa8alCtw=.54989b5b-f093-4122-816a-8238f56ee2cf@github.com>
References: <reL99fRUC5O9EkyxbE3hD8ZXK98rX3QiCCYZa8alCtw=.54989b5b-f093-4122-816a-8238f56ee2cf@github.com>
Message-ID: <ItR5mJswDB2xf0W6L8cuUbZGS6LPGhOCSJpq6I0jl2E=.4ecc5ddb-8f35-4018-bde1-615c7e568f8a@github.com>

On Fri, 22 Mar 2024 17:54:19 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Fix updates these tests to use OCSP or CRL revocation check with failover enabled. Intermediate root CA "WE3" doesn't specify OCSP responder in AIA extension. Check https://good.gsr4.demo.pki.goog/ for example.

This looks reasonable. I checked that tests for these certificates are now passing.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18459#pullrequestreview-1957525667


From rhalade at openjdk.org  Mon Mar 25 16:36:25 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 25 Mar 2024 16:36:25 GMT
Subject: Integrated: 8328825: Google CAInterop test failures
In-Reply-To: <reL99fRUC5O9EkyxbE3hD8ZXK98rX3QiCCYZa8alCtw=.54989b5b-f093-4122-816a-8238f56ee2cf@github.com>
References: <reL99fRUC5O9EkyxbE3hD8ZXK98rX3QiCCYZa8alCtw=.54989b5b-f093-4122-816a-8238f56ee2cf@github.com>
Message-ID: <18mf9B_vFJ13OhFn2-LGFdJUYOZXH9I1JfX1qyaXCe8=.40895acf-85d7-4f19-80bc-c9566d87e9b8@github.com>

On Fri, 22 Mar 2024 17:54:19 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Fix updates these tests to use OCSP or CRL revocation check with failover enabled. Intermediate root CA "WE3" doesn't specify OCSP responder in AIA extension. Check https://good.gsr4.demo.pki.goog/ for example.

This pull request has now been integrated.

Changeset: 70a15c73
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70a15c73638f45b9ed629abc0ea2d86a324bf624
Stats:     10 lines in 1 file changed: 0 ins; 5 del; 5 mod

8328825: Google CAInterop test failures

Reviewed-by: shade

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

PR: https://git.openjdk.org/jdk/pull/18459


From shade at openjdk.org  Mon Mar 25 19:24:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 25 Mar 2024 19:24:39 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
Message-ID: <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>

> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
> 
> Additional testing:
>  - [x] `jdk_security` passes out of the box (includes new test config)
>  - [x]  `jdk_security` passes with flag override
>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8328638-ocsp-post
 - Merge branch 'master' into JDK-8328638-ocsp-post
 - Merge branch 'master' into JDK-8328638-ocsp-post
 - Amend CAInterop test
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/18408/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18408&range=04
  Stats: 83 lines in 3 files changed: 79 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18408/head:pull/18408

PR: https://git.openjdk.org/jdk/pull/18408


From valeriep at openjdk.org  Mon Mar 25 20:45:22 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 25 Mar 2024 20:45:22 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
In-Reply-To: <ApMwD7hSDatZinUiHxezZJc8ShK5rUFAouykHYiP_wU=.2959d892-76a3-4051-ad61-2331ce696fcf@github.com>
References: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
 <ApMwD7hSDatZinUiHxezZJc8ShK5rUFAouykHYiP_wU=.2959d892-76a3-4051-ad61-2331ce696fcf@github.com>
Message-ID: <FPd63Woe-xj-c7Hu8hHJpIqBxqV9hiKJQ7UrqWKfUbA=.cb590a85-4fd7-4cc0-9dd8-befc6e32f228@github.com>

On Mon, 25 Mar 2024 10:55:35 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Does this PR actually improve the performance of AES/GCM? I'm asking because NSS documentation states that the newer NSS versions actually support both forms of the parameters, so I'd expect no performance penalty for using the old version. Is this on some other provider?

Yes, IIRC, the performance improvement is meant for non-NSS providers which only accepts the normative version. For these providers, the first call would fail due to invalid parameters, thus requiring 2 calls. This is due to earlier NSS impl would crash when given normative version. Thus the ordering of trying non-normative version before normative version.

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

PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2018878840


From valeriep at openjdk.org  Mon Mar 25 21:08:24 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 25 Mar 2024 21:08:24 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
In-Reply-To: <idj5xyjZr3uPWG2yV6nSvd6sZYHi3NiJA9Tk6pCTrHU=.2347eb26-0e44-433a-88d2-1c4d4163fb60@github.com>
References: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
 <xKYkKZBj2uprRcbjPM_jn4g9fsn6X2ZGa_UQT6uAFt8=.da89ec59-b57b-4e2f-bc12-4c22b4136505@github.com>
 <idj5xyjZr3uPWG2yV6nSvd6sZYHi3NiJA9Tk6pCTrHU=.2347eb26-0e44-433a-88d2-1c4d4163fb60@github.com>
Message-ID: <NuLVjZVM5qxFyriw6w0S1NmNqfj9MRf9S658WqUlHjA=.4796aac6-255a-4ab6-b164-ded921b5b063@github.com>

On Mon, 25 Mar 2024 06:34:53 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> > Now that we are going with the normative version first, maybe we should make additional changes to clean up the flow further?Say,
> > 
> > 1. update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, CK_ULONG *pLength)` to allocate the normative structure instead.
> > 2. enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to return a copy of mech pointer containing the non-normative structure.
> 
> If PKCS11 spec version is less than 2.40, we are retaining the same logic as it exists today. If we make the above changes then there will be a crash in NSS version 3.51 and below where PKCS11 2.20 spec is used.
> 
> However, I can optimze the code by introducing new boolean variable in C_DecryptInit and C_EncryptInit to indicate if we need to send normative struct. If so, I'll add a goto statement to updateGCM params. I did not do this initially because in 11u and above I have seen goto being removed.

Yes, it's better to add one boolean argument and just have one EncryptInit/DecryptInit() method. As times goes by, I'd expect old NSS library usage to die out and we should optimize the flow toward normative version.

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

PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2018913831


From duke at openjdk.org  Mon Mar 25 22:51:48 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 25 Mar 2024 22:51:48 GMT
Subject: RFR: JDK-8328501 Incorrect `@since` tags for security java
 security interfaces [v3]
In-Reply-To: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
Message-ID: <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>

> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>   Here's an illustration using Markdown and Java code:
> 
> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
> 
> As pointed out by my mentor Jan, 
> 
> 
> import javax.crypto.interfaces.DHPublicKey;
> 
> public class DhkeyTest {
> 
>     public static void main(DHPublicKey key) {
>         System.err.println(key.getParams());
>     }
>     
> }
> 
> 
> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
> 
> 
> - the same goes for these other interfaces 
> 
> java.security.interfaces.DSAPublicKey
> java.security.interfaces.XECPublicKey
> java.security.interfaces.DSAPrivateKey
> java.security.interfaces.ECPrivateKey
> java.security.interfaces.XECPrivateKey
> java.security.interfaces.EdECPrivateKey
> java.security.interfaces.ECPublicKey
> java.security.interfaces.EdECPublicKey
> javax.crypto.interfaces.DHPrivateKey
> javax.crypto.interfaces.DHPublicKey
> java.security.interfaces.RSAPublicKey
> java.security.interfaces.RSAPrivateKey

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year to 2024

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18373/files
  - new: https://git.openjdk.org/jdk/pull/18373/files/7ef8b4ee..b04a75e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=01-02

  Stats: 12 lines in 12 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18373/head:pull/18373

PR: https://git.openjdk.org/jdk/pull/18373


From xuelei at openjdk.org  Tue Mar 26 05:34:22 2024
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 26 Mar 2024 05:34:22 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v2]
In-Reply-To: <rRsPUlHLR3jxwyiMwBoY0W4-02zbgKNgwdRqreGhaOg=.6e97b8d2-5c5d-4c58-82f6-67de0c2d2b86@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <rRsPUlHLR3jxwyiMwBoY0W4-02zbgKNgwdRqreGhaOg=.6e97b8d2-5c5d-4c58-82f6-67de0c2d2b86@github.com>
Message-ID: <dXTsZPUtK6sDbUlbHc1uF_AwuzdQSs3M0rvjjivSGHA=.04077d95-d4a0-4cce-a3af-216cbf19a976@github.com>

On Fri, 22 Mar 2024 06:56:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
>> 
>> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
>> 
>> 1. Accept that PKIX+PKCS12 is slow.
>> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
>> 
>> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
>> 
>> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
>> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
>> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
>> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
>> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
>> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
>> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
>> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
>> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   ...
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with John's comments

> While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:

I'm not sure if it is the direction to improve performance by introducing new bugs.

If I read the benchmark result correction, for some cases, the performance was hurt by the update, some others was improved.  For the performance improved cases, it may be just in the cost of the key manager initialization performance.  The cost may be not desired as it hurts the boot-up performance to build a TLS context.

Alternatively, there might/could be an event get triggered when the key store get updated. It may worth to explore how to trigger the event, listen to the even and handle the event accordingly in the key manager and key store.

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

PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2019427132


From hchao at openjdk.org  Tue Mar 26 06:00:33 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 26 Mar 2024 06:00:33 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v3]
In-Reply-To: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
Message-ID: <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>

> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
> 
> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
> 
> 1. Accept that PKIX+PKCS12 is slow.
> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
> 
> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
> 
> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   104.764 ?   3.237  ops/s
> SSLHandshak...

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Updated with John's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17956/files
  - new: https://git.openjdk.org/jdk/pull/17956/files/a45fe0e5..fdab5aee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17956&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17956&range=01-02

  Stats: 144 lines in 1 file changed: 40 ins; 59 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/17956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17956/head:pull/17956

PR: https://git.openjdk.org/jdk/pull/17956


From hchao at openjdk.org  Tue Mar 26 06:00:34 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 26 Mar 2024 06:00:34 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v2]
In-Reply-To: <-OQL2W7DJ8a90DEaeIwBTuuNIN1HbNsPGnCSpGoWETU=.29b81163-683c-42ba-8251-907f6184febf@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <rRsPUlHLR3jxwyiMwBoY0W4-02zbgKNgwdRqreGhaOg=.6e97b8d2-5c5d-4c58-82f6-67de0c2d2b86@github.com>
 <-OQL2W7DJ8a90DEaeIwBTuuNIN1HbNsPGnCSpGoWETU=.29b81163-683c-42ba-8251-907f6184febf@github.com>
Message-ID: <McKwEtXjGcYhvM_fkiESQ2cBCQGiUQ8FaiRIq4Gd0og=.544f3434-bd23-446c-bda2-cacc45896a6a@github.com>

On Mon, 25 Mar 2024 02:17:18 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with John's comments
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 168:
> 
>> 166:                     boolean mapEntryUpdated = processCredentials(builder,
>> 167:                             i, alias);
>> 168:                     if (!mapEntryUpdated){
> 
> Nit: need a space between `)` and `{`.

Space added.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 191:
> 
>> 189:     @Override
>> 190:     public X509Certificate[] getCertificateChain(String alias) {
>> 191:         if (ksP12) {
> 
> It looks the new codes in method `getCertificateChain` and `getPrivateKey` are quite similar.
> They both mainly retrieve the `X509Credentials` from the cached map, though finally the former returns certificate chain and the latter returns the private key.
> So, it may be better to abstract a method for retrieving the `X509Credentials`, and this new method can be shared by the `getCertificateChain` and `getPrivateKey`.

New method created.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 302:
> 
>> 300:     //
>> 301: 
>> 302:     private String removeAliasIndex (String alias){
> 
> Nit: the space between `x` and `(` can be removed; a space is needed between `)` and `{`.

Fixed.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 368:
> 
>> 366:         credentialsMap.put(builderAlias, cred);
>> 367: 
>> 368:         if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 
> The method `processCredentials` itself logs for the success, however the callers log for the failure (see line 169 and 388).
> Especially, the logs on successful and failed cases display different contents.
> The log for the failed case doesn't contain the builder index and entry alias.
> 
> Could it also log the failed cases in the body of this method?
> That should log the messages before returning false.
> Then, the callers may not need to log for the method.

Done as suggested.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 369:
> 
>> 367: 
>> 368:         if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>> 369:             SSLLogger.fine("found key for : " +
> 
> May not need the space between `for` and `:`.

Space removed.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 371:
> 
>> 369:             SSLLogger.fine("found key for : " +
>> 370:                     "keystore builder index = " + builderIndex +
>> 371:                     " alias = " + alias, (Object[]) certs);
> 
> Suggestion: add a `,` after the first `"`. That can separate the parameters `index` and `alias` clearly.

"," added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1538631064
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1538631147
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1538631089
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1538631262
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1538631176
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1538631196


From nicolas at simide.fr  Tue Mar 26 07:11:51 2024
From: nicolas at simide.fr (Nicolas SIMIDE)
Date: Tue, 26 Mar 2024 08:11:51 +0100
Subject: RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are
 problematic
Message-ID: <c26b270a-8df1-4f20-9d0c-ca48ca0429bd@Spark>

Thank you Valerie PENG for your PR, that's exactly what we need for French Healthcare card.
I look foorward to use this in the next release.
Many thanks.
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240326/3ec5aaf2/attachment.htm>

From aturbanov at openjdk.org  Tue Mar 26 07:30:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 26 Mar 2024 07:30:23 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dnzll7uMjmAmGD_8ZaudJH1Kw90Dqq-j3TEiABaWSu4=.560e44c6-d426-4799-9fe6-fc04b338ef38@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

test/jdk/java/nio/channels/unixdomain/Bind.java line 162:

> 160:         // address with space should work
> 161:         checkNormal(() -> {
> 162:             UnixDomainSocketAddress usa =  UnixDomainSocketAddress.of("with space");

Suggestion:

            UnixDomainSocketAddress usa = UnixDomainSocketAddress.of("with space");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1538701870


From djelinski at openjdk.org  Tue Mar 26 07:50:21 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 26 Mar 2024 07:50:21 GMT
Subject: RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are
 problematic
In-Reply-To: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>
References: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>
Message-ID: <Xl3E_Q58Lsn2sPV7GVH9hJ8VkW_jmrQWqLV2vHdw2oI=.18d1926c-8d70-4905-b24f-499b81de48f6@github.com>

On Wed, 20 Mar 2024 02:44:19 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Existing legacy mechanism check disables mechanism(s) when the support is partial, e.g. supports decryption but not encryption, or supports verification but not signing. Some mechanisms can be used for both encryption/decryption and sign/verify such as RSA related ones. If the particular mechanism supports sign/verify/decryption but not encryption, it'd be disabled as a result. Fine tune the legacy mechanism check with the service type, i.e. supports encryption for Cipher,  sign for Signature, so the mechanism is disabled based on the service type.
> For completeness sake, I also added a PKCS11 provider configuration option to control this check (default is true, disable mechanisms with partial support).

LGTM

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18387#pullrequestreview-1959546087


From mullan at openjdk.org  Tue Mar 26 12:10:24 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 26 Mar 2024 12:10:24 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
Message-ID: <HlN4oIch9GgGR9EpyhXgdOONGTPkOx2lUyCbeEnX2f0=.d1448bd1-bc24-4701-aedb-3567b4b66cc6@github.com>

On Mon, 25 Mar 2024 19:24:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
>> 
>> Additional testing:
>>  - [x] `jdk_security` passes out of the box (includes new test config)
>>  - [x]  `jdk_security` passes with flag override
>>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Amend CAInterop test
>  - Fix

Looks good. Please also write a release note and I will review it.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18408#pullrequestreview-1960165816


From mdonovan at openjdk.org  Tue Mar 26 14:07:43 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 26 Mar 2024 14:07:43 GMT
Subject: RFR: 8328957: Update PKCS11Test.java to not use hardcoded path
Message-ID: <YH9QHsB9Ko5b1W-C28mK5LAcfWO2_H-bYp94b49ulD4=.d24c6e05-5502-41ed-83c8-8e789d77d4c6@github.com>

When resolving the location of the NSS library, the code appended a hard-coded path: `/nss/lib`. This makes it difficult for a person to specify the library when it is installed in a location such as `/usr/lib64`. 

In this PR, I removed the hard-coded path and updated the code to search the specified path for the nss library file, softokn3.

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

Commit messages:
 - 8328957: Update PKCS11Test.java to not use hardcoded path

Changes: https://git.openjdk.org/jdk/pull/18488/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18488&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328957
  Stats: 18 lines in 1 file changed: 10 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18488/head:pull/18488

PR: https://git.openjdk.org/jdk/pull/18488


From michaelm at openjdk.org  Tue Mar 26 15:56:23 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 26 Mar 2024 15:56:23 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dDrW4l3mQ8774vjN_VH6nQ94gMJSKK5xcEzMpxy_EPU=.8d557a74-6ad1-44ae-ba35-cab23db68f39@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

unixdomain NIO test changes look fine to me

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1960889711


From pkumaraswamy at openjdk.org  Tue Mar 26 16:01:22 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Tue, 26 Mar 2024 16:01:22 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
In-Reply-To: <NuLVjZVM5qxFyriw6w0S1NmNqfj9MRf9S658WqUlHjA=.4796aac6-255a-4ab6-b164-ded921b5b063@github.com>
References: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
 <xKYkKZBj2uprRcbjPM_jn4g9fsn6X2ZGa_UQT6uAFt8=.da89ec59-b57b-4e2f-bc12-4c22b4136505@github.com>
 <idj5xyjZr3uPWG2yV6nSvd6sZYHi3NiJA9Tk6pCTrHU=.2347eb26-0e44-433a-88d2-1c4d4163fb60@github.com>
 <NuLVjZVM5qxFyriw6w0S1NmNqfj9MRf9S658WqUlHjA=.4796aac6-255a-4ab6-b164-ded921b5b063@github.com>
Message-ID: <UhnPSQdqQYdCfM2r_LKAukyYfa2KPYBQVd1Ddp9XoGo=.df96b61d-addf-41bb-a173-64e1709d1d35@github.com>

On Mon, 25 Mar 2024 21:05:07 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> > > Now that we are going with the normative version first, maybe we should make additional changes to clean up the flow further?Say,
> > > 
> > > 1. update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, CK_ULONG *pLength)` to allocate the normative structure instead.
> > > 2. enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to return a copy of mech pointer containing the non-normative structure.
> > 
> > 
> > If PKCS11 spec version is less than 2.40, we are retaining the same logic as it exists today. If we make the above changes then there will be a crash in NSS version 3.51 and below where PKCS11 2.20 spec is used.
> > However, I can optimze the code by introducing new boolean variable in C_DecryptInit and C_EncryptInit to indicate if we need to send normative struct. If so, I'll add a goto statement to updateGCM params. I did not do this initially because in 11u and above I have seen goto being removed.
> 
> Yes, it's better to add one boolean argument and just have one EncryptInit/DecryptInit() method. As times goes by, I'd expect old NSS library usage to die out and we should optimize the flow toward normative version.

I just noticed, If I add boolean variable, it'll affect all classes (like P11RSA.java etc.) that extends PKCS11.java and we will have to modify all subclasses which might not be the right approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2020825235


From shade at openjdk.org  Tue Mar 26 16:10:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 26 Mar 2024 16:10:23 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <HlN4oIch9GgGR9EpyhXgdOONGTPkOx2lUyCbeEnX2f0=.d1448bd1-bc24-4701-aedb-3567b4b66cc6@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
 <HlN4oIch9GgGR9EpyhXgdOONGTPkOx2lUyCbeEnX2f0=.d1448bd1-bc24-4701-aedb-3567b4b66cc6@github.com>
Message-ID: <wE0AUJ4qaSVSLIueWk7gxC3TqM3Q8gbhWjCurCunPe4=.93d37e8c-c3f1-494e-87b0-8397cc886a7a@github.com>

On Tue, 26 Mar 2024 12:07:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Looks good. Please also write a release note and I will review it.

Here you go: https://bugs.openjdk.org/browse/JDK-8329111

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2020848495


From mbalao at openjdk.org  Tue Mar 26 16:33:21 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 26 Mar 2024 16:33:21 GMT
Subject: RFR: 8328957: Update PKCS11Test.java to not use hardcoded path
In-Reply-To: <YH9QHsB9Ko5b1W-C28mK5LAcfWO2_H-bYp94b49ulD4=.d24c6e05-5502-41ed-83c8-8e789d77d4c6@github.com>
References: <YH9QHsB9Ko5b1W-C28mK5LAcfWO2_H-bYp94b49ulD4=.d24c6e05-5502-41ed-83c8-8e789d77d4c6@github.com>
Message-ID: <Jfbh75bDntRdcgcCJnBimDXPyGgDEGxrwQFgMKEWgqk=.a20ce359-1994-4094-80ac-573859f27bd7@github.com>

On Tue, 26 Mar 2024 14:02:27 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> When resolving the location of the NSS library, the code appended a hard-coded path: `/nss/lib`. This makes it difficult for a person to specify the library when it is installed in a location such as `/usr/lib64`. 
> 
> In this PR, I removed the hard-coded path and updated the code to search the specified path for the nss library file, softokn3.

Hi @mpdonova ,

Thanks for contributing this fix. I've seen in java.nio.file.Files::find doc an implementation note saying that it should be used in a try-with-resource fashion to close the stream and any open directories. Should we consider this?

One more question. The ".orElse(path).getParent()" code path, what case is it intended for? I wonder in which cases this is expected to succeed.

Martin.-

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

PR Review: https://git.openjdk.org/jdk/pull/18488#pullrequestreview-1961059503


From mullan at openjdk.org  Tue Mar 26 17:00:27 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 26 Mar 2024 17:00:27 GMT
Subject: RFR: JDK-8328501 Incorrect `@since` tags for security java
 security interfaces [v3]
In-Reply-To: <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
 <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
Message-ID: <O_niwCQiMeys_zCeZoPcQSjlAIZtLjWFkLObCwT3w_4=.fc3b389c-e2e9-4ff5-a989-84c3cfbf8df3@github.com>

On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>>   Here's an illustration using Markdown and Java code:
>> 
>> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
>> 
>> As pointed out by my mentor Jan, 
>> 
>> 
>> import javax.crypto.interfaces.DHPublicKey;
>> 
>> public class DhkeyTest {
>> 
>>     public static void main(DHPublicKey key) {
>>         System.err.println(key.getParams());
>>     }
>>     
>> }
>> 
>> 
>> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
>> 
>> 
>> - the same goes for these other interfaces 
>> 
>> java.security.interfaces.DSAPublicKey
>> java.security.interfaces.XECPublicKey
>> java.security.interfaces.DSAPrivateKey
>> java.security.interfaces.ECPrivateKey
>> java.security.interfaces.XECPrivateKey
>> java.security.interfaces.EdECPrivateKey
>> java.security.interfaces.ECPublicKey
>> java.security.interfaces.EdECPublicKey
>> javax.crypto.interfaces.DHPrivateKey
>> javax.crypto.interfaces.DHPublicKey
>> java.security.interfaces.RSAPublicKey
>> java.security.interfaces.RSAPrivateKey
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year to 2024

Looks good. Please add a `noreg-doc` label to the bug.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18373#pullrequestreview-1961142238


From duke at openjdk.org  Tue Mar 26 17:06:22 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 26 Mar 2024 17:06:22 GMT
Subject: RFR: JDK-8328501 Incorrect `@since` tags for security java
 security interfaces [v3]
In-Reply-To: <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
 <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
Message-ID: <Arxi6abk4KiPWfugfSMlM_bfBX0vx5xcEI0V8MpUMko=.4c7b441d-519a-46a0-8317-4aaf10382a39@github.com>

On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>>   Here's an illustration using Markdown and Java code:
>> 
>> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
>> 
>> As pointed out by my mentor Jan, 
>> 
>> 
>> import javax.crypto.interfaces.DHPublicKey;
>> 
>> public class DhkeyTest {
>> 
>>     public static void main(DHPublicKey key) {
>>         System.err.println(key.getParams());
>>     }
>>     
>> }
>> 
>> 
>> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
>> 
>> 
>> - the same goes for these other interfaces 
>> 
>> java.security.interfaces.DSAPublicKey
>> java.security.interfaces.XECPublicKey
>> java.security.interfaces.DSAPrivateKey
>> java.security.interfaces.ECPrivateKey
>> java.security.interfaces.XECPrivateKey
>> java.security.interfaces.EdECPrivateKey
>> java.security.interfaces.ECPublicKey
>> java.security.interfaces.EdECPublicKey
>> javax.crypto.interfaces.DHPrivateKey
>> javax.crypto.interfaces.DHPublicKey
>> java.security.interfaces.RSAPublicKey
>> java.security.interfaces.RSAPrivateKey
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year to 2024

Mistake comment

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

PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2020995518


From duke at openjdk.org  Tue Mar 26 17:12:22 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 26 Mar 2024 17:12:22 GMT
Subject: RFR: JDK-8328501 Incorrect `@since` tags for security java
 security interfaces [v3]
In-Reply-To: <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
 <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
Message-ID: <lBvDKQcqEuHH_RBYWcFUB6l3hX6zXp2cL_PzKZrs8S4=.fb4871b9-28e3-47a9-8c14-a45dcaafeaf6@github.com>

On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>>   Here's an illustration using Markdown and Java code:
>> 
>> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
>> 
>> As pointed out by my mentor Jan, 
>> 
>> 
>> import javax.crypto.interfaces.DHPublicKey;
>> 
>> public class DhkeyTest {
>> 
>>     public static void main(DHPublicKey key) {
>>         System.err.println(key.getParams());
>>     }
>>     
>> }
>> 
>> 
>> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
>> 
>> 
>> - the same goes for these other interfaces 
>> 
>> java.security.interfaces.DSAPublicKey
>> java.security.interfaces.XECPublicKey
>> java.security.interfaces.DSAPrivateKey
>> java.security.interfaces.ECPrivateKey
>> java.security.interfaces.XECPrivateKey
>> java.security.interfaces.EdECPrivateKey
>> java.security.interfaces.ECPublicKey
>> java.security.interfaces.EdECPublicKey
>> javax.crypto.interfaces.DHPrivateKey
>> javax.crypto.interfaces.DHPublicKey
>> java.security.interfaces.RSAPublicKey
>> java.security.interfaces.RSAPrivateKey
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year to 2024

Done, will also add it to the 2 similar bugs that are left - I will integrate the changes tomorrow

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

PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2021011637


From mdonovan at openjdk.org  Tue Mar 26 17:48:49 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 26 Mar 2024 17:48:49 GMT
Subject: RFR: 8328957: Update PKCS11Test.java to not use hardcoded path
 [v2]
In-Reply-To: <YH9QHsB9Ko5b1W-C28mK5LAcfWO2_H-bYp94b49ulD4=.d24c6e05-5502-41ed-83c8-8e789d77d4c6@github.com>
References: <YH9QHsB9Ko5b1W-C28mK5LAcfWO2_H-bYp94b49ulD4=.d24c6e05-5502-41ed-83c8-8e789d77d4c6@github.com>
Message-ID: <_ESDIsjeeVmfV0asNm-d9UQbbjFsF1EdfUJStpkvHEI=.85ab20a8-39e5-4fd9-80c0-48795cdcc603@github.com>

> When resolving the location of the NSS library, the code appended a hard-coded path: `/nss/lib`. This makes it difficult for a person to specify the library when it is installed in a location such as `/usr/lib64`. 
> 
> In this PR, I removed the hard-coded path and updated the code to search the specified path for the nss library file, softokn3.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  added try-with-resources to Stream and cleaned up path logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18488/files
  - new: https://git.openjdk.org/jdk/pull/18488/files/61eb4d32..373da05e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18488&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18488&range=00-01

  Stats: 29 lines in 1 file changed: 2 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/18488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18488/head:pull/18488

PR: https://git.openjdk.org/jdk/pull/18488


From mdonovan at openjdk.org  Tue Mar 26 17:51:21 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 26 Mar 2024 17:51:21 GMT
Subject: RFR: 8328957: Update PKCS11Test.java to not use hardcoded path
 [v2]
In-Reply-To: <Jfbh75bDntRdcgcCJnBimDXPyGgDEGxrwQFgMKEWgqk=.a20ce359-1994-4094-80ac-573859f27bd7@github.com>
References: <YH9QHsB9Ko5b1W-C28mK5LAcfWO2_H-bYp94b49ulD4=.d24c6e05-5502-41ed-83c8-8e789d77d4c6@github.com>
 <Jfbh75bDntRdcgcCJnBimDXPyGgDEGxrwQFgMKEWgqk=.a20ce359-1994-4094-80ac-573859f27bd7@github.com>
Message-ID: <0kBBQEe3tK1Hw_uoxywZNnJloOCnKSoUUmHWgoYLEoY=.7d42e293-63ee-4bb1-9429-509595cd26a8@github.com>

On Tue, 26 Mar 2024 16:31:06 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hi @mpdonova ,
> 
> Thanks for contributing this fix. I've seen in java.nio.file.Files::find doc an implementation note saying that it should be used in a try-with-resource fashion to close the stream and any open directories. Should we consider this?
> 
> One more question. The ".orElse(path).getParent()" code path, what case is it intended for? I wonder in which cases this is expected to succeed.
> 
> Martin.-

I think adding the try-with-resources is a good idea. Always better to close things that potentially leave them open.

The `orElse(path).getParent()` was to return a default path that was then used higher-up on the call stack to check for the existence of the library. Looking at it again, that seemed redundant, since this change also looks for the existence of the library, so I refactored the code a little bit for the new `findNssLibrary()` method to return the path to the library or throw a SkippedException.

I think this is a cleaner way to do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18488#issuecomment-2021101482


From rhalade at openjdk.org  Tue Mar 26 18:13:24 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 26 Mar 2024 18:13:24 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
Message-ID: <HkVU-nmsFbyVr-0V66P3e4Jx9LMxWIiHAV0BiDjnaiY=.0aafb1f6-6d2d-483b-8dee-8e3b736ad735@github.com>

On Mon, 25 Mar 2024 19:24:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
>> 
>> Additional testing:
>>  - [x] `jdk_security` passes out of the box (includes new test config)
>>  - [x]  `jdk_security` passes with flag override
>>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Amend CAInterop test
>  - Fix

test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 478:

> 476:  * @library /test/lib
> 477:  * @build jtreg.SkippedException ValidatePathWithURL CAInterop
> 478:  * @run main/othervm -Djava.security.debug=certpath,ocsp CAInterop emsignrootcag1 OCSP

eMudhra OCSP responders don't support GET calls so these tests fail, refer - [JDK-8328830](https://bugs.openjdk.org/browse/JDK-8328830). We are following up with CA. Meanwhile, can you please add these test to ProblemList at https://github.com/openjdk/jdk/blob/master/test/jdk/ProblemList.txt#L627


# jdk_security_infra

security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#emsigneccrootcag3 8328830 generic-all 
security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#emsignrootcag1    8328830 generic-all

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18408#discussion_r1539854497


From bhuang at openjdk.org  Tue Mar 26 18:18:39 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 26 Mar 2024 18:18:39 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/nio/channels/unixdomain/Bind.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/2517f756..0f4130a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/18352


From shade at openjdk.org  Tue Mar 26 18:37:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 26 Mar 2024 18:37:23 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <HkVU-nmsFbyVr-0V66P3e4Jx9LMxWIiHAV0BiDjnaiY=.0aafb1f6-6d2d-483b-8dee-8e3b736ad735@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
 <HkVU-nmsFbyVr-0V66P3e4Jx9LMxWIiHAV0BiDjnaiY=.0aafb1f6-6d2d-483b-8dee-8e3b736ad735@github.com>
Message-ID: <YjwXh5DsJ3jLrVlV0uSRSnhXSP9loJV9PChiCQTYP70=.4c5c3cbd-cd23-4b52-a648-f4fc12a5e28c@github.com>

On Tue, 26 Mar 2024 18:10:39 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8328638-ocsp-post
>>  - Merge branch 'master' into JDK-8328638-ocsp-post
>>  - Merge branch 'master' into JDK-8328638-ocsp-post
>>  - Amend CAInterop test
>>  - Fix
>
> test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 478:
> 
>> 476:  * @library /test/lib
>> 477:  * @build jtreg.SkippedException ValidatePathWithURL CAInterop
>> 478:  * @run main/othervm -Djava.security.debug=certpath,ocsp CAInterop emsignrootcag1 OCSP
> 
> eMudhra OCSP responders don't support GET calls so these tests fail, refer - [JDK-8328830](https://bugs.openjdk.org/browse/JDK-8328830). We are following up with CA. Meanwhile, can you please add these test to ProblemList at https://github.com/openjdk/jdk/blob/master/test/jdk/ProblemList.txt#L627
> 
> 
> # jdk_security_infra
> 
> security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#emsigneccrootcag3 8328830 generic-all 
> security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#emsignrootcag1    8328830 generic-all

Oooooh! So we found the CA that does not like GET requests, nice. I think these tests should be problemlisted with [JDK-8328830](https://bugs.openjdk.org/browse/JDK-8328830) subtask, and the fix for [JDK-8328830](https://bugs.openjdk.org/browse/JDK-8328830) would then fix/resolve the issue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18408#discussion_r1539892392


From mbalao at openjdk.org  Tue Mar 26 18:40:23 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 26 Mar 2024 18:40:23 GMT
Subject: RFR: 8328957: Update PKCS11Test.java to not use hardcoded path
 [v2]
In-Reply-To: <_ESDIsjeeVmfV0asNm-d9UQbbjFsF1EdfUJStpkvHEI=.85ab20a8-39e5-4fd9-80c0-48795cdcc603@github.com>
References: <YH9QHsB9Ko5b1W-C28mK5LAcfWO2_H-bYp94b49ulD4=.d24c6e05-5502-41ed-83c8-8e789d77d4c6@github.com>
 <_ESDIsjeeVmfV0asNm-d9UQbbjFsF1EdfUJStpkvHEI=.85ab20a8-39e5-4fd9-80c0-48795cdcc603@github.com>
Message-ID: <891soGgcapkZMUUSgmZF4AX0hnntMFquYguNYeYbEEM=.85fa60aa-4e26-4edd-81dc-39f4f892b2d5@github.com>

On Tue, 26 Mar 2024 17:48:49 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> When resolving the location of the NSS library, the code appended a hard-coded path: `/nss/lib`. This makes it difficult for a person to specify the library when it is installed in a location such as `/usr/lib64`. 
>> 
>> In this PR, I removed the hard-coded path and updated the code to search the specified path for the nss library file, softokn3.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added try-with-resources to Stream and cleaned up path logic

Looks good to me. I verified that it fixes the problem when running PKCS11 tests with system libraries (e.g. /usr/lib64).

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

Marked as reviewed by mbalao (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18488#pullrequestreview-1961396374


From rhalade at openjdk.org  Tue Mar 26 19:01:26 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 26 Mar 2024 19:01:26 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <YjwXh5DsJ3jLrVlV0uSRSnhXSP9loJV9PChiCQTYP70=.4c5c3cbd-cd23-4b52-a648-f4fc12a5e28c@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
 <HkVU-nmsFbyVr-0V66P3e4Jx9LMxWIiHAV0BiDjnaiY=.0aafb1f6-6d2d-483b-8dee-8e3b736ad735@github.com>
 <YjwXh5DsJ3jLrVlV0uSRSnhXSP9loJV9PChiCQTYP70=.4c5c3cbd-cd23-4b52-a648-f4fc12a5e28c@github.com>
Message-ID: <leVN3L6EG2kN8KOHxa6q_LqHcW_0nXYbpXDOLT9Pgms=.6939c9e2-6c3d-411e-b517-5344a55f9dbd@github.com>

On Tue, 26 Mar 2024 18:34:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 478:
>> 
>>> 476:  * @library /test/lib
>>> 477:  * @build jtreg.SkippedException ValidatePathWithURL CAInterop
>>> 478:  * @run main/othervm -Djava.security.debug=certpath,ocsp CAInterop emsignrootcag1 OCSP
>> 
>> eMudhra OCSP responders don't support GET calls so these tests fail, refer - [JDK-8328830](https://bugs.openjdk.org/browse/JDK-8328830). We are following up with CA. Meanwhile, can you please add these test to ProblemList at https://github.com/openjdk/jdk/blob/master/test/jdk/ProblemList.txt#L627
>> 
>> 
>> # jdk_security_infra
>> 
>> security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#emsigneccrootcag3 8328830 generic-all 
>> security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#emsignrootcag1    8328830 generic-all
>
> Oooooh! So we found the CA's OCSP responder that does not like GET requests, nice. I think these tests should be problemlisted with [JDK-8328830](https://bugs.openjdk.org/browse/JDK-8328830) subtask, and the fix for [JDK-8328830](https://bugs.openjdk.org/browse/JDK-8328830) would then fix/resolve the issue?

Sure, I will do that then. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18408#discussion_r1539937209


From rhalade at openjdk.org  Tue Mar 26 19:24:22 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 26 Mar 2024 19:24:22 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
Message-ID: <Wl_7UdFNgkKUaAbrJQGpOHarcWn3I_t6EYPq6fnO-ZU=.887a4014-24e4-4b7f-86e9-994e0c13b126@github.com>

On Mon, 25 Mar 2024 19:24:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
>> 
>> Additional testing:
>>  - [x] `jdk_security` passes out of the box (includes new test config)
>>  - [x]  `jdk_security` passes with flag override
>>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Amend CAInterop test
>  - Fix

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18408#pullrequestreview-1961505717


From mullan at openjdk.org  Tue Mar 26 19:38:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 26 Mar 2024 19:38:21 GMT
Subject: RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are
 problematic
In-Reply-To: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>
References: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>
Message-ID: <CNNv_NN-Jmnuv7AJ1uGtVbs7komoE-UM9HlL6RkJhjw=.31406a49-af73-4790-93ff-fd8d2f2eabda@github.com>

On Wed, 20 Mar 2024 02:44:19 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Existing legacy mechanism check disables mechanism(s) when the support is partial, e.g. supports decryption but not encryption, or supports verification but not signing. Some mechanisms can be used for both encryption/decryption and sign/verify such as RSA related ones. If the particular mechanism supports sign/verify/decryption but not encryption, it'd be disabled as a result. Fine tune the legacy mechanism check with the service type, i.e. supports encryption for Cipher,  sign for Signature, so the mechanism is disabled based on the service type.
> For completeness sake, I also added a PKCS11 provider configuration option to control this check (default is true, disable mechanisms with partial support).

Is "disableLegacy" a standard PKCS11 attribute we are introducing support for? If so, I think a CSR is probably needed as it is kind of like a system property.

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

PR Comment: https://git.openjdk.org/jdk/pull/18387#issuecomment-2021313367


From valeriep at openjdk.org  Tue Mar 26 23:00:22 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 26 Mar 2024 23:00:22 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
In-Reply-To: <UhnPSQdqQYdCfM2r_LKAukyYfa2KPYBQVd1Ddp9XoGo=.df96b61d-addf-41bb-a173-64e1709d1d35@github.com>
References: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
 <xKYkKZBj2uprRcbjPM_jn4g9fsn6X2ZGa_UQT6uAFt8=.da89ec59-b57b-4e2f-bc12-4c22b4136505@github.com>
 <idj5xyjZr3uPWG2yV6nSvd6sZYHi3NiJA9Tk6pCTrHU=.2347eb26-0e44-433a-88d2-1c4d4163fb60@github.com>
 <NuLVjZVM5qxFyriw6w0S1NmNqfj9MRf9S658WqUlHjA=.4796aac6-255a-4ab6-b164-ded921b5b063@github.com>
 <UhnPSQdqQYdCfM2r_LKAukyYfa2KPYBQVd1Ddp9XoGo=.df96b61d-addf-41bb-a173-64e1709d1d35@github.com>
Message-ID: <N_4WWIVFk5CMxY2R3CHQYKnTWPedZyClEZP0FgotTrM=.1526fbe6-89ff-4b5e-a6e9-a6afdc8369ad@github.com>

On Tue, 26 Mar 2024 15:57:55 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> > > > Now that we are going with the normative version first, maybe we should make additional changes to clean up the flow further?Say,
> > > > 
> > > > 1. update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, CK_ULONG *pLength)` to allocate the normative structure instead.
> > > > 2. enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to return a copy of mech pointer containing the non-normative structure.
> > > 
> > > 
> > > If PKCS11 spec version is less than 2.40, we are retaining the same logic as it exists today. If we make the above changes then there will be a crash in NSS version 3.51 and below where PKCS11 2.20 spec is used.
> > > However, I can optimze the code by introducing new boolean variable in C_DecryptInit and C_EncryptInit to indicate if we need to send normative struct. If so, I'll add a goto statement to updateGCM params. I did not do this initially because in 11u and above I have seen goto being removed.
> > 
> > 
> > Yes, it's better to add one boolean argument and just have one EncryptInit/DecryptInit() method. As times goes by, I'd expect old NSS library usage to die out and we should optimize the flow toward normative version.
> 
> I just noticed, If I add boolean variable, it'll affect all classes (like P11RSA.java etc.) that extends PKCS11.java and we will have to modify all subclasses which might not be the right approach.

Hmm, good point, let me try it out and see if there are other choices.

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

PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2021606718


From valeriep at openjdk.org  Tue Mar 26 23:20:21 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 26 Mar 2024 23:20:21 GMT
Subject: RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are
 problematic
In-Reply-To: <CNNv_NN-Jmnuv7AJ1uGtVbs7komoE-UM9HlL6RkJhjw=.31406a49-af73-4790-93ff-fd8d2f2eabda@github.com>
References: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>
 <CNNv_NN-Jmnuv7AJ1uGtVbs7komoE-UM9HlL6RkJhjw=.31406a49-af73-4790-93ff-fd8d2f2eabda@github.com>
Message-ID: <pH1QtjVZU4XDqkekskspfoFR19DUXz2FwxRo8CqNnv0=.978c4ee3-a52e-46b8-97c5-069ad536b4d7@github.com>

On Tue, 26 Mar 2024 19:35:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Is "disableLegacy" a standard PKCS11 attribute we are introducing support for? If so, I think a CSR is probably needed as it is kind of like a system property.

It's a configuration file option. Just for the uncommon case if users would like to disable the check entirely. I can file a CSR on this. Thanks for the comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/18387#issuecomment-2021625299


From valeriep at openjdk.org  Tue Mar 26 23:20:22 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 26 Mar 2024 23:20:22 GMT
Subject: RFR: 8293345: SunPKCS11 provider checks on PKCS11 Mechanism are
 problematic
In-Reply-To: <Xl3E_Q58Lsn2sPV7GVH9hJ8VkW_jmrQWqLV2vHdw2oI=.18d1926c-8d70-4905-b24f-499b81de48f6@github.com>
References: <MYA0sRdTxmcPGNkKsNadvPNQdZpZZMjAyBOdUbsrkAw=.8e116007-8ac4-4970-a4bf-498e47b7e94d@github.com>
 <Xl3E_Q58Lsn2sPV7GVH9hJ8VkW_jmrQWqLV2vHdw2oI=.18d1926c-8d70-4905-b24f-499b81de48f6@github.com>
Message-ID: <ldLlp-eTTyQbddfv1-cJeWGLfQtpMer7U8FtJg3Jmx4=.c8289ba3-32b3-4b1d-915a-732417e91187@github.com>

On Tue, 26 Mar 2024 07:48:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> LGTM

Thanks for the review~

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

PR Comment: https://git.openjdk.org/jdk/pull/18387#issuecomment-2021625533


From hchao at openjdk.org  Wed Mar 27 03:36:22 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 27 Mar 2024 03:36:22 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v3]
In-Reply-To: <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
Message-ID: <RIbzW0MuEDqfkuTFYbMmu5nFJi87c7ctd1A7JuSXPOM=.30cecc9d-f02c-4414-bc08-30c6060412c3@github.com>

On Tue, 26 Mar 2024 06:00:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
>> 
>> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
>> 
>> 1. Accept that PKIX+PKCS12 is slow.
>> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
>> 
>> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
>> 
>> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
>> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
>> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
>> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
>> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
>> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
>> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
>> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
>> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   ...
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with John's comments

The current changes are for the PKIX KeyManager, and the SunX509 KeyManager will not execute the PKIX code path. Therefore, the performance of the SunX509 KeyManager becomes irrelevant. Here are the results of another set of runs:
    
Without changes:
Benchmark                                (keyMgr)(resume) (tlsVersion)  Mode  Cnt        Score         Error   Units
SSLHandshake.doHandshake  SunX509        true      TLSv1.2    thrpt    15  9071.959 ? 372.691   ops/s
SSLHandshake.doHandshake  SunX509        true            TLS     thrpt    15    913.964 ?   41.041   ops/s
SSLHandshake.doHandshake  SunX509       false      TLSv1.2    thrpt    15    602.424 ?   16.202   ops/s
SSLHandshake.doHandshake  SunX509       false            TLS     thrpt    15     518.974 ?   21.392   ops/s
SSLHandshake.doHandshake         PKIX         true     TLSv1.2     thrpt    15  9490.990 ?  118.610   ops/s
SSLHandshake.doHandshake         PKIX         true           TLS      thrpt    15     937.166 ?   23.937   ops/s
SSLHandshake.doHandshake         PKIX        false     TLSv1.2     thrpt    15      104.519 ?     2.657  ops/s
SSLHandshake.doHandshake         PKIX        false           TLS      thrpt    15     102.763 ?     1.536   ops/s

With changes:
Benchmark                                (keyMgr)(resume)   (tlsVersion)  Mode   Cnt       Score           Error  Units
SSLHandshake.doHandshake SunX509         true        TLSv1.2    thrpt    15  9386.371 ?   587.227  ops/s
SSLHandshake.doHandshake SunX509         true              TLS    thrpt     15    973.139 ?    12.022   ops/s
SSLHandshake.doHandshake SunX509        false        TLSv1.2    thrpt    15    615.763 ?       9.911   ops/s
SSLHandshake.doHandshake SunX509        false              TLS    thrpt    15    539.656 ?     11.618   ops/s
SSLHandshake.doHandshake        PKIX          true       TLSv1.2    thrpt    15   9713.760 ?  202.706   ops/s
SSLHandshake.doHandshake        PKIX          true              TLS    thrpt    15    910.733 ?      87.172   ops/s
SSLHandshake.doHandshake        PKIX         false       TLSv1.2    thrpt    15    603.587 ?    26.367   ops/s
SSLHandshake.doHandshake        PKIX         false             TLS     thrpt   15    533.897 ?      11.513   ops/s

In the case where "resume=false" for TLSv1.2 and TLS, the performance is slow without changes, which was also reported in the bug report. However, with the current change, the performance has improved. While there may be slightly different score numbers for each run, there is no significant performance hurt/impact.

I created a JMH benchmark to measure the time needed to build a TLS context using different SSL protocols ("TLSv1.2" and "TLS") and different KeyManager types ("SunX509" and "PKIX?). Here is the benchmark result:

Benchmark                                 (keyMgr)   (tlsVersion)   Mode  Cnt     Score       Error  Units
SSLHandshake.doHandshake   SunX509       TLSv1.2     thrpt   15    112.920 ? 10.518  ops/s
SSLHandshake.doHandshake   SunX509            TLS       thrpt   15   122.255 ?   3.128  ops/s
SSLHandshake.doHandshake          PKIX       TLSv1.2      thrpt   15   115.956 ?   5.490  ops/s
SSLHandshake.doHandshake          PKIX             TLS      thrpt   15   118.512 ?    3.574   ops/s

The performance between the SunX509 and PKIX KeyManagers for building SSL contexts seems fairly comparable. The changes made to X509KeyManagerImpl.java to cache keystore entries in the credentialsMap at initialization time for the PKIX KeyManager do not impact performance compared to SunX509.

The SunX509 KeyManager also caches keystore entries in its credentialsMap at initialization time. That?s why option 2 (PKIX does the same caching as SunX509 at initialization time) is listed as one of the preferences. However, the SunX509 KeyManager does not attempt to refresh a keystore entry in its cached map to accommodate keystore changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2021860848


From xuelei at openjdk.org  Wed Mar 27 04:22:22 2024
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 27 Mar 2024 04:22:22 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v3]
In-Reply-To: <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
Message-ID: <OumICd7wAck6jYcvyRF95tbC0yai64_zN79LgFcj9hI=.f784a769-d65a-4eab-93d6-30c4700fd826@github.com>

On Tue, 26 Mar 2024 06:00:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
>> 
>> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
>> 
>> 1. Accept that PKIX+PKCS12 is slow.
>> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
>> 
>> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
>> 
>> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
>> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
>> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
>> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
>> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
>> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
>> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
>> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
>> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   ...
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with John's comments

>From the description, it looks like you are concerning about that new bugs could be introduced and if the performance improvement worth the risk.  Before looking into the performance numbers, I think it would be nice to make sure no bugs was introduced. Otherwise, the performance improvement makes no sense.

> Without changes:
> SSLHandshake.doHandshake PKIX true TLS thrpt 15 937.166 ? 23.937 ops/s
>
> With changes:
> SSLHandshake.doHandshake PKIX true TLS thrpt 15 910.733 ? 87.172 ops/s

Here is a performance regression, from 937 to 910 ops/s.

> I created a JMH benchmark to measure the time needed to build a TLS context using different SSL protocols ("TLSv1.2" and "TLS") and different KeyManager types ("SunX509" and "PKIX?). Here is the benchmark result:
> 
> Benchmark (keyMgr) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake SunX509 TLSv1.2 thrpt 15 112.920 ? 10.518 ops/s SSLHandshake.doHandshake SunX509 TLS thrpt 15 122.255 ? 3.128 ops/s SSLHandshake.doHandshake PKIX TLSv1.2 thrpt 15 115.956 ? 5.490 ops/s SSLHandshake.doHandshake PKIX TLS thrpt 15 118.512 ? 3.574 ops/s
> 
> The performance between the SunX509 and PKIX KeyManagers for building SSL contexts seems fairly comparable. The changes made to X509KeyManagerImpl.java to cache keystore entries in the credentialsMap at initialization time for the PKIX KeyManager do not impact performance compared to SunX509.
> 

I think the comparing could between apple to apple.  PKIX and SunX509 are different key managers and could have different performance numbers.  Did you have the number for PKIX before and after the update for TLS boot-up?

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

PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2021896501


From hchao at openjdk.org  Wed Mar 27 08:17:22 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 27 Mar 2024 08:17:22 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v3]
In-Reply-To: <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
Message-ID: <uvpWpweBi4XT_0X2QCCsnTok8tYRMmEOzUUXzYsjiw8=.155666b0-83ba-4da6-9456-a2d46d2d127b@github.com>

On Tue, 26 Mar 2024 06:00:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
>> 
>> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
>> 
>> 1. Accept that PKIX+PKCS12 is slow.
>> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
>> 
>> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
>> 
>> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
>> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
>> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
>> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
>> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
>> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
>> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
>> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
>> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   ...
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with John's comments

Yes, it?d be nice to make sure no bugs were introduced. It is not desirable to introduce bugs when working on this issue to improve performance.

As each run may have slightly different scores, I ran the benchmark again. This time, it shows no regression as below. It seems the small score degradation may not be flagged as regression; hence, I should run multiple times to try to get the average results.

Benchmark                                       (keyMgr) (resume) (tlsVersion)   Mode   Cnt            Score         Error    Units   
SSLHandshake.doHandshake        SunX509         true       TLSv1.2     thrpt     15      9381.086 ?  171.396   ops/s
SSLHandshake.doHandshake        SunX509         true              TLS     thrpt     15        953.039 ?   19.431   ops/s
SSLHandshake.doHandshake        SunX509        false        TLSv1.2    thrpt     15         616.918 ?     7.652   ops/s
SSLHandshake.doHandshake        SunX509        false               TLS    thrpt     15        530.865 ?     7.109   ops/s
SSLHandshake.doHandshake               PKIX          true        TLSv1.2    thrpt     15      9653.252 ?   92.254  ops/s
SSLHandshake.doHandshake               PKIX          true              TLS     thrpt     15         951.771 ?   28.665  ops/s
SSLHandshake.doHandshake               PKIX         false        TLSv1.2    thrpt     15         617.288 ?      7.197   ops/s
SSLHandshake.doHandshake               PKIX         false              TLS     thrpt     15        521.930 ?    19.292  ops/s

I ran the benchmark to measure the time needed to build a TLS context using PKIX KeyManager (with protocols "TLSv1.2" and "TLS?) before and after the changes to X509KeyManagerImpl.java. Here are the results:

Without changes:
Benchmark                                (tlsVersion)    Mode    Cnt                  Score               Error     Units
SSLHandshake.doHandshake        TLSv1.2     thrpt      15      1073890.853 ?   18249.629     ops/s
SSLHandshake.doHandshake              TLS      thrpt      15      1139049.624 ?     5507.867     ops/s

With changes:
Benchmark                                (tlsVersion)    Mode    Cnt         Score           Error   Units
SSLHandshake.doHandshake        TLSv1.2     thrpt      15      130.039 ?       4.372   ops/s
SSLHandshake.doHandshake              TLS      thrpt      15      134.157 ?       1.903    ops/s

For the case without changes, it has higher Error values and looks like there is more variability in the measurements. I ran it again, and got similar results with no background processes running. I can?t explain if there may be environmental variables affecting the Error values. The changes that arise time to set up cached map at initialization time will be paid off for multiple handshaking.

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

PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2022178215


From djelinski at openjdk.org  Wed Mar 27 09:20:29 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 27 Mar 2024 09:20:29 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v3]
In-Reply-To: <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
Message-ID: <_dE1fveXXmnKOJ6V3HWh-KGqvTBbLO0ha5y2dCC2ZQY=.8aaa2b49-7300-4ef5-8532-72fe49454da1@github.com>

On Tue, 26 Mar 2024 06:00:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
>> 
>> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
>> 
>> 1. Accept that PKIX+PKCS12 is slow.
>> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
>> 
>> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
>> 
>> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
>> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
>> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
>> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
>> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
>> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
>> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
>> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
>> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   ...
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with John's comments

Well this PR doesn't introduce new bugs, but it exacerbates a preexisting one. The key manager does not try to validate the private/public key pair in any way, and will use whatever the key store provides, even if not valid. With the current key manager implementation, as soon as a key pair is changed, the key manager will start using the new pair. With the proposed PR, the private key is cached, and the certificate chain is used as the cache key. If the key store entry is corrected by changing the private key only, the key manager cache will not be updated, and the bad private key will be served until the certificate chain changes.

The default key store getEntry method implementation is not thread-safe, and during concurrent modification it can return a PrivateKeyEntry mixing the old private key and the new certificate chain. This was recently fixed for PKCS12 key stores (#18156), but other key store types might still be affected. This is why the PR is only caching PKCS12 key stores. This should really be explained in a code comment by the way.

With PKCS12 key store, we can still cache an invalid entry if the invalid entry is actually present in the key store. This could happen if a user tried to update the key/cert pair, but used the wrong key in the process. If the user then tried to fix the mistake by updating the key without changing the certificate chain, the change would not be picked up by the key manager, which would keep serving the wrong key.

The above scenario, as unlikely as it sounds, i why I'm not sure about this change.

What alternatives do we have?

- We could keep the existing code, and accept the fact that it's 400% slower than SunX509. However, given that we want to steer users away from SunX509 and change the default to PKIX ([JDK-8272875](https://bugs.openjdk.org/browse/JDK-8272875)), the performance penalty might be a bitter pill to swallow.
- We could use a faster KDF for private key encryption in PKCS12; JKS is also encrypting private keys, but the encryption overhead is negligible (SunX509+JKS had similar performance to PKIX+JKS last time I measured)
- We could implement a new caching key manager, that would cache key store entries during creation (like SunX509), and then behave identically to PKIX.
- We could add a new system property to control caching in PKIX key manager, then switch to PKIX, then point the users who need every last bit of performance to that system property.

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

PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2022282831


From shade at openjdk.org  Wed Mar 27 09:33:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Mar 2024 09:33:24 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
Message-ID: <CVgKsGtYjFtWYa2sVOzZkx_Fp1wtfo_HB9vKsR8FtO0=.3052e0a4-8d75-4d53-8c34-868cc71e6736@github.com>

On Mon, 25 Mar 2024 19:24:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
>> 
>> Additional testing:
>>  - [x] `jdk_security` passes out of the box (includes new test config)
>>  - [x]  `jdk_security` passes with flag override
>>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Amend CAInterop test
>  - Fix

CSR is done. I assume we are good here, and we can integrate?

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2022305331


From mullan at openjdk.org  Wed Mar 27 12:51:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 27 Mar 2024 12:51:25 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <CVgKsGtYjFtWYa2sVOzZkx_Fp1wtfo_HB9vKsR8FtO0=.3052e0a4-8d75-4d53-8c34-868cc71e6736@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
 <CVgKsGtYjFtWYa2sVOzZkx_Fp1wtfo_HB9vKsR8FtO0=.3052e0a4-8d75-4d53-8c34-868cc71e6736@github.com>
Message-ID: <QV9OU986gGtJLtaaGmo96OjIjPtxSn9YOAcVVWSl6os=.e7992384-e7e7-4f5e-aeb5-6b9c64225cd5@github.com>

On Wed, 27 Mar 2024 09:30:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> CSR is done. I assume we are good here, and we can integrate?

Yes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2022687436


From shade at openjdk.org  Wed Mar 27 14:47:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Mar 2024 14:47:31 GMT
Subject: RFR: 8328638: Fallback option for POST-only OCSP requests [v5]
In-Reply-To: <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
 <9NBq77IgZydjt44_3y-M79otp78NZT-FWyxPAbNPo7c=.95bd4b95-bb44-447b-a3e5-8d21538668b5@github.com>
Message-ID: <d9ZiCH2KtfHhQv-1EPhh6Sk3ZAYkiwNYT56L3zO_bIA=.130bd270-5a30-472b-8c83-cac84fc5e816@github.com>

On Mon, 25 Mar 2024 19:24:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
>> 
>> Additional testing:
>>  - [x] `jdk_security` passes out of the box (includes new test config)
>>  - [x]  `jdk_security` passes with flag override
>>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Merge branch 'master' into JDK-8328638-ocsp-post
>  - Amend CAInterop test
>  - Fix

All right, thanks! Here it goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18408#issuecomment-2022952755


From shade at openjdk.org  Wed Mar 27 14:47:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Mar 2024 14:47:32 GMT
Subject: Integrated: 8328638: Fallback option for POST-only OCSP requests
In-Reply-To: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
References: <Cdd7NO96q-15UtZ-0U2_pzU12UJ9U9F7c6B5Hin3Mu4=.fafba2d3-c091-4484-a44e-e0c880666cd4@github.com>
Message-ID: <wBX5roqXkvRFH2JofvvfuW5BKImhxLDnSiw_I2y2HfI=.87da1528-fe0a-40c5-9b03-23207eb56d92@github.com>

On Wed, 20 Mar 2024 19:48:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the rationale/discussion in the bug. This patch introduces the option that allows to restore pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The default behavior does not change. Better suggestions for flag name are welcome.
> 
> Additional testing:
>  - [x] `jdk_security` passes out of the box (includes new test config)
>  - [x]  `jdk_security` passes with flag override
>  - [x] Eyeballing `GetPostTests` amended debugging output, `GET`-s are used by default for small requests, `POST`-s are used for everything with flag override

This pull request has now been integrated.

Changeset: 614db2ea
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/614db2ea9e10346475eef34629eab54878aa482d
Stats:     83 lines in 3 files changed: 79 ins; 0 del; 4 mod

8328638: Fallback option for POST-only OCSP requests

Reviewed-by: mullan, rhalade

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

PR: https://git.openjdk.org/jdk/pull/18408


From xuelei at openjdk.org  Wed Mar 27 15:47:25 2024
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 27 Mar 2024 15:47:25 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v3]
In-Reply-To: <uvpWpweBi4XT_0X2QCCsnTok8tYRMmEOzUUXzYsjiw8=.155666b0-83ba-4da6-9456-a2d46d2d127b@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
 <uvpWpweBi4XT_0X2QCCsnTok8tYRMmEOzUUXzYsjiw8=.155666b0-83ba-4da6-9456-a2d46d2d127b@github.com>
Message-ID: <C6HXwGtYpjJ2qBHflJoafBZDM6uIjUFlLNsgPaoRK1I=.6055ff18-4d6c-476f-8791-27e0195ea119@github.com>

On Wed, 27 Mar 2024 08:15:08 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> I ran the benchmark to measure the time needed to build a TLS context using PKIX KeyManager (with protocols "TLSv1.2" and "TLS?) before and after the changes to X509KeyManagerImpl.java. Here are the results:
> 
> Without changes: Benchmark (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake TLSv1.2 thrpt 15 1073890.853 ? 18249.629 ops/s SSLHandshake.doHandshake TLS thrpt 15 1139049.624 ? 5507.867 ops/s
> 
> With changes: Benchmark (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake TLSv1.2 thrpt 15 130.039 ? 4.372 ops/s SSLHandshake.doHandshake TLS thrpt 15 134.157 ? 1.903 ops/s
> 
> For the case without changes, it has higher Error values and looks like there is more variability in the measurements. I ran it again, and got similar results with no background processes running. I can?t explain if there may be environmental variables affecting the Error values. The changes that arise time to set up cached map at initialization time will be paid off for multiple handshaking.

The Error values looks fine to me.  The differences between them are caused by the differences between op/s numbers.

If I read the numbers correctly, the TLS context buildup performance impact is about 100 times.  The performance downgrading is not small.  If I remembered correctly, a few years ago we tried hard to speed up the TLS booting up as it is very slow to initialize a TLS context and customers run into problems in their environment.  Thinking about the industry effort to deploy the service in cloud environment, where need to speed up the booting time as soon as possible.  In cloud or micro-service loading environment, it is more important to boot-up the context as soon as possible, comparing to speed up each connections.

I don't think we have to complete the cache during the context building period.  It is also possible to build the cache when the entry is required.

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

PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2023101804


From shade at openjdk.org  Wed Mar 27 20:28:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Mar 2024 20:28:42 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option
Message-ID: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>

[JDK-8328638](https://bugs.openjdk.org/browse/JDK-8328638) introduced a new boolean option, `com.sun.security.ocsp.useget`. We use the usual `Boolean.parseBoolean` to convert it from String to boolean value, which works correctly for `false` and `true` as boolean values. However, any string that is not `true` would be treated as `false`. Which means that if users mistype the value, they would get a `false`, which is a non-default value, which is against the spirit of the JDK-8328638.

It would be preferable to validate the option range a bit better, and default to the correct value on any error.

Additional testing:
  - [x] Eyeballing `GetAndPostTests` debugging, checking that GET/POST are properly enabled/disabled for `false`, `true`, `foobar` passed as option values
  - [x] `jdk_security`, out of the box
  - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=false` passes
  - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=foobar` passes

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/18525/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18525&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329213
  Stats: 37 lines in 2 files changed: 33 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18525/head:pull/18525

PR: https://git.openjdk.org/jdk/pull/18525


From valeriep at openjdk.org  Wed Mar 27 21:05:32 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 27 Mar 2024 21:05:32 GMT
Subject: RFR: 8261433: Better pkcs11 performance for
 libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit
In-Reply-To: <N_4WWIVFk5CMxY2R3CHQYKnTWPedZyClEZP0FgotTrM=.1526fbe6-89ff-4b5e-a6e9-a6afdc8369ad@github.com>
References: <22cG189Dd5JAv0fuRRJePqPtpRYnxSMZS9Vex113Z4Q=.7f1a3b51-c6a5-405a-98e8-45d964839044@github.com>
 <xKYkKZBj2uprRcbjPM_jn4g9fsn6X2ZGa_UQT6uAFt8=.da89ec59-b57b-4e2f-bc12-4c22b4136505@github.com>
 <idj5xyjZr3uPWG2yV6nSvd6sZYHi3NiJA9Tk6pCTrHU=.2347eb26-0e44-433a-88d2-1c4d4163fb60@github.com>
 <NuLVjZVM5qxFyriw6w0S1NmNqfj9MRf9S658WqUlHjA=.4796aac6-255a-4ab6-b164-ded921b5b063@github.com>
 <UhnPSQdqQYdCfM2r_LKAukyYfa2KPYBQVd1Ddp9XoGo=.df96b61d-addf-41bb-a173-64e1709d1d35@github.com>
 <N_4WWIVFk5CMxY2R3CHQYKnTWPedZyClEZP0FgotTrM=.1526fbe6-89ff-4b5e-a6e9-a6afdc8369ad@github.com>
Message-ID: <yt1AtKHhKkv4V5P6H0_gsiK6CUjQVA0LrHxIhb6K6GE=.cabf2e72-e951-443c-b05f-5c6f21657102@github.com>

On Tue, 26 Mar 2024 22:57:59 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> > Now that we are going with the normative version first, maybe we should make additional changes to clean up the flow further?Say,
> > 
> > 1. update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, CK_ULONG *pLength)` to allocate the normative structure instead.
> > 2. enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to return a copy of mech pointer containing the non-normative structure.
> 
> If PKCS11 spec version is less than 2.40, we are retaining the same logic as it exists today. If we make the above changes then there will be a crash in NSS version 3.51 and below where PKCS11 2.20 spec is used.
> 
> However, I can optimze the code by introducing new boolean variable in C_DecryptInit and C_EncryptInit to indicate if we need to send normative struct. If so, I'll add a goto statement to updateGCM params. I did not do this initially because in 11u and above I have seen goto being removed.

I prototyped this a bit and we can add GCM specific encrypt/decrypt init methods which takes additional boolean argument which indicate which version to use first for the PKCS11 init call. This way, we can remove the mechanism check in C_EncryptInit/C_DecryptInit since GCM init would go through the new GCM specific encrypt/decrypt init methods. I ended up also making changes to p11_convert.c and p11_util.c as well to use the normative version by default. 
It's easier to explain though the webrev/patch which I will share with you through slack. I don't have the older NSS library to verify the prototype changes, but it works fine w/ the current NSS library in the artifactory. Maybe you can take a look and let me know what do you think. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2023985885


From shade at openjdk.org  Thu Mar 28 09:09:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Mar 2024 09:09:46 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option [v2]
In-Reply-To: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
References: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
Message-ID: <M13kIzDsdTi20_4tKBfvV74J3K5R-qmGb0J_kMNYRR0=.6e0a5b72-b6fd-4687-9b2f-d068ec2bb79a@github.com>

> [JDK-8328638](https://bugs.openjdk.org/browse/JDK-8328638) introduced a new boolean option, `com.sun.security.ocsp.useget`. We use the usual `Boolean.parseBoolean` to convert it from String to boolean value, which works correctly for `false` and `true` as boolean values. However, any string that is not `true` would be treated as `false`. Which means that if users mistype the value, they would get a `false`, which is a non-default value, which is against the spirit of the JDK-8328638.
> 
> It would be preferable to validate the option range a bit better, and default to the correct value on any error.
> 
> Additional testing:
>   - [x] Eyeballing `GetAndPostTests` debugging, checking that GET/POST are properly enabled/disabled for `false`, `true`, `foobar` passed as option values
>   - [x] `jdk_security`, out of the box
>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=false` passes
>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=foobar` passes

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Invert equals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18525/files
  - new: https://git.openjdk.org/jdk/pull/18525/files/abe82ed5..f793a262

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18525&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18525&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/18525


From mullan at openjdk.org  Thu Mar 28 15:13:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 28 Mar 2024 15:13:46 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
 [v4]
In-Reply-To: <x_mbt4vFcIqTisw9TX-yqAIiEyN4yCZehoNqUwXH0NA=.cf4b5a6a-060b-4c32-89bd-d179094f11cb@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
 <x_mbt4vFcIqTisw9TX-yqAIiEyN4yCZehoNqUwXH0NA=.cf4b5a6a-060b-4c32-89bd-d179094f11cb@github.com>
Message-ID: <F2SI_PZwvynhu-9wD7grw365x4OIyfqlqoyMj__tg4A=.81aad780-c367-4738-8478-92740c1078d4@github.com>

On Tue, 5 Mar 2024 14:55:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Re-implement it as an `Iterator` to make sure it can only be iterated once and make debugger happy.
>> 
>> No regression, just a refactoring.
>
> Weijun Wang 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8323624
>  - rename class name
>  - use consistent names
>  - : iterator
>  - the fix

Also add a `noreg` label to issue.

src/java.base/share/classes/sun/security/jca/GetInstance.java line 112:

> 110:      * necessary.
> 111:      */
> 112:     public static List<Service> getServices(String type, String algorithm) {

Change the javadoc of these methods from "Return a List of all ..." to "Returns an iterator over all ..."

src/java.base/share/classes/sun/security/jca/GetInstance.java line 123:

> 121:      */
> 122:     @Deprecated
> 123:     public static Iterator<Service> getServices(String type,

Can we remove this deprecated method yet?

src/java.base/share/classes/sun/security/jca/ProviderList.java line 402:

> 400:      * The List returned is NOT thread safe.
> 401:      */
> 402:     public Iterator<Service> getServices(String type, String algorithm) {

Change the javadoc of this method from "Return a List of all ..." to "Returns an iterator over all ..." and replace other instances of "List" with "Iterator".

src/java.base/share/classes/sun/security/jca/ProviderList.java line 412:

> 410:      */
> 411:     @Deprecated
> 412:     public Iterator<Service> getServices(String type, List<String> algorithms) {

Can we remove this deprecated method yet?

src/java.base/share/classes/sun/security/jca/ProviderList.java line 429:

> 427:      * Not thread safe.
> 428:      */
> 429:     private final class ServiceList extends AbstractList<Service> {

Replace comments above of instances of "List" with "Iterator".

src/java.base/share/classes/sun/security/jca/ProviderList.java line 539:

> 537:         int index;
> 538: 
> 539:         public boolean hasNext() {

Suggest adding Override annotations to overridden methods.

src/java.base/share/classes/sun/security/jca/ProviderList.java line 565:

> 563:          * ServiceList.
> 564:          */
> 565:         ArrayList<PreferredEntry> getAll(ServiceIterator s) {

line 563: s/ServiceList/ServiceIterator/

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

PR Review: https://git.openjdk.org/jdk/pull/17381#pullrequestreview-1966465307
PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1543125796
PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1543126321
PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1543131268
PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1543135914
PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1543137500
PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1543139173
PR Review Comment: https://git.openjdk.org/jdk/pull/17381#discussion_r1543141780


From mullan at openjdk.org  Thu Mar 28 15:44:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 28 Mar 2024 15:44:32 GMT
Subject: RFR: 8327779: Remove deprecated internal field
 sun.security.x509.X509Key.key
In-Reply-To: <mldT4vDRBT6DMvgcXy39L2bXT_oWK1nL6khzkGrLqh8=.cd4cfe2e-df0e-4780-b63e-f491aa417671@github.com>
References: <mldT4vDRBT6DMvgcXy39L2bXT_oWK1nL6khzkGrLqh8=.cd4cfe2e-df0e-4780-b63e-f491aa417671@github.com>
Message-ID: <gfWQMT3M3IaW8-gLb8E1SPsesrkFhZ-N7gq7qbnEzfc=.ef6622e1-4027-4caa-b922-1453fe481cf5@github.com>

On Mon, 11 Mar 2024 09:58:42 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes the protected, deprecated field `X509Key.key` in the internal package `sun.security.x509`.
> 
> This field and the associated field `unusedBits` have been marked `@Deprecated` since the initial load. The recommended replacement is to use the `BitArray` representation, which does not require keys to be byte-aligned.
> 
> Two use sites of the `key` field were found in subclasses:
> 
> * The `ECPublicKeyImpl` constructor was updated to use a `BitArray` instead.
> * `ECPublicKeyImpl.parseKeyBits()` was updated to call `getKey().toByteArray()` to produce the byte array.
> 
> Somewhat unrelated, the method `ECPublicKeyImpl.getEncodedPublicValue()` was deemed unused and has been removed.
> 
> Testing and verification: This PR does not update any tests. GHA runs green.

This looks good to me - thanks for the cleanup.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18185#pullrequestreview-1966577694


From coffeys at openjdk.org  Thu Mar 28 15:59:47 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 28 Mar 2024 15:59:47 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar
Message-ID: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>

Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
This patch adds logic to the EventHelper class to detect recursion and prevent it.

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

Commit messages:
 - 8329013

Changes: https://git.openjdk.org/jdk/pull/18534/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18534&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329013
  Stats: 87 lines in 2 files changed: 79 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18534/head:pull/18534

PR: https://git.openjdk.org/jdk/pull/18534


From mullan at openjdk.org  Thu Mar 28 18:22:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 28 Mar 2024 18:22:32 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option [v2]
In-Reply-To: <M13kIzDsdTi20_4tKBfvV74J3K5R-qmGb0J_kMNYRR0=.6e0a5b72-b6fd-4687-9b2f-d068ec2bb79a@github.com>
References: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
 <M13kIzDsdTi20_4tKBfvV74J3K5R-qmGb0J_kMNYRR0=.6e0a5b72-b6fd-4687-9b2f-d068ec2bb79a@github.com>
Message-ID: <9DVJM_gO5S2ml8qwDg4uXGcF-yQFYsAhidlqHonRDFQ=.d18bc353-ba58-41e8-ae8e-23608fa5357b@github.com>

On Thu, 28 Mar 2024 09:09:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8328638](https://bugs.openjdk.org/browse/JDK-8328638) introduced a new boolean option, `com.sun.security.ocsp.useget`. We use the usual `Boolean.parseBoolean` to convert it from String to boolean value, which works correctly for `false` and `true` as boolean values. However, any string that is not `true` would be treated as `false`. Which means that if users mistype the value, they would get a `false`, which is a non-default value, which is against the spirit of the JDK-8328638.
>> 
>> It would be preferable to validate the option range a bit better, and default to the correct value on any error.
>> 
>> Additional testing:
>>   - [x] Eyeballing `GetAndPostTests` debugging, checking that GET/POST are properly enabled/disabled for `false`, `true`, `foobar` passed as option values
>>   - [x] `jdk_security`, out of the box
>>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=false` passes
>>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=foobar` passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Invert equals

Can you also add to the RN that any value other than "false" (case-insensitive) defaults to "true".

src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 235:

> 233:      * @param dbg a Debug object, if null no debug messages will be sent
> 234:      *
> 235:      * @return an boolean value corresponding to the value in the System property.

s/an/a/

src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 239:

> 237:      *      will be returned.
> 238:      */
> 239:     public static boolean privilegedGetBooleanProp(String prop, boolean def, Debug dbg) {

It probably makes more sense to put this method in the `GetBooleanAction` class.

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

PR Review: https://git.openjdk.org/jdk/pull/18525#pullrequestreview-1966933688
PR Review Comment: https://git.openjdk.org/jdk/pull/18525#discussion_r1543422305
PR Review Comment: https://git.openjdk.org/jdk/pull/18525#discussion_r1543421938


From shade at openjdk.org  Thu Mar 28 18:30:45 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Mar 2024 18:30:45 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option [v3]
In-Reply-To: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
References: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
Message-ID: <GwuOn9YjkszV58QpV53HdPn6avSPtGfUkBNVULHw4D4=.4e062d02-c7f3-49cb-b0c9-dec1e4cba98a@github.com>

> [JDK-8328638](https://bugs.openjdk.org/browse/JDK-8328638) introduced a new boolean option, `com.sun.security.ocsp.useget`. We use the usual `Boolean.parseBoolean` to convert it from String to boolean value, which works correctly for `false` and `true` as boolean values. However, any string that is not `true` would be treated as `false`. Which means that if users mistype the value, they would get a `false`, which is a non-default value, which is against the spirit of the JDK-8328638.
> 
> It would be preferable to validate the option range a bit better, and default to the correct value on any error.
> 
> Additional testing:
>   - [x] Eyeballing `GetAndPostTests` debugging, checking that GET/POST are properly enabled/disabled for `false`, `true`, `foobar` passed as option values
>   - [x] `jdk_security`, out of the box
>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=false` passes
>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=foobar` passes

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Touchup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18525/files
  - new: https://git.openjdk.org/jdk/pull/18525/files/f793a262..b1a03e81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18525&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18525&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/18525


From shade at openjdk.org  Thu Mar 28 18:30:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Mar 2024 18:30:46 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option [v2]
In-Reply-To: <9DVJM_gO5S2ml8qwDg4uXGcF-yQFYsAhidlqHonRDFQ=.d18bc353-ba58-41e8-ae8e-23608fa5357b@github.com>
References: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
 <M13kIzDsdTi20_4tKBfvV74J3K5R-qmGb0J_kMNYRR0=.6e0a5b72-b6fd-4687-9b2f-d068ec2bb79a@github.com>
 <9DVJM_gO5S2ml8qwDg4uXGcF-yQFYsAhidlqHonRDFQ=.d18bc353-ba58-41e8-ae8e-23608fa5357b@github.com>
Message-ID: <Ftmf4EFSZwh9EHO6SJBR76BZJxGjpEouCJBijrdvjEM=.9719e5a7-5280-427c-a698-2a8a9943f616@github.com>

On Thu, 28 Mar 2024 18:19:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Can you also add to the RN that any value other than "false" (case-insensitive) defaults to "true".

Amended the existing [RN](https://bugs.openjdk.org/browse/JDK-8329111).

> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 235:
> 
>> 233:      * @param dbg a Debug object, if null no debug messages will be sent
>> 234:      *
>> 235:      * @return an boolean value corresponding to the value in the System property.
> 
> s/an/a/

Done.

> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 239:
> 
>> 237:      *      will be returned.
>> 238:      */
>> 239:     public static boolean privilegedGetBooleanProp(String prop, boolean def, Debug dbg) {
> 
> It probably makes more sense to put this method in the `GetBooleanAction` class.

I thought so first too, but decided that `GetPropertyAction` is a better place for it, because it needs the generic `privilegedGetProperty`. It is also adjacent to `privilegedGetTimeoutProp` that returns `int`. Makes sense?

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

PR Comment: https://git.openjdk.org/jdk/pull/18525#issuecomment-2025856087
PR Review Comment: https://git.openjdk.org/jdk/pull/18525#discussion_r1543436079
PR Review Comment: https://git.openjdk.org/jdk/pull/18525#discussion_r1543436216


From mullan at openjdk.org  Thu Mar 28 18:56:31 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 28 Mar 2024 18:56:31 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option [v2]
In-Reply-To: <Ftmf4EFSZwh9EHO6SJBR76BZJxGjpEouCJBijrdvjEM=.9719e5a7-5280-427c-a698-2a8a9943f616@github.com>
References: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
 <M13kIzDsdTi20_4tKBfvV74J3K5R-qmGb0J_kMNYRR0=.6e0a5b72-b6fd-4687-9b2f-d068ec2bb79a@github.com>
 <9DVJM_gO5S2ml8qwDg4uXGcF-yQFYsAhidlqHonRDFQ=.d18bc353-ba58-41e8-ae8e-23608fa5357b@github.com>
 <Ftmf4EFSZwh9EHO6SJBR76BZJxGjpEouCJBijrdvjEM=.9719e5a7-5280-427c-a698-2a8a9943f616@github.com>
Message-ID: <b2G97BOnvNF5Ie-wCd3BzF4TZP-VnQ3uv2JYLqXl5J4=.d3da5745-a09f-47dc-b57a-bd3772c726a3@github.com>

On Thu, 28 Mar 2024 18:26:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 239:
>> 
>>> 237:      *      will be returned.
>>> 238:      */
>>> 239:     public static boolean privilegedGetBooleanProp(String prop, boolean def, Debug dbg) {
>> 
>> It probably makes more sense to put this method in the `GetBooleanAction` class.
>
> I thought so first too, but decided that `GetPropertyAction` is a better place for it, because it needs the generic `privilegedGetProperty`. It is also adjacent to `privilegedGetTimeoutProp` that returns `int`. Makes sense?

Right, that's a good point because you need to get the string value of the property and not a boolean directly. Ok then.

For a test, what do you think about adding another @run line to `GetAndPostTest` like:

`* @run main/othervm -Dcom.sun.security.ocsp.useget=flase GetAndPostTests`

and also modifying the POST code of test/jdk/java/security/testlibrary/SimpleOCSPServer.java to check that when the request is less than 255 bytes, the system property is set to "false" and nothing else? The server runs in the same process as the test, so I think that should work.

This would help eliminate the possibility of the property accidentally not working in the future and reverting to GET instead of POST.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18525#discussion_r1543488316


From shade at openjdk.org  Thu Mar 28 19:48:55 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Mar 2024 19:48:55 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option [v4]
In-Reply-To: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
References: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
Message-ID: <dhIVNqORCV0eTa13RJ6zMNuCXutL77BxyM3EsqzF5y0=.32c5b44d-0ae1-41dd-9d38-6d472f6a26f0@github.com>

> [JDK-8328638](https://bugs.openjdk.org/browse/JDK-8328638) introduced a new boolean option, `com.sun.security.ocsp.useget`. We use the usual `Boolean.parseBoolean` to convert it from String to boolean value, which works correctly for `false` and `true` as boolean values. However, any string that is not `true` would be treated as `false`. Which means that if users mistype the value, they would get a `false`, which is a non-default value, which is against the spirit of the JDK-8328638.
> 
> It would be preferable to validate the option range a bit better, and default to the correct value on any error.
> 
> Additional testing:
>   - [x] Eyeballing `GetAndPostTests` debugging, checking that GET/POST are properly enabled/disabled for `false`, `true`, `foobar` passed as option values
>   - [x] `jdk_security`, out of the box
>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=false` passes
>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=foobar` passes

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - test -> client
 - Add another option to GetAndPostTests, check requests in test OSCP server

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18525/files
  - new: https://git.openjdk.org/jdk/pull/18525/files/b1a03e81..606a384b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18525&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18525&range=02-03

  Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18525/head:pull/18525

PR: https://git.openjdk.org/jdk/pull/18525


From shade at openjdk.org  Thu Mar 28 19:48:55 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Mar 2024 19:48:55 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option [v2]
In-Reply-To: <b2G97BOnvNF5Ie-wCd3BzF4TZP-VnQ3uv2JYLqXl5J4=.d3da5745-a09f-47dc-b57a-bd3772c726a3@github.com>
References: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
 <M13kIzDsdTi20_4tKBfvV74J3K5R-qmGb0J_kMNYRR0=.6e0a5b72-b6fd-4687-9b2f-d068ec2bb79a@github.com>
 <9DVJM_gO5S2ml8qwDg4uXGcF-yQFYsAhidlqHonRDFQ=.d18bc353-ba58-41e8-ae8e-23608fa5357b@github.com>
 <Ftmf4EFSZwh9EHO6SJBR76BZJxGjpEouCJBijrdvjEM=.9719e5a7-5280-427c-a698-2a8a9943f616@github.com>
 <b2G97BOnvNF5Ie-wCd3BzF4TZP-VnQ3uv2JYLqXl5J4=.d3da5745-a09f-47dc-b57a-bd3772c726a3@github.com>
Message-ID: <NXbZIfmK4Jy3aGT9mE6mSLkhed2sO-x46X-UjS4K8e4=.8bfc695d-43e2-476c-9f38-bf19db6421ea@github.com>

On Thu, 28 Mar 2024 18:53:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I thought so first too, but decided that `GetPropertyAction` is a better place for it, because it needs the generic `privilegedGetProperty`. It is also adjacent to `privilegedGetTimeoutProp` that returns `int`. Makes sense?
>
> Right, that's a good point because you need to get the string value of the property and not a boolean directly. Ok then.
> 
> For a test, what do you think about adding another @run line to `GetAndPostTest` like:
> 
> `* @run main/othervm -Dcom.sun.security.ocsp.useget=flase GetAndPostTests`
> 
> and also modifying the POST code of test/jdk/java/security/testlibrary/SimpleOCSPServer.java to check that when the request is less than 255 bytes, the system property is set to "false" and nothing else? The server runs in the same process as the test, so I think that should work.
> 
> This would help eliminate the possibility of the property accidentally not working in the future and reverting to GET instead of POST.

This looks easy/safe enough to do. See new commits. New version passes the `GetAndPostTests` and the whole `jdk_security`. For sensitivity test, I broke the option parsing and observed that `GetAndPostTests` fails as expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18525#discussion_r1543552012


From eirbjo at openjdk.org  Thu Mar 28 20:02:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 28 Mar 2024 20:02:35 GMT
Subject: Integrated: 8327779: Remove deprecated internal field
 sun.security.x509.X509Key.key
In-Reply-To: <mldT4vDRBT6DMvgcXy39L2bXT_oWK1nL6khzkGrLqh8=.cd4cfe2e-df0e-4780-b63e-f491aa417671@github.com>
References: <mldT4vDRBT6DMvgcXy39L2bXT_oWK1nL6khzkGrLqh8=.cd4cfe2e-df0e-4780-b63e-f491aa417671@github.com>
Message-ID: <n8gxHabllBJGY7Bz-6-Sfcht0cvhNvGfm9rVR8dIR0k=.5cd94b1e-ad3f-4233-8bab-8a2c32bea58c@github.com>

On Mon, 11 Mar 2024 09:58:42 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes the protected, deprecated field `X509Key.key` in the internal package `sun.security.x509`.
> 
> This field and the associated field `unusedBits` have been marked `@Deprecated` since the initial load. The recommended replacement is to use the `BitArray` representation, which does not require keys to be byte-aligned.
> 
> Two use sites of the `key` field were found in subclasses:
> 
> * The `ECPublicKeyImpl` constructor was updated to use a `BitArray` instead.
> * `ECPublicKeyImpl.parseKeyBits()` was updated to call `getKey().toByteArray()` to produce the byte array.
> 
> Somewhat unrelated, the method `ECPublicKeyImpl.getEncodedPublicValue()` was deemed unused and has been removed.
> 
> Testing and verification: This PR does not update any tests. GHA runs green.

This pull request has now been integrated.

Changeset: 4eefda91
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4eefda91021e07768ace03725c88a56af33ca344
Stats:     55 lines in 2 files changed: 2 ins; 48 del; 5 mod

8327779: Remove deprecated internal field sun.security.x509.X509Key.key

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/18185


From tprinzing at openjdk.org  Fri Mar 29 00:56:46 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Fri, 29 Mar 2024 00:56:46 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
Message-ID: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>

Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.

Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.

Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.

Uses the existing tests.

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

Commit messages:
 - javadoc fixup
 - remove mirrors from JDKEvents
 - 8329138: Convert JFR FileForceEvent to static mirror event

Changes: https://git.openjdk.org/jdk/pull/18542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329138
  Stats: 159 lines in 7 files changed: 123 ins; 30 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542


From alanb at openjdk.org  Fri Mar 29 01:52:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 29 Mar 2024 01:52:35 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <EfqP82wv46tkL-lb7QhMgC748W7wJ0dV5KWNWNHaCNg=.a2b9453a-1d9b-41f5-ac0e-b5bf54d77c48@github.com>

On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

The other two places that should probably emit this event are FileDescriptor.sync and AsynchonrousFileChannel.force.

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

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2026460366


From jwaters at openjdk.org  Fri Mar 29 05:42:48 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 29 Mar 2024 05:42:48 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v10]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <p6LHdyKNHKPY7ospFJklit3PHo9oJfnXDx0ZqY42VO0=.f066e910-53c5-4952-8be9-017d4b933718@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert some changes for now in sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/c0084f23..67887e41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16682&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16682&range=08-09

  Stats: 10 lines in 1 file changed: 3 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16682/head:pull/16682

PR: https://git.openjdk.org/jdk/pull/16682


From jwaters at openjdk.org  Fri Mar 29 05:51:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 29 Mar 2024 05:51:01 GMT
Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi
 [v11]
In-Reply-To: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
References: <eNK6srlACCHCboB3Vye2Mu4XecMp7RAExKiSdRVaol0=.eaf59719-771d-46a0-907d-a7d13420b5be@github.com>
Message-ID: <WwKhOKWt2-BNOXK1fNCe8CNOBCUDGG6ePWeafXgJcxo=.2e08b7f3-3e02-4d96-8974-7212b56ceec4@github.com>

> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Revert some changes in sspi.cpp
 - Revert some changes in sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16682/files
  - new: https://git.openjdk.org/jdk/pull/16682/files/67887e41..cc9992e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16682&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16682&range=09-10

  Stats: 34 lines in 1 file changed: 12 ins; 22 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16682/head:pull/16682

PR: https://git.openjdk.org/jdk/pull/16682


From weijun at openjdk.org  Fri Mar 29 13:04:02 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 29 Mar 2024 13:04:02 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
 [v5]
In-Reply-To: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
Message-ID: <woEOmW6vQq4M3I8lAEYiWQajbZc3kSEkNXeInVfiEqM=.24da5b2c-42fa-4d92-acb3-441a239d6599@github.com>

> Re-implement it as an `Iterator` to make sure it can only be iterated once and make debugger happy.
> 
> No regression, just a refactoring.

Weijun Wang 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 seven additional commits since the last revision:

 - Merge branch 'master' into 8323624
 - Sean's comments
 - Merge branch 'master' into 8323624
 - rename class name
 - use consistent names
 - : iterator
 - the fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17381/files
  - new: https://git.openjdk.org/jdk/pull/17381/files/4cfc4c9b..0b2b49e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17381&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17381&range=03-04

  Stats: 448113 lines in 3896 files changed: 31304 ins; 89900 del; 326909 mod
  Patch: https://git.openjdk.org/jdk/pull/17381.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17381/head:pull/17381

PR: https://git.openjdk.org/jdk/pull/17381


From mullan at openjdk.org  Fri Mar 29 13:18:31 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 29 Mar 2024 13:18:31 GMT
Subject: RFR: 8329213: Better validation for com.sun.security.ocsp.useget
 option [v4]
In-Reply-To: <dhIVNqORCV0eTa13RJ6zMNuCXutL77BxyM3EsqzF5y0=.32c5b44d-0ae1-41dd-9d38-6d472f6a26f0@github.com>
References: <XUgH9UyuhZfZSqnJa6a84e2IpsHV8ezR-wSTjVzgETA=.b8e974b1-2bd2-42f6-a267-18ee57b14325@github.com>
 <dhIVNqORCV0eTa13RJ6zMNuCXutL77BxyM3EsqzF5y0=.32c5b44d-0ae1-41dd-9d38-6d472f6a26f0@github.com>
Message-ID: <272Zh3y8JlEIz1DoG-l2m5mDzf0CtoFY1ceuFPNV7Bc=.49d6e84a-6ddf-4d19-ba07-cc8590d833ca@github.com>

On Thu, 28 Mar 2024 19:48:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8328638](https://bugs.openjdk.org/browse/JDK-8328638) introduced a new boolean option, `com.sun.security.ocsp.useget`. We use the usual `Boolean.parseBoolean` to convert it from String to boolean value, which works correctly for `false` and `true` as boolean values. However, any string that is not `true` would be treated as `false`. Which means that if users mistype the value, they would get a `false`, which is a non-default value, which is against the spirit of the JDK-8328638.
>> 
>> It would be preferable to validate the option range a bit better, and default to the correct value on any error.
>> 
>> Additional testing:
>>   - [x] Eyeballing `GetAndPostTests` debugging, checking that GET/POST are properly enabled/disabled for `false`, `true`, `foobar` passed as option values
>>   - [x] `jdk_security`, out of the box
>>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=false` passes
>>   - [x] `jdk_security` with `-Dcom.sun.security.ocsp.useget=foobar` passes
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - test -> client
>  - Add another option to GetAndPostTests, check requests in test OSCP server

Update copyright date on SimpleOCSPServer. Otherwise, looks good!

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18525#pullrequestreview-1968500798


From mullan at openjdk.org  Fri Mar 29 15:09:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 29 Mar 2024 15:09:45 GMT
Subject: RFR: 8323624: ProviderList.ServiceList does not need to be a list
 [v5]
In-Reply-To: <woEOmW6vQq4M3I8lAEYiWQajbZc3kSEkNXeInVfiEqM=.24da5b2c-42fa-4d92-acb3-441a239d6599@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
 <woEOmW6vQq4M3I8lAEYiWQajbZc3kSEkNXeInVfiEqM=.24da5b2c-42fa-4d92-acb3-441a239d6599@github.com>
Message-ID: <9tBgyd0Jjxofso2Hd8vR4vTwqDDrCBwh0O6lULWVbbI=.716377c0-a654-4832-becc-d6cf9a9ed9ba@github.com>

On Fri, 29 Mar 2024 13:04:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Re-implement it as an `Iterator` to make sure it can only be iterated once and make debugger happy.
>> 
>> No regression, just a refactoring.
>
> Weijun Wang 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8323624
>  - Sean's comments
>  - Merge branch 'master' into 8323624
>  - rename class name
>  - use consistent names
>  - : iterator
>  - the fix

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17381#pullrequestreview-1968728011


From coffeys at openjdk.org  Fri Mar 29 15:09:50 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 29 Mar 2024 15:09:50 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v5]
In-Reply-To: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
Message-ID: <EW_j_bEC4UGEWFmGK_JS44sR5xU5HZUqE2fq0w1-KOI=.b8a1ccae-7223-4e57-be52-d15f5e910c51@github.com>

> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
> 
> examples:
> format without patch :
> 
> 
> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info included:
> 
> 
> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
> 
> 
> format with thread info and timestamp:
> 
> 
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
> 
> 
> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
> 
> current proposal is to keep the thread and timestamp information off (make it opt in)
> 
> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
> 
> e.g 
> 
> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
> 
> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  don't assume option string in args

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18084/files
  - new: https://git.openjdk.org/jdk/pull/18084/files/e88e663b..e8f7021b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18084&range=03-04

  Stats: 21 lines in 2 files changed: 13 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18084/head:pull/18084

PR: https://git.openjdk.org/jdk/pull/18084


From coffeys at openjdk.org  Fri Mar 29 15:14:32 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 29 Mar 2024 15:14:32 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v5]
In-Reply-To: <EW_j_bEC4UGEWFmGK_JS44sR5xU5HZUqE2fq0w1-KOI=.b8a1ccae-7223-4e57-be52-d15f5e910c51@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <EW_j_bEC4UGEWFmGK_JS44sR5xU5HZUqE2fq0w1-KOI=.b8a1ccae-7223-4e57-be52-d15f5e910c51@github.com>
Message-ID: <4O_T4dKjIpD8gCHk5lJYMta4pvchrJvcGmwsoMfi3Do=.f6076402-2bfc-4276-9fa2-05e71b9f8cf2@github.com>

On Fri, 29 Mar 2024 15:09:50 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't assume option string in args

@wangweij found a scenario where the String parsing in the `configureExtras` method may not work as expected. Thanks! Shouldn't assume that option String is contained in `args` String -- "`all`" value has special treatment.

Method patched and test coverage updated

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

PR Comment: https://git.openjdk.org/jdk/pull/18084#issuecomment-2027366963


From weijun at openjdk.org  Fri Mar 29 15:26:48 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 29 Mar 2024 15:26:48 GMT
Subject: Integrated: 8323624: ProviderList.ServiceList does not need to be a
 list
In-Reply-To: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
References: <ud-OsiM043AOih39Kz6g1zEgZ5_NxNKge_xfCFE3DGI=.71ca33ee-d3b7-4c20-96ce-ad2b06cde077@github.com>
Message-ID: <2KFDPx848wr8w3APOUvYMwqZDh41Z_tCK5O7uvP5EaE=.48d90f90-d609-49a7-995b-2c3893e9da4e@github.com>

On Thu, 11 Jan 2024 22:06:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Re-implement it as an `Iterator` to make sure it can only be iterated once and make debugger happy.
> 
> No regression, just a refactoring.

This pull request has now been integrated.

Changeset: 59c2aff1
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/59c2aff1edffb66762bbbe5e310913f87953be5b
Stats:     144 lines in 12 files changed: 15 ins; 76 del; 53 mod

8323624: ProviderList.ServiceList does not need to be a list

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/17381


From weijun at openjdk.org  Fri Mar 29 15:55:33 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 29 Mar 2024 15:55:33 GMT
Subject: RFR: 8051959: Add thread and timestamp options to
 java.security.debug system property [v5]
In-Reply-To: <EW_j_bEC4UGEWFmGK_JS44sR5xU5HZUqE2fq0w1-KOI=.b8a1ccae-7223-4e57-be52-d15f5e910c51@github.com>
References: <TYWJTP9Zd6Yt6Hv_QJ2ABfNuhYRQoOgK1cjkn2wcNCA=.cf566364-f19c-4ec7-922c-c122f7bdf273@github.com>
 <EW_j_bEC4UGEWFmGK_JS44sR5xU5HZUqE2fq0w1-KOI=.b8a1ccae-7223-4e57-be52-d15f5e910c51@github.com>
Message-ID: <sPSL2AE3k58GpzM9kPDj3HNn4IiNymlkOoSV_uq9bQ8=.8587511d-27ec-4d56-84a4-dfa097d31bea@github.com>

On Fri, 29 Mar 2024 15:09:50 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Proposal to improve the `java.security.debug` output so that options exist to add thread ID, thread name, source of log record and a timestamp information to the output.
>> 
>> examples:
>> format without patch :
>> 
>> 
>> properties: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info included:
>> 
>> 
>> properties[10|main|Security.java:122]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122]: Initial security property: krb5.kdc.bad.policy=tryLast 
>> keystore[10|main|KeyStoreDelegator.java:216]: Creating a new keystore in PKCS12 format
>> 
>> 
>> format with thread info and timestamp:
>> 
>> 
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[10|main|Security.java:122|2024-03-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> It's a similar format to what can be seen when the TLS (javax.net.debug) debug logging option is in use
>> 
>> current proposal is to keep the thread and timestamp information off (make it opt in)
>> 
>> The extra decorator info is controlled by appending option to each component specified in the `"java.security.debug"` option list.
>> 
>> e.g 
>> 
>> `-Djava.security.debug=properties+timestamp+thread` turns on logging for the `properties` component and also decorates the records with timestamp and thread info
>> 
>> -Djava.security.debug=properties+thread+timestamp,keystore would decorate the `properties` component but no decorating performed for the `keystore `component.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't assume option string in args

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18084#pullrequestreview-1968855163


From djelinski at openjdk.org  Fri Mar 29 19:54:34 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 29 Mar 2024 19:54:34 GMT
Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and
 X509KeyManagerImpl [v3]
In-Reply-To: <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
References: <TMoSmYyTbqalRQQRPX2RRVFCILhiAMAZ2sVjq2foQCg=.e6bd7928-23ba-4db3-9102-80eec0c0eb73@github.com>
 <DGMzR-YvltPuhLdeh1jGCfFHJw9k2AY_yNN1eLobXXI=.b3879bef-8e4c-438b-b3ea-837361ab1908@github.com>
Message-ID: <7GF7BIFZ1RjIVIrjrPkcaPalctazjOkq2y60xhtym9c=.6235b250-9432-4902-8e0a-3c5bfb11bb68@github.com>

On Tue, 26 Mar 2024 06:00:33 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> For the PKIX KeyManager and PKCS12 Keystore, when the TLS server sends the ServerHello message and ultimately calls the X509KeyManagerImpl.chooseEngineServerAlias() method, it retrieves the private key from the keystore, decrypts it, and caches both the key and its certificate. This caching currently occurs only during a single handshake. Since decryption can be time-consuming, a modification has been implemented to cache the keystore entries at initialization time. This way, it won't be necessary to retrieve and decrypt the keys for multiple handshakes, which could lead to performance drawbacks.
>> 
>> A change was made to also update/refresh the cached entry as the certificates in the PKCS12 keystore may change, for scenarios like when the certificate expires and a new one is added under a different alias, and the certificate chain returned by the PKCS12 keystore is not the same as the one in the cache. While attempting to handle when to refresh a cached entry to accommodate keystore changes, we would like to know if you agree that this improvement is worth the risk. We would also like to know if you have a preference for other options:
>> 
>> 1. Accept that PKIX+PKCS12 is slow.
>> 2. Add a configuration option (system property, maybe) to decide the level of caching (1 - same as the existing one, 2 - same caching as in SunX509KeyManagerImpl, 3 - the new caching introduced in this change).
>> 
>> Additionally, the benchmark test SSLHandshake.java is modified to include a @Param annotation, allowing it to pass different KeyManagerFactory values (SunX509 and PKIX) to the benchmark method.
>> 
>> Running modified SSLHandshake.java test prior to the change that caches the PKCS12 keystore entries for PKIX:
>> Benchmark                 (keyMgr)  (resume)  (tlsVersion)   Mode  Cnt     Score     Error  Units
>> SSLHandshake.doHandshake   SunX509      true       TLSv1.2  thrpt   15  9346.292 ? 379.023  ops/s
>> SSLHandshake.doHandshake   SunX509      true           TLS  thrpt   15   940.175 ?  21.215  ops/s
>> SSLHandshake.doHandshake   SunX509     false       TLSv1.2  thrpt   15   594.418 ?  23.374  ops/s
>> SSLHandshake.doHandshake   SunX509     false           TLS  thrpt   15   534.030 ?  16.709  ops/s
>> SSLHandshake.doHandshake      PKIX      true       TLSv1.2  thrpt   15  9359.086 ? 246.257  ops/s
>> SSLHandshake.doHandshake      PKIX      true           TLS  thrpt   15   933.835 ?  81.388  ops/s
>> SSLHandshake.doHandshake      PKIX     false       TLSv1.2  thrpt   15   ...
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with John's comments

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 82:

> 80:     private final Map<String,Reference<PrivateKeyEntry>> entryCacheMap;
> 81: 
> 82:     private final boolean ksP12;

Can we improve this name? Something like "cachePrivateKeys" would better describe the purpose

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 112:

> 110:                 KeyStore keyStore = builder.getKeyStore();
> 111:                 String ksType = keyStore.getType();
> 112:                 if (ksType.equalsIgnoreCase("pkcs12")) {

I think we also need to check the provider; other providers might also implement PKCS12 key store type, and we don't know if we can trust their `getEntry` to return consistent data

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 113:

> 111:                 String ksType = keyStore.getType();
> 112:                 if (ksType.equalsIgnoreCase("pkcs12")) {
> 113:                     foundPKCS12 = true;

this will enable caching if _any_ of the keystores is PKCS12; we should only enable caching when _all_ keystores are PKCS12

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1544815889
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1544818679
PR Review Comment: https://git.openjdk.org/jdk/pull/17956#discussion_r1544818184


From tprinzing at openjdk.org  Fri Mar 29 20:51:31 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Fri, 29 Mar 2024 20:51:31 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <u2efcIPGCJXkSOQMCdqOT3LVLRqW42S-uRuMcwVoPPs=.2975a724-467c-4b62-852a-691b07bfe2d9@github.com>

On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

Okay, I'll update those two places to emit the event.  It looks like adding a file descriptor property to the event is needed, and there would be no file path in those cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2027722419


From alanb at openjdk.org  Sat Mar 30 10:08:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 30 Mar 2024 10:08:30 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <5WxpEWPgGFA1cNFyaD0ww5qSGnC1a1axgcgzBcH22CA=.6b54905a-92fd-4d2c-84cf-ffabd88be2c0@github.com>

On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

> It looks like adding a file descriptor property to the event is needed, and there would be no file path in those cases.

The AsynchonrousFileChannel implementations can keep a reference to the file path, that should be easy. FileDescriptor.sync does need more thought, maybe it's not worth doing.

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

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2028000449