Re: RFR: 8341346: Add support for exporting TLS Keying Material [v11]

2025-05-12 Thread Bradford Wetmore
> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE > respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK > API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net > jck:api/javax_security jck:ap

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v12]

2025-05-12 Thread Bradford Wetmore
> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE > respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK > API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net > jck:api/javax_security jck:ap

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v10]

2025-05-12 Thread Bradford Wetmore
On Mon, 12 May 2025 14:58:07 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains 13 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Adjustments made for JDK-8350830 >> - Merg

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v10]

2025-05-12 Thread Bradford Wetmore
On Mon, 12 May 2025 15:07:20 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains 13 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Adjustments made for JDK-8350830 >> - Merg

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v10]

2025-05-12 Thread Bradford Wetmore
On Mon, 12 May 2025 15:02:31 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains 13 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Adjustments made for JDK-8350830 >> - Merg

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v10]

2025-05-12 Thread Bradford Wetmore
On Sat, 10 May 2025 13:48:05 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains 13 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Adjustments made for JDK-8350830 >> - Merg

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v10]

2025-05-12 Thread Bradford Wetmore
On Mon, 12 May 2025 14:45:36 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains 13 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Adjustments made for JDK-8350830 >> - Merg

Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3]

2025-05-12 Thread Hai-May Chao
On Mon, 12 May 2025 20:05:18 GMT, Artur Barashev wrote: >> When the deafult SunX509KeyManagerImpl is being used we are in violation of >> TLSv1.3 RFC spec because we ignore peer supported certificate signatures >> sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions: >> h

Re: RFR: 8356644: Update encoding declaration to UTF-8

2025-05-12 Thread Sergey Bylokhov
On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote: > A handful of html and xml files in the JDK source tree claims to have > encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. > > While perhaps technically correct, this is misleading, and goes contrary to > the eff

Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3]

2025-05-12 Thread Artur Barashev
> When the deafult SunX509KeyManagerImpl is being used we are in violation of > TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent > to us in "signature_algorithms"/"signature_algorithms_cert" extensions: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 >

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v6]

2025-05-12 Thread Volkan Yazici
> `ServerUdsChannelHolder` is introduced to manage the life cycle of a > `ServerSocketChannel` created using Unix domain sockets (UDS) in a > thread-safe manner. > > ### Testing > > Changes can be tested as follows: > > > make build-microbenchmark > build/linux-x64/jdk/bin/java \ > -jar bui

Re: RFR: 8355360: -d option of jwebserver command should accept relative paths [v4]

2025-05-12 Thread duke
On Fri, 9 May 2025 09:53:08 GMT, Volkan Yazici wrote: >> Allows relative paths in the content root directory passed to the >> `jwebserver`. Changes effect both the `jwebserver` executable and the `java >> -m jdk.httpserver` execution. >> >> ### Implementation notes >> >> Received `Path` is re

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v4]

2025-05-12 Thread Volkan Yazici
On Mon, 12 May 2025 15:25:54 GMT, Michael McMahon wrote: >> Volkan Yazici has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Improve UDS file path obtain > > test/micro/org/openjdk/bench/java/net/SocketChannelConnectionSetup.java line > 58

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v5]

2025-05-12 Thread Volkan Yazici
> `ServerUdsChannelHolder` is introduced to manage the life cycle of a > `ServerSocketChannel` created using Unix domain sockets (UDS) in a > thread-safe manner. > > ### Testing > > Changes can be tested as follows: > > > make build-microbenchmark > build/linux-x64/jdk/bin/java \ > -jar bui

Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v2]

2025-05-12 Thread Artur Barashev
> When the deafult SunX509KeyManagerImpl is being used we are in violation of > TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent > to us in "signature_algorithms"/"signature_algorithms_cert" extensions: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 >

Integrated: 8353642: Deprecate URL::getPermission method and networking permission classes for removal

