Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server [v20]

2024-10-18 Thread Artur Barashev
On Fri, 18 Oct 2024 04:37:46 GMT, Xue-Lei Andrew Fan wrote: > > We want to address just this particular issue and not to cause any > > collateral damage by simplifying things. For example: if plaintext alert > > comes after handshake we want to throw an exception. > > I think I have a better s

Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server [v20]

2024-10-18 Thread Artur Barashev
On Fri, 18 Oct 2024 00:38:06 GMT, Bradford Wetmore wrote: >> Artur Barashev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Adjust line length > > test/jdk/javax/net/ssl/TLSv13/SSLEngineNoServerHelloClientShutdown.java line > 1: > >> 1

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Eirik Bjørsnøs
> Please review this PR which speeds up `JarFile::getEntry` lookup > significantly for multi-release JAR files. > > The changes in this PR are motivated by the following insights: > > * `META-INF/versions/` is sparsely populated. > * Most entries are not versioned > * The number of unique versio

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Claes Redestad
On Fri, 18 Oct 2024 12:08:08 GMT, Eirik Bjørsnøs wrote: >> There are a few possible strategies for avoiding that additional parse, >> since the effect we're getting at here is to have a quick filter to avoid >> pointless lookups and not necessarily an exact mapping. >> >> One is to store the `

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Eirik Bjørsnøs
On Fri, 18 Oct 2024 10:04:55 GMT, Claes Redestad wrote: > One is to store the `checkedHash` rather than the full `String`. This gets > `openCloseZipFile` down to ~91 ns/op. (`checkedHash` very hot in > profiles). There's still a chance for redundant lookups on hash collisions, > but this s

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Claes Redestad
On Fri, 18 Oct 2024 12:34:18 GMT, Claes Redestad wrote: >>> One is to store the `checkedHash` rather than the full `String`. This gets >>> `openCloseZipFile` down to ~91 ns/op. (`checkedHash` very hot in >>> profiles). There's still a chance for redundant lookups on hash collisions, >>> bu

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Claes Redestad
On Fri, 18 Oct 2024 13:54:30 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which speeds up `JarFile::getEntry` lookup >> significantly for multi-release JAR files. >> >> The changes in this PR are motivated by the following insights: >> >> * `META-INF/versions/` is sparsely populated. >>

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Claes Redestad
On Fri, 18 Oct 2024 09:31:45 GMT, Eirik Bjørsnøs wrote: >> With this change to `ZipFileOpen`: >> >> diff --git a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java >> b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java >> index 4f6ae6373ec..0e22cf7f0ab 100644 >> --- a/test/m

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Sean Mullan
> This is the implementation of JEP 486: Permanently Disable the Security > Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The > [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the > main changes in the JEP and also includes an apidiff of the specif

Re: RFD: Security Providers Filter (JEP)

2024-10-18 Thread Martin Balao
Hello Sean, On 9/19/24 12:00, Sean Mullan wrote: Hi Martin, Our team at Oracle has done another review of the proposed feature and we have some questions that we would like to discuss below. This is a significant effort that would add some valuable features to the Security Provider mechanis

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Eirik Bjørsnøs
On Fri, 18 Oct 2024 09:23:17 GMT, Claes Redestad wrote: > I suspect remaining regression is mostly from the added `String` > creation/processing in `initCEN`. Yes, there is a cost with the String construction when parsing the name out of `META-INF/versions/{name}` - PR Review Com

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Chen Liang
On Fri, 18 Oct 2024 13:59:32 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which speeds up `JarFile::getEntry` lookup >> significantly for multi-release JAR files. >> >> The changes in this PR are motivated by the following insights: >> >> * `META-INF/versions/` is sparsely populated. >>

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Kevin Walls
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8336665: CCE in X509CRLImpl$TBSCertList.getCertIssuer [v4]

2024-10-18 Thread Sean Mullan
On Tue, 8 Oct 2024 15:32:55 GMT, Mark Powers wrote: >> Fixed. > > Does the test need to be modified to test for more than one name? I could go > either way. Are you able to easily create test CRLs with more than one entry? If not, I think the existing test is ok. - PR Review Comm

RFR: 8317538: access to shared variable was removed

2024-10-18 Thread Vladimir Ivanov
To fix scalability issue usage of the shared variable was removed. According to specjvm2008::crypto.rsa workload one thread performance drop for less than 1% while score for the 224 threads increased in ~2 times. Numbers for my run on 2 socket server with the Xeon 8480+ looks as: 1 thread runs: s

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Claes Redestad
On Thu, 17 Oct 2024 22:32:12 GMT, Claes Redestad wrote: >>> I guess performance leans on there being only one or a small number of >>> versions per entry. >> >> I checked Spring Petclinic: >> >> * 109 JAR dependencies >> * 15 are multi-release enabled. >> * The 15 MR-JARs have 9347 entries, o

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Eirik Bjørsnøs
On Fri, 18 Oct 2024 15:43:18 GMT, Chen Liang wrote: >> Eirik Bjørsnøs has updated the pull request incrementally with four >> additional commits since the last revision: >> >> - Map versions by entry name hashcode instead of by entry name. This avoids >> String allocation and storage >> - Me

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Sean Mullan
On Tue, 15 Oct 2024 17:01:59 GMT, Sean Mullan wrote: >>> While making `LogManager.checkAccess` be a no-op might be more convenient, >>> it could unconditionally permit operations that formerly required a >>> permission check: clearly a bad idea. Always throwing a `SecurityException` >>> is the

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Sean Mullan
On Wed, 16 Oct 2024 20:42:11 GMT, Sean Mullan wrote: >> The description for the SecurityException thrown by these methods were >> adjusted to "if access to the screen is denied by desktop environment". If >> you bring back the paragraphs that were removed then you might have to >> adjust the w

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Sean Mullan
On Thu, 17 Oct 2024 05:54:24 GMT, Alan Bateman wrote: >> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` >> instead. > > Okay, it already has `@see StackWalker`. My guess is that anything extending > SM to call getClassContext is very old code. If that old code is comp

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Sean Mullan
On Tue, 15 Oct 2024 14:50:54 GMT, Daniel Fuchs wrote: >> Sean Mullan has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 97 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Change apiNote to d

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Sean Mullan
On Tue, 15 Oct 2024 22:14:00 GMT, Sean Mullan wrote: >> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java >> line 225: >> >>> 223: */ >>> 224: public static JMXConnector connect(JMXServiceURL serviceURL) >>> 225: throws IOException { >> >>

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread David M . Lloyd
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v62]

2024-10-18 Thread Kevin Driver
> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic > algorithms for deriving additional keys from a secret key and other data. See > [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-18 Thread Sean Mullan
On Thu, 17 Oct 2024 17:59:20 GMT, Sean Mullan wrote: >> All JGSS permission classes follow the same style: >> >> In `javax.security.auth.kerberos.DelegationPermission`: >> >> * This class is used to restrict the usage of the Kerberos >> * delegation model, ie: forwardable and proxiable ticket

Re: RFR: 8336665: CCE in X509CRLImpl$TBSCertList.getCertIssuer [v5]

2024-10-18 Thread Sean Mullan
On Tue, 8 Oct 2024 15:32:19 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8336665 > > Mark Powers has updated the pull request incrementally with one additional > commit since the last revision: > > allow more than one name src/java.base/share/classes/sun/security/x509/X509C

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

2024-10-18 Thread Eirik Bjørsnøs
On Fri, 18 Oct 2024 13:41:55 GMT, Claes Redestad wrote: >> Eirik Bjørsnøs has updated the pull request incrementally with four >> additional commits since the last revision: >> >> - Map versions by entry name hashcode instead of by entry name. This avoids >> String allocation and storage >>

Re: RFR: 8298420: PEM API: Implementation (Preview) [v8]

2024-10-18 Thread Michael Osipov
On Thu, 17 Oct 2024 16:24:02 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a >> format for encoding and decoding cryptographic keys and certificates. It >> will be integrated into JDK24 as a Preview Feature. Preview featur

Re: RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v2]

2024-10-18 Thread Eirik Bjørsnøs
On Mon, 14 Oct 2024 19:50:45 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which speeds up `JarFile::getEntry` lookup >> significantly for multi-release JAR files. >> >> The changes in this PR are motivated by the following insights: >> >> * `META-INF/versions/` is sparsely populated. >>