2025-05-12 Thread Daniel Fuchs
On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs wrote: > Please find her a patch that deprecate networking permission classes for > removal. The method `URL::getPermission` now serves little purpose and is > also deprecated. That method was overridden in subclasses and specified to > return so

Re: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v4]

2025-05-12 Thread Sean Mullan
On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs wrote: >> Please find her a patch that deprecate networking permission classes for >> removal. The method `URL::getPermission` now serves little purpose and is >> also deprecated. That method was overridden in subclasses and specified to >> return

Re: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v4]

2025-05-12 Thread Sean Mullan
On Mon, 12 May 2025 15:21:46 GMT, Daniel Fuchs wrote: >> Ah - good point - I will double check. > > Yes - it is needed as well. Apparently if you override a deprecated method > you need both `@Deprecated` and `@SuppressWarning`: > > > src/java.base/share/classes/java/net/HttpURLConnection.java

RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager

2025-05-12 Thread Artur Barashev
When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions: https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 https://d

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v4]

2025-05-12 Thread Michael McMahon
On Mon, 12 May 2025 11:26:30 GMT, Volkan Yazici wrote: >> `ServerUdsChannelHolder` is introduced to manage the life cycle of a >> `ServerSocketChannel` created using Unix domain sockets (UDS) in a >> thread-safe manner. >> >> ### Testing >> >> Changes can be tested as follows: >> >> >> make

Re: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v4]

2025-05-12 Thread Daniel Fuchs
On Fri, 9 May 2025 19:19:03 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/HttpURLConnection.java line 615: >> >>> 613: */ >>> 614: @Deprecated(since = "25", forRemoval = true) >>> 615: @SuppressWarnings("removal") >> >> Do you still need this annotation now that

Re: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v4]

2025-05-12 Thread Daniel Fuchs
On Fri, 9 May 2025 19:18:58 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java >> line 214: >> >>> 212: */ >>> 213: @Override >>> 214: @Deprecated(since = "25", forRemoval = true) >> >> Is this annotation required or more as a

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v10]

2025-05-12 Thread Sean Mullan
On Fri, 9 May 2025 21:38:07 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE >> respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK >> API (jck:api/java_security jck:a

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v4]

2025-05-12 Thread Volkan Yazici
> `ServerUdsChannelHolder` is introduced to manage the life cycle of a > `ServerSocketChannel` created using Unix domain sockets (UDS) in a > thread-safe manner. > > ### Testing > > Changes can be tested as follows: > > > make build-microbenchmark > build/linux-x64/jdk/bin/java \ > -jar bui

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v2]

2025-05-12 Thread Volkan Yazici
On Mon, 12 May 2025 07:41:01 GMT, Volkan Yazici wrote: >> What about just doing `bind(null)`? This will create all the socket files >> with unique names in the system temp directory. Since no sub-directory is >> being created, there can't be a race trying to delete it. >> >> Or maybe this is w

Re: RFR: 8355360: -d option of jwebserver command should accept relative paths [v4]

2025-05-12 Thread Volkan Yazici
On Fri, 9 May 2025 15:28:44 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Fix license year >> - Move path resolution back to option parsing > > Sorry - I have approved too fast - aren't ther

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v2]

2025-05-12 Thread Volkan Yazici
On Fri, 9 May 2025 13:01:20 GMT, Michael McMahon wrote: >>> It's not clear to me why each `ServerSocketChannel` needs a separate >>> temporary directory for its socket file. >> >> Each JMH thread needs its own socket file. If we share the socket file >> folder, the following operations become

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v3]

2025-05-12 Thread Volkan Yazici
> `ServerUdsChannelHolder` is introduced to manage the life cycle of a > `ServerSocketChannel` created using Unix domain sockets (UDS) in a > thread-safe manner. > > ### Testing > > Changes can be tested as follows: > > > make build-microbenchmark > build/linux-x64/jdk/bin/java \ > -jar bui