From duke at openjdk.org  Mon Dec  1 00:38:50 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Mon, 1 Dec 2025 00:38:50 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v8]
In-Reply-To: <RiOeacWUGk8YrEXhlpXuNefZATD-vIh5_U_hFdIYBmI=.3d25a9bb-503f-4f18-a5a9-4548f48d4ae5@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <2HwG7uFrqW7pXzu32WvTuOZmzolIhPS8TxoZazYsvG8=.a75ab9bf-8587-4e35-82a2-88b7e8aa44da@github.com>
 <RiOeacWUGk8YrEXhlpXuNefZATD-vIh5_U_hFdIYBmI=.3d25a9bb-503f-4f18-a5a9-4548f48d4ae5@github.com>
Message-ID: <CUdae5s-R_OJzw5w9FK2988YEJbR8Osew0zNYgDyupo=.87505d51-486f-4a06-bd85-3de4af30d441@github.com>

On Mon, 24 Nov 2025 17:24:50 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed the ENCRYPT_16_BLKS fall through case that sviswa7 pointed out in PR review.
>
> Marked as reviewed by sviswanathan (Reviewer).

@sviswa7 or @shipilev, if the updated changes look good to you then could you please reapprove/approve the PR as I don't have Reviewer privileges at this point.

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

PR Comment: https://git.openjdk.org/jdk/pull/28363#issuecomment-3594057961

From shade at openjdk.org  Mon Dec  1 07:54:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Dec 2025 07:54:03 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v10]
In-Reply-To: <cbgcZOlm-8SgDVFjLxcZoki5kqR9L7UqWG9IYcux2dw=.b99e999e-3cef-488e-a68c-64a31f30257d@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <cbgcZOlm-8SgDVFjLxcZoki5kqR9L7UqWG9IYcux2dw=.b99e999e-3cef-488e-a68c-64a31f30257d@github.com>
Message-ID: <LUrD4KfHO-GjXh3VRKU4UpXtbfhX-VHB4PadSnjserk=.c658a8d5-d766-45de-9887-dc1170b0272f@github.com>

On Fri, 28 Nov 2025 06:01:26 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
>> 
>> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to break before operators.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28363#pullrequestreview-3523605119

From myankelevich at openjdk.org  Mon Dec  1 07:55:02 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 1 Dec 2025 07:55:02 GMT
Subject: Integrated: 8365861: test/jdk/sun/security/pkcs11/Provider/ tests
 skipped without SkippedException
In-Reply-To: <Gz2_zX8dMTJ3SEOVZ2k8YfkqueUZk_ISkjl8SGEHGgc=.377a6dc0-5b9b-44bb-bb22-84a6a7128788@github.com>
References: <Gz2_zX8dMTJ3SEOVZ2k8YfkqueUZk_ISkjl8SGEHGgc=.377a6dc0-5b9b-44bb-bb22-84a6a7128788@github.com>
Message-ID: <3wTwOohEzKHtHQgiY4h1vlxujgRh1MSChPj_zoEfsUs=.20bdc2bb-2378-48dd-b179-d8e9950ab272@github.com>

On Wed, 20 Aug 2025 14:58:44 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> * test/jdk/sun/security/pkcs11/Provider/ tests skipped without SkippedException:
>   - test/jdk/sun/security/pkcs11/Provider/LoginISE.java 
>   - test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java
>   - test/jdk/sun/security/pkcs11/Provider/Absolute.java
> * cleanup

This pull request has now been integrated.

Changeset: 969eb1ce
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/969eb1ce2419324582ee8d8108031323f82e125e
Stats:     32 lines in 3 files changed: 14 ins; 3 del; 15 mod

8365861: test/jdk/sun/security/pkcs11/Provider/ tests skipped without SkippedException

Reviewed-by: rhalade

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

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

From mdoerr at openjdk.org  Mon Dec  1 10:27:36 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 1 Dec 2025 10:27:36 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v7]
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

Martin Doerr 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 nine additional commits since the last revision:

 - Minor simplification.
 - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
 - Fix missing whitespace.
 - Address review comments.
 - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
 - Remove K from AES_Crypt
 - More minor cleanup.
 - Improve comment and minor cleanup.
 - 8371820: Further AES performance improvements for key schedule generation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28299/files
  - new: https://git.openjdk.org/jdk/pull/28299/files/ae84912d..c7107a70

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

  Stats: 17426 lines in 467 files changed: 10903 ins; 3977 del; 2546 mod
  Patch: https://git.openjdk.org/jdk/pull/28299.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28299/head:pull/28299

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

From djelinski at openjdk.org  Mon Dec  1 11:03:15 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Dec 2025 11:03:15 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v7]
In-Reply-To: <DTog6sfC8efnL2ysENz2zRAVGWNuGZ7hfE8mxrwP1vo=.dcf5fc1f-9188-4fd4-a2c2-e0930d2c257d@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <DTog6sfC8efnL2ysENz2zRAVGWNuGZ7hfE8mxrwP1vo=.dcf5fc1f-9188-4fd4-a2c2-e0930d2c257d@github.com>
Message-ID: <Q15PCCegrjbDS-CKa2jsyLoOeaAyvKLV3a5018Deb9g=.70160d1c-2168-4cbe-aa05-45569271111c@github.com>

On Mon, 24 Nov 2025 17:22:39 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan 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 13 additional commits since the last revision:
> 
>  - Updated IPAddressDNSIdentities and confirmed test fails for correct reason
>  - Merge branch 'master' into update-md5-certs
>  - Updated SAN methods in CertificateBuilder to take multiple names
>  - Merge branch 'master' into update-md5-certs
>  - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
>  - removed unused keystore files, fixed certificate chain
>  - Merge branch 'master' into update-md5-certs
>  - changed line wrapping
>  - removed unnecessary comment and made getSSLContext(...) private
>  - changed tests to use SecurityUtils.removeDisabled*Algs methods
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d0629285...ea9c2dce

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3524380076

From coffeys at openjdk.org  Mon Dec  1 11:27:50 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 1 Dec 2025 11:27:50 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v2]
In-Reply-To: <bmi5laEV_xFJN5GCTfyjDVg04BlgYbnSE85NA8Fq_X8=.e50b7f0a-bc57-41c7-aaf9-4089c3e3cbfc@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <zVGXB-bfjOycUAhnNo_37Cvoj-6YPCxB_780AlHzYPw=.a3698f36-5bfc-4986-973d-228b48579a00@github.com>
 <H-DLOGq_flBI4X77A32JJsCyS7RpV4C4g8XsLp95J_Q=.9329638a-9423-4a0b-a2fd-a04e8dd6fc75@github.com>
 <bmi5laEV_xFJN5GCTfyjDVg04BlgYbnSE85NA8Fq_X8=.e50b7f0a-bc57-41c7-aaf9-4089c3e3cbfc@github.com>
Message-ID: <d5TrZnFPOiEYs0EjzvsUwbl3UNMST1bOxd5gPXxKvVQ=.00379de5-19cd-4063-a9d2-9798337e8bec@github.com>

On Wed, 26 Nov 2025 21:38:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 101:
>> 
>>> 99:         serverValidator = v;
>>> 100: 
>>> 101:         if (SSLLogger.isOn() && SSLLogger.isOn("ssl,trustmanager")) {
>> 
>> One benefit of the older style log call was that we got c2 inlining and some deadcode elimination in various security methods if the SSLLogger was off.  i.e. if `SSLLogger.isOn()` was proven to always be false, then c2 could remove such code paths.  The new `logFine` type calls bring one extra level of method reference but it might be worth confirming that c2 is able to inline such calls and perform dead code elimination also.
>
> I see, how do I confirm that then? I followed the example of `logWarning` method which was added earlier. It's more convenient way to log than current `if` condition approach.

I guess you've a few options to measure. One is `hsdis` tool. An easier approach is a jmh benchmark. I put a simple example together below. I think the performance will be similar/on-par with this design (tested with TLS logging disabled) but it does highlight a possible pitfall for future iterations of this code. The String and params passed to the new method are calculated even before checking to see if logging is enabled. For an expensive string calculation, that'll add cycles. see `testLogProposed` Benchmark. A Supplier type API might be useful in future versions.


Benchmark                                  (numStrings)  Mode  Cnt    Score    Error  Units
SSLLoggerTest.testLogCurrent                          1  avgt    5    0.391 ?  0.027  ns/op
SSLLoggerTest.testLogCurrent                         10  avgt    5    0.391 ?  0.021  ns/op
SSLLoggerTest.testLogProposed                         1  avgt    5   64.012 ?  8.939  ns/op
SSLLoggerTest.testLogProposed                        10  avgt    5  242.656 ? 22.269  ns/op
SSLLoggerTest.testLogProposedSimpleString             1  avgt    5    0.386 ?  0.016  ns/op
SSLLoggerTest.testLogProposedSimpleString            10  avgt    5    0.389 ?  0.021  ns/op
Finished running test 'micro:sun.security.ssl.SSLLoggerTest'


JMH src:


package org.openjdk.bench.sun.security.ssl;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.Param;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;

import java.util.concurrent.TimeUnit;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

import sun.security.ssl.SSLLogger;

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Thread)
@Fork(value = 1, jvmArgs = {"--add-exports", "java.base/sun.security.ssl=ALL-UNNAMED"})
public class SSLLoggerTest {

    @Param({"1", "10"})
    private int numStrings;

    @Benchmark
    public void testLogCurrent() {
        if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
            SSLLogger.info(createMessage(numStrings));
        }
    }

    @Benchmark
    public void testLogProposed() {
        SSLLogger.logFine("ssl,handshake", createMessage(numStrings));
    }

    @Benchmark
    public void testLogProposedSimpleString() {
        SSLLogger.logFine("ssl,handshake", "Test String Logging Call");
    }

    private static String createMessage(int numStrings) {
        return IntStream.range(0, numStrings).mapToObj(i -> { return "test" + i; }).collect(Collectors.toList()).toString();
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2576686296

From smonteith at openjdk.org  Mon Dec  1 12:07:02 2025
From: smonteith at openjdk.org (Stuart Monteith)
Date: Mon, 1 Dec 2025 12:07:02 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
Message-ID: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>

MemorySegments allocated from shared Arena from
java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.

The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .

The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.

| Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
|---------|-------|-------|-------|-------|-------|-------|
|    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
|   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
|  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
|  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
|   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
|  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
|   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
|   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |

After:

| Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
|---------|-------|-------|-------|-------|-------|-------|
|    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
|    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
|    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
|    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |    16.52 |
|   16 |     70.15 |     47.76 |     52.37 |   47.26 |     70.91 |     14.53 |
|   24 |     77.38 |     78.14 |     81.67 |   71.98 |     87.20  |    21.70 |
|   32 |     87.54 |     98.01 |     84.73 |   86.79 |    109.25  |    22.65 |
|   48 |    121.54|     128.14  |   120.51 |  104.35 |    175.08 |     26.85 |

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

Commit messages:
 - 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas

Changes: https://git.openjdk.org/jdk/pull/28575/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28575&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371260
  Stats: 628 lines in 33 files changed: 402 ins; 38 del; 188 mod
  Patch: https://git.openjdk.org/jdk/pull/28575.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28575/head:pull/28575

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

From mdonovan at openjdk.org  Mon Dec  1 12:21:04 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 1 Dec 2025 12:21:04 GMT
Subject: Integrated: 8353738: Update TLS unit tests to not use certificates
 with MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <KiVDvQMrcUC7gXrOaTXnGTgkn39UhSTGczGfyPrlU0Q=.4b6c2f93-e61a-4a58-883a-7501554ac7b8@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

This pull request has now been integrated.

Changeset: f5eecc45
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5eecc454eb78fc1a3714dfe3cb94113238dd3ac
Stats:     3481 lines in 14 files changed: 402 ins; 2957 del; 122 mod

8353738: Update TLS unit tests to not use certificates with MD5 signatures

Reviewed-by: djelinski, abarashev

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

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

From myankelevich at openjdk.org  Mon Dec  1 12:36:52 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 1 Dec 2025 12:36:52 GMT
Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass
 when they should skip [v4]
In-Reply-To: <RB9RIr2jh513zd-qdiXnBedXHJIi5fMlw1hEY-DfPI8=.8f40faa5-bcd8-4db5-bbbc-cbfd89b18926@github.com>
References: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
 <cZ4PMYo0FpEddQsTwVqDrAu1-nDYzePE0vIMNXfrZrU=.a761242e-4e5a-4b79-aa05-296994da658f@github.com>
 <RB9RIr2jh513zd-qdiXnBedXHJIi5fMlw1hEY-DfPI8=.8f40faa5-bcd8-4db5-bbbc-cbfd89b18926@github.com>
Message-ID: <b9l1VEA0PrcyEnbjA9IXxfibibgp6qMIsBripzM3mO8=.54a57ab9-3db6-4214-b74c-a3a38a3d35f2@github.com>

On Fri, 21 Nov 2025 18:42:45 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Mikhail Yankelevich 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:
>> 
>>  - skip reworked
>>  - Merge branch 'master' into JDK-8367994
>>  - name changes for arrays
>>  - renamed  id
>>  - JDK-8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip
>
> Changes requested by rhalade (Reviewer).

@rhalade Thanks for noticing, missed this one. Will be fixed in the next commit

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

PR Comment: https://git.openjdk.org/jdk/pull/27367#issuecomment-3596330436

From alanb at openjdk.org  Mon Dec  1 13:15:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Dec 2025 13:15:49 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <xHnX0VGSD6D2l0OLmREedfs7tcoCnnn-zczoNrrTCfc=.c8f98e67-36df-4fe5-8229-869b7e1adb61@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Can you confirm that you aren't planning to try to try to integrate this before the fork for JDK 26 this week? There are several discussion points, and some of the changes are in risky areas, will likely need back time in main line.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3596489652

From alanb at openjdk.org  Mon Dec  1 13:20:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Dec 2025 13:20:49 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <sHRNXSSfRJ0D0Gwva0xmZoIX5eYGGG3InU4lZcmcSL8=.ad9a26f6-e672-4651-aa79-293107fcbf8f@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 396:

> 394:         private final PendingFuture<Integer,A> result;
> 395:         private volatile boolean released;
> 396:         private int ticket;             // to release buffer scope

This is for substitution, so needs to be declared with buf (further down), and needs to be volatile (can't use plain access as it may be released on different thread).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2577021290

From smonteith at openjdk.org  Mon Dec  1 13:48:47 2025
From: smonteith at openjdk.org (Stuart Monteith)
Date: Mon, 1 Dec 2025 13:48:47 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <xHnX0VGSD6D2l0OLmREedfs7tcoCnnn-zczoNrrTCfc=.c8f98e67-36df-4fe5-8229-869b7e1adb61@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <xHnX0VGSD6D2l0OLmREedfs7tcoCnnn-zczoNrrTCfc=.c8f98e67-36df-4fe5-8229-869b7e1adb61@github.com>
Message-ID: <49FGQkAhjaiL3NugHvEzFGQhwTOf1oOKIPAUihJDgF0=.f19c5f9b-fa41-4fbe-9223-cba043dfa1d0@github.com>

On Mon, 1 Dec 2025 13:13:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you confirm that you aren't planning to try to try to integrate this before the fork for JDK 26 this week? There are several discussion points, and some of the changes are in risky areas, will likely need back time in main line.

I am not planning, and wouldn't want to integrate this just before a fork. While I've checked it the best I can, I'd appreciate some scrutiny.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3596636408

From myankelevich at openjdk.org  Mon Dec  1 14:07:15 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 1 Dec 2025 14:07:15 GMT
Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass
 when they should skip [v5]
In-Reply-To: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
References: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
Message-ID: <5y1gcN4lI6i6zeMoqGyJXfB71cvxK5CXDK8yDWfsM84=.881abea4-c48d-4de8-8e7c-2c737937bc25@github.com>

> * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java
> * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java
> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java
> * test/jdk/sun/security/pkcs11/Signature/TestDSA.java

Mikhail Yankelevich 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 branch 'master' into JDK-8367994
 - skip reworked
 - Merge branch 'master' into JDK-8367994
 - name changes for arrays
 - renamed  id
 - JDK-8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27367/files
  - new: https://git.openjdk.org/jdk/pull/27367/files/234aa5d0..ed52c835

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

  Stats: 362487 lines in 3667 files changed: 231873 ins; 83413 del; 47201 mod
  Patch: https://git.openjdk.org/jdk/pull/27367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27367/head:pull/27367

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

From myankelevich at openjdk.org  Mon Dec  1 14:12:36 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 1 Dec 2025 14:12:36 GMT
Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass
 when they should skip [v6]
In-Reply-To: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
References: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
Message-ID: <4MPhZ2Uv1E3Wv2ohROMgeu7_KHe1YLrZr4GvDuplgSU=.855e6aa2-d6c4-49d3-8e41-fd89d0e5b619@github.com>

> * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java
> * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java
> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java
> * test/jdk/sun/security/pkcs11/Signature/TestDSA.java

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

  reworked skipped logic to be list based

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27367/files
  - new: https://git.openjdk.org/jdk/pull/27367/files/ed52c835..415fc1fd

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

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

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

From schernyshev at openjdk.org  Mon Dec  1 14:22:03 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 1 Dec 2025 14:22:03 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to
 IllegalArgumentException
Message-ID: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>

Hi all,

Let me propose a fix and a test case for JDK-8369950.

The failure reproduces with BCJSSE provider and all implementations of SSLSocker other than SSLSocketImpl.

In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).

The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.

SNIHostName, as defined in
https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66

has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.

This mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see

https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116

Testing:
- standard jtreg tests goups showed no regressions
- the new test passes with the fix and fails otherwise
- passes also with BCJSSE in FIPS and standard mode 

<details><summary> BCJSSE standard</summary>


STDOUT:
STDERR:
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
INFORMATION: Found boolean security property [keystore.type.compat]: true
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': dsa_sha1 usage HandshakeSignature
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFORMATION: Found string security property [jdk.certpath.disabledAlgorithms]: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage SignedJAR & denyAfter 2019-01-01
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 usage SignedJAR & denyAfter 2019-01-01
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSystemProperty
INFORMATION: Found string system property [java.home]: /Users/sercher/repos/jdk/build/macosx-x86_64-server-release/images/jdk
Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeBeginning
INFORMATION: [server #1 @193b6d73] accepting connection from 0:0:0:0:0:0:0:1:56197
Dez. 01, 2025 2:44:03 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeComplete
INFORMATION: [server #1 @193b6d73] established connection with 0:0:0:0:0:0:0:1:56197
Dez. 01, 2025 2:44:08 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyConnectionClosed
INFORMATION: [server #1 @193b6d73] disconnected from 0:0:0:0:0:0:0:1:56197
STATUS:Passed.

</details>

<details><summary> BCJSSE FIPS</summary>


STDOUT:
STDERR:
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
INFORMATION: Found boolean security property [keystore.type.compat]: true
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': dsa_sha1 usage HandshakeSignature
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFORMATION: Found string security property [jdk.certpath.disabledAlgorithms]: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage SignedJAR & denyAfter 2019-01-01
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 usage SignedJAR & denyAfter 2019-01-01
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSystemProperty
INFORMATION: Found string system property [java.home]: /Users/sercher/repos/jdk/build/macosx-x86_64-server-release/images/jdk
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeBeginning
INFORMATION: [server #1 @4d1e9767] accepting connection from 0:0:0:0:0:0:0:1:56184
Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeComplete
INFORMATION: [server #1 @4d1e9767] established connection with 0:0:0:0:0:0:0:1:56184
Dez. 01, 2025 2:41:37 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyConnectionClosed
INFORMATION: [server #1 @4d1e9767] disconnected from 0:0:0:0:0:0:0:1:56184
STATUS:Passed.

</details>

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

Commit messages:
 - 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException

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

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

From mullan at openjdk.org  Mon Dec  1 14:31:16 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 Dec 2025 14:31:16 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
Message-ID: <NmPZqiPhLf_0IMUAHGoEl8qvfaALrGybLX6cpLLxs3U=.883253dd-8d61-4d08-bfab-ec6dbf1758e3@github.com>

On Mon, 24 Nov 2025 07:51:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update names to uppercase
>  - Remove fallback in engineGeneratePublic
>  - Change default named group list to have only X25519MLKEM768

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 28:

> 26: 
> 27: import java.io.IOException;
> 28: import java.security.*;

Probably clearer not to use wildcard imports so we can see all the classes needed, same comment on line 32.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 35:

> 33: import sun.security.x509.X509Key;
> 34: 
> 35: import javax.crypto.SecretKey;

Move this import up, after line 29.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 47:

> 45:     static final class KEMCredentials implements NamedGroupCredentials {
> 46: 
> 47:         final NamedGroup namedGroup;

Make private, also line 50.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 67:

> 65:         }
> 66: 
> 67:         public byte[] getKeyshare() {

Nit, suggest renaming as "getKeyShare()" since RFC refers to these as two words: "key share".

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 77:

> 75: 
> 76:         /**
> 77:          * Parse the encoded Point into the KEMCredentials using the

This doesn't do any parsing, it just instantiates a `KEMCredentials` object.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 82:

> 80:         static KEMCredentials valueOf(NamedGroup namedGroup,
> 81:                 byte[] encodedPoint) throws IOException,
> 82:                 GeneralSecurityException {

This doesn't throw either of these exceptions AFAICT.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 86:

> 84:             if (namedGroup.spec != NamedGroupSpec.NAMED_GROUP_KEM) {
> 85:                 throw new RuntimeException(
> 86:                         "Credentials decoding:  Not KEM named group");

Nit: only one space after ":".

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 97:

> 95:     }
> 96: 
> 97:     static class KEMPossession implements SSLPossession {

Looks like this can be private.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 98:

> 96: 
> 97:     static class KEMPossession implements SSLPossession {
> 98:         private final NamedGroup namedGroup;

Nit, add empty lines between variable declarations and method names.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 128:

> 126:             } catch (GeneralSecurityException e) {
> 127:                 throw new RuntimeException(
> 128:                         "Could not generate XDH keypair", e);

XDH? Should this be `algName`?

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 142:

> 140:         }
> 141: 
> 142:         public PublicKey getPublicKey() {

This can be package-private, also `getPrivateKey`.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 153:

> 151:     static final class KEMSenderPossession extends KEMPossession {
> 152: 
> 153:         public SecretKey getKey() {

This method can be package-private, also `setKey`.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 161:

> 159:         }
> 160: 
> 161:         private SecretKey key;

Not - move this declaration to before `getKey`.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 163:

> 161:         private SecretKey key;
> 162: 
> 163:         KEMSenderPossession(NamedGroup namedGroup) {

Move this ctor up to before the methods.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 200:

> 198:             }
> 199:             context.conContext.fatal(Alert.HANDSHAKE_FAILURE,
> 200:                     "No sufficient XDHE key agreement "

Is this always XDHE?

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 317:

> 315:                 // Skip AlgorithmParameters for KEMs (not supported)
> 316:                 if (namedGroupSpec == NamedGroupSpec.NAMED_GROUP_KEM) {
> 317:                     Provider p = getProvider();

Nit: you can just use `defaultProvider`, no need to call `getProvider()` or define another variable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577168986
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577172087
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577185252
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577203089
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577219207
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577220264
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577207226
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577242023
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577235201
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577290498
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577263772
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577252219
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577254497
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577258290
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577305844
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2566394510

From erikj at openjdk.org  Mon Dec  1 14:57:09 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 1 Dec 2025 14:57:09 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <xdUWLsVlUtG9pNOw8nH-im3jaIzN8hO_sF-EvbXbvGo=.775b77bd-5f31-4874-a3fa-fa5374a2f494@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
 <4_rkUaOwuH6_uQRt0HnZKey0t4Z83CQvcrHEqS-VYys=.c825780e-778b-431e-9800-b3a548f1355d@github.com>
 <ZO1hyrSpqBaLEJUS5ondq0v3tiPvuJxJyiZYQ4gHgDs=.98949ddd-e7c4-4502-b1df-dbc5ebbedfb9@github.com>
 <xdUWLsVlUtG9pNOw8nH-im3jaIzN8hO_sF-EvbXbvGo=.775b77bd-5f31-4874-a3fa-fa5374a2f494@github.com>
Message-ID: <BxIyyval1TxVnnJXtTKlqFRocvM3tXXetg3mea5wfaE=.f5921cb4-92af-4c6f-919b-9827ed821e1e@github.com>

On Fri, 28 Nov 2025 19:38:20 GMT, Nick Hall <duke at openjdk.org> wrote:

> Thanks. I had a go at this today, but am struggling to build a devkit (even without any changes). Can you recommend a suitable host OS for building one, and which OS targets I should use to build the devkits to test?
> 
> (I've tried building a devkit for Fedora 41 using both RHEL8 and Fedora 41 as host OSes, but am getting a variety of issues in the build)

I haven't used this myself in a while, but I believe our internal kits use Oracle Linux 7 as host (in a container) and Oracle Linux 6 as target. RHEL should be equivalent to Oracle Linux, at least in this context. These are quite old, but the motivation for us to use devkits is to guarantee compatibility with old Linux versions. The host OS dictates the oldest where the kit itself can be used and the target dictates the oldest where the subsequently built JDK can be used. 

That said, getting a devkit to compile can be finicky for all sorts of reasons. The important part in this case is the sysroot, which is what you are going to change here, by adding extra packages. At least in theory, you could generate just a sysroot and supply that to the JDK build to verify this. I don't think there is a readily available make target for that though.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3596996889

From djelinski at openjdk.org  Mon Dec  1 15:00:14 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Dec 2025 15:00:14 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v2]
In-Reply-To: <zVGXB-bfjOycUAhnNo_37Cvoj-6YPCxB_780AlHzYPw=.a3698f36-5bfc-4986-973d-228b48579a00@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <zVGXB-bfjOycUAhnNo_37Cvoj-6YPCxB_780AlHzYPw=.a3698f36-5bfc-4986-973d-228b48579a00@github.com>
Message-ID: <lybjAaaFjuS0uXsiEPDECsQEhYhHfJ_jFi8V5vhniq8=.dcdedc62-b274-4de7-b2d2-1ce9dbc801d8@github.com>

On Tue, 25 Nov 2025 21:43:55 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
>> Also refactoring X509TrustManagerImpl logging code since we are touching this file.
>
> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Fix merge errors
>  - Merge branch 'master' into JDK-8371721
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/security/ssl/SSLLogger.java
>    #	src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java
>  - 8371721: Refactor checkTrusted methods in X509TrustManagerImpl

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 69:

> 67: 
> 68:         SSLLogger.logFine("ssl,trustmanager", "adding as trusted certificates",
> 69:                 (Object[]) trustedCerts.toArray(new X509Certificate[0]));

If you'd like to remove the calls to isOn, make sure that the log method call parameters are available without running any extra code. For example, this will always call toArray even if the logging is disabled. This will have impact on the CPU and allocation profile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2577430921

From abarashev at openjdk.org  Mon Dec  1 15:09:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 1 Dec 2025 15:09:07 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v2]
In-Reply-To: <lybjAaaFjuS0uXsiEPDECsQEhYhHfJ_jFi8V5vhniq8=.dcdedc62-b274-4de7-b2d2-1ce9dbc801d8@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <zVGXB-bfjOycUAhnNo_37Cvoj-6YPCxB_780AlHzYPw=.a3698f36-5bfc-4986-973d-228b48579a00@github.com>
 <lybjAaaFjuS0uXsiEPDECsQEhYhHfJ_jFi8V5vhniq8=.dcdedc62-b274-4de7-b2d2-1ce9dbc801d8@github.com>
Message-ID: <uVZ8vV7YNfcog21dLwkXCknYsjzN8xr6L0clx_GyGAg=.4bad1db4-316a-4143-9871-1ef922e66372@github.com>

On Mon, 1 Dec 2025 14:57:22 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Fix merge errors
>>  - Merge branch 'master' into JDK-8371721
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/sun/security/ssl/SSLLogger.java
>>    #	src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java
>>  - 8371721: Refactor checkTrusted methods in X509TrustManagerImpl
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 69:
> 
>> 67: 
>> 68:         SSLLogger.logFine("ssl,trustmanager", "adding as trusted certificates",
>> 69:                 (Object[]) trustedCerts.toArray(new X509Certificate[0]));
> 
> If you'd like to remove the calls to isOn, make sure that the log method call parameters are available without running any extra code. For example, this will always call toArray even if the logging is disabled. This will have impact on the CPU and allocation profile.

Oh, good point, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2577467287

From mullan at openjdk.org  Mon Dec  1 15:16:52 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 Dec 2025 15:16:52 GMT
Subject: RFR: 8371688: Unexpected behavior for jdk.tls.client.cipherSuites
 and jdk.tls.server.cipherSuites system properties [v3]
In-Reply-To: <WjECPDRxyqmva_xZ--gw-S1ctiAKPGwUuCWvHb2JMZk=.96e513b7-22b4-459f-8ca6-b4cc27888568@github.com>
References: <KqGL6cc_Kwq18AWnxul--q7AInEKVtKRMv5xggbKcVw=.7276c340-c470-474c-8124-6e570725084f@github.com>
 <WjECPDRxyqmva_xZ--gw-S1ctiAKPGwUuCWvHb2JMZk=.96e513b7-22b4-459f-8ca6-b4cc27888568@github.com>
Message-ID: <w6lG77CaY6jqmq5YPqXyytsD4phOl75DpKYSVeHzTGE=.1caa2672-7f29-4d31-8a07-1ca9188a8b8e@github.com>

On Wed, 26 Nov 2025 21:57:24 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system properties allow a custom set of cipher suites to be used for the default JDK SSLContext. If such properties specify cipher suites not supported by the JDK, then the JDK falls back to using the default cipher suite list (as if no property was specified). This seems like unexpected behavior.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct test description

src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 448:

> 446: 
> 447:             if (cipherSuites.isEmpty()) {
> 448:                 throw new IllegalArgumentException("System property "

How does this exception propagate to the caller? Can you show the stack trace?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28499#discussion_r2577500084

From myankelevich at openjdk.org  Mon Dec  1 15:28:25 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 1 Dec 2025 15:28:25 GMT
Subject: RFR: 8372817: Remove test/jdk/sun/security/rsa silent skips
Message-ID: <HKpgBXAhdf_aOsh8Q8djvoYiFXhTmcvCCoC7OQA_YFE=.91798c32-6c45-4e89-ac25-fd555c559e9e@github.com>

Removing silent skips and throwing skipped exceptions in the following tests:
test/jdk/sun/security/rsa/TestSigGen15.java
test/jdk/sun/security/rsa/TestCACerts.java
test/jdk/sun/security/rsa/pss/TestSigGenPSS.java
test/jdk/sun/security/rsa/pss/SignatureTest2.java

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

Commit messages:
 - JDK-8372817: Remove test/jdk/sun/security/rsa silent skips

Changes: https://git.openjdk.org/jdk/pull/28580/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28580&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372817
  Stats: 104 lines in 4 files changed: 78 ins; 3 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/28580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28580/head:pull/28580

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

From mullan at openjdk.org  Mon Dec  1 15:42:36 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 Dec 2025 15:42:36 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
Message-ID: <dPU9AfMxyNtAyg7daldkrP-8mYIpq48z4bwflz2VLxg=.18dcfc66-6386-4398-a858-ab586246025b@github.com>

On Mon, 24 Nov 2025 07:51:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update names to uppercase
>  - Remove fallback in engineGeneratePublic
>  - Change default named group list to have only X25519MLKEM768

src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 599:

> 597:                                 xp.setKey(encaped.key());
> 598:                                 keyShare = new KeyShareEntry(ng.id,
> 599:                                         encaped.encapsulation());

Should there be a break after this line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577611290

From abarashev at openjdk.org  Mon Dec  1 16:11:14 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 1 Dec 2025 16:11:14 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v3]
In-Reply-To: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
Message-ID: <gts4SYkcbfDLFF3hTv449tZTu7pmjdI0hrhYcVNhS8I=.32c3ee5d-f4fd-4e69-ac53-b54af7fb2764@github.com>

> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.

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

  Revert logging changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28275/files
  - new: https://git.openjdk.org/jdk/pull/28275/files/d2399cf0..0cabd3c4

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

  Stats: 37 lines in 2 files changed: 6 ins; 20 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28275/head:pull/28275

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

From mullan at openjdk.org  Mon Dec  1 16:17:34 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 Dec 2025 16:17:34 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <4Ab4lEzxzAL0YOlNUhk1znrIXcbZheuHNewZ-0hzvak=.cbb45d96-2269-4c7f-87e9-540224a07bb9@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <M0_MNSViTpDaV_-ek4AXkQ-_QiQgpuRBcP-9h1nY8VI=.8be542c8-f3a1-4dcc-b004-280ce9a9286f@github.com>
 <SjX0xqXCA4FsBab_DIX4lG17zSc_OrQx5P9Y-Zn9sFE=.d46430f4-1912-4df2-b552-31c268a18d47@github.com>
 <4Ab4lEzxzAL0YOlNUhk1znrIXcbZheuHNewZ-0hzvak=.cbb45d96-2269-4c7f-87e9-540224a07bb9@github.com>
Message-ID: <nQKlt0nesBkWqzs-qqIU39WTwxbxh4SMZnLFgMX20Is=.5a10b51e-4e78-451c-95c5-3747e45c9f04@github.com>

On Wed, 26 Nov 2025 19:46:38 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Could this class could be renamed to something more meaningful?  e.g. `DHasKEM`, `DHasaKEM` or something similar.   A class name of `DH` by itself hints this will be a DH implementation.  I would expect a `KeyAgreement` impl, not as a wrapper.
>
> One other nit, currently the `Params` class doesn't actually handle `DH`, just `ECDH`/`XDH`.  Should you remove `DH` from the `DH/ECDH/XDH` javadoc?

Also, if it is only used by JSSE, I think it should be in the `sun.security.ssl` package.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577682240

From mullan at openjdk.org  Mon Dec  1 16:17:37 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 Dec 2025 16:17:37 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
Message-ID: <Y7azUkWEoruKxpinhEeiOQ8MH8u9Dz-AyCy_JvgbwkI=.49efad6e-1d35-4721-b5dc-d73ff240dc1d@github.com>

On Mon, 24 Nov 2025 07:51:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update names to uppercase
>  - Remove fallback in engineGeneratePublic
>  - Change default named group list to have only X25519MLKEM768

src/java.base/share/classes/com/sun/crypto/provider/DH.java line 66:

> 64:  * KEMs.
> 65:  */
> 66: public class DH implements KEMSpi {

This class includes more than a DH KEM wrapper implementation. The provider is registering all the hybrid algorithms, including the ML-KEM parts. It feels odd to be hiding the provider inside this class. I suggest creating a separate `HybridProvider` class that is in `sun.security.ssl` package and either encapsulating the DH impl inside that, or better yet, create a separate class for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577735059

From sviswanathan at openjdk.org  Mon Dec  1 16:33:43 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 1 Dec 2025 16:33:43 GMT
Subject: RFR: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
 [v10]
In-Reply-To: <cbgcZOlm-8SgDVFjLxcZoki5kqR9L7UqWG9IYcux2dw=.b99e999e-3cef-488e-a68c-64a31f30257d@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
 <cbgcZOlm-8SgDVFjLxcZoki5kqR9L7UqWG9IYcux2dw=.b99e999e-3cef-488e-a68c-64a31f30257d@github.com>
Message-ID: <EZqbtsJfAPMFDdclYH5cLhADvu_4EztD4q-ENsJjiAg=.c55d5017-09a1-4b80-b4f3-945f9959cad9@github.com>

On Fri, 28 Nov 2025 06:01:26 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
>> 
>> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to break before operators.

Marked as reviewed by sviswanathan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28363#pullrequestreview-3525930778

From abarashev at openjdk.org  Mon Dec  1 16:34:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 1 Dec 2025 16:34:49 GMT
Subject: RFR: 8371688: Unexpected behavior for jdk.tls.client.cipherSuites
 and jdk.tls.server.cipherSuites system properties [v3]
In-Reply-To: <w6lG77CaY6jqmq5YPqXyytsD4phOl75DpKYSVeHzTGE=.1caa2672-7f29-4d31-8a07-1ca9188a8b8e@github.com>
References: <KqGL6cc_Kwq18AWnxul--q7AInEKVtKRMv5xggbKcVw=.7276c340-c470-474c-8124-6e570725084f@github.com>
 <WjECPDRxyqmva_xZ--gw-S1ctiAKPGwUuCWvHb2JMZk=.96e513b7-22b4-459f-8ca6-b4cc27888568@github.com>
 <w6lG77CaY6jqmq5YPqXyytsD4phOl75DpKYSVeHzTGE=.1caa2672-7f29-4d31-8a07-1ca9188a8b8e@github.com>
Message-ID: <VssmcUwayNF0oMCK4_Dw1X8Z2xmm5cT93WKHjFmUR8A=.7a8cd9a8-bd1a-4be8-bfdf-5e6355dd0ec6@github.com>

On Mon, 1 Dec 2025 15:14:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct test description
>
> src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 448:
> 
>> 446: 
>> 447:             if (cipherSuites.isEmpty()) {
>> 448:                 throw new IllegalArgumentException("System property "
> 
> How does this exception propagate to the caller? Can you show the stack trace?

Since this method is called to initialize static class variables the whole class fails to initialize. So `ExceptionInInitializerError` is being thrown as demonstrated in the [unit test](https://github.com/openjdk/jdk/pull/28499/files#diff-907d2d932e7c3ee713ab69b674a8c5f6edfc5ebf3f62421e0effb0951ced41c9R45)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28499#discussion_r2577801716

From djelinski at openjdk.org  Mon Dec  1 17:10:51 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Dec 2025 17:10:51 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <PTlRzYZLDP-z97hrOWr9C3CQt0TOkr9MSwQ2sOeu3ZE=.cdd8fddd-5659-4fc9-8418-2b5042bd6935@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocker other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> This mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44...

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28577#pullrequestreview-3526098687

From dfuchs at openjdk.org  Mon Dec  1 17:19:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 1 Dec 2025 17:19:31 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <7AkGXks9t4bapk0cGxAcBvIYE5wN6ChDCDoG-gvOBGI=.0aee1a66-4ba2-4dcb-b22a-2b699b1544bd@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocker other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> This mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44...

Please make sure to run tier2 before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3597828383

From jiangli at openjdk.org  Mon Dec  1 17:32:40 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 1 Dec 2025 17:32:40 GMT
Subject: Integrated: 8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2
 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes
In-Reply-To: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
References: <WeKDs8ORqmBgSey5OZswmtLfLg8NlelH0vJWiDe57eY=.16e1285a-86e8-4d0f-88dc-fc94a9d16c2b@github.com>
Message-ID: <OSciecmQy6yIKASkZTbuN06No-M0AXNo7bj3h2HE3-c=.4bf165b0-da13-4941-9a1e-4d7818acc51f@github.com>

On Mon, 17 Nov 2025 22:34:14 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in StubGenerator::aesgcm_avx512 and StubGenerator::aesgcm_avx2 to handle some edge cases with input sizes that are not multiple of the block size. 
> 
> Thanks to Thomas Holenstein and Lukas Zobernig for analyzing the issue and providing the test case!

This pull request has now been integrated.

Changeset: 6cb1c8f9
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cb1c8f9cfcb797af788ca8fb490f388cc68f525
Stats:     151 lines in 2 files changed: 149 ins; 1 del; 1 mod

8371864: GaloisCounterMode.implGCMCrypt0 AVX512/AVX2 intrinsics stubs cause AES-GCM encryption failure for certain payload sizes

Co-authored-by: Thomas Holenstein <tholenst at google.com>
Co-authored-by: Lukas Zobernig <zlukas at google.com>
Reviewed-by: shade, sviswanathan

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

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

From schernyshev at openjdk.org  Mon Dec  1 17:47:48 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 1 Dec 2025 17:47:48 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <7AkGXks9t4bapk0cGxAcBvIYE5wN6ChDCDoG-gvOBGI=.0aee1a66-4ba2-4dcb-b22a-2b699b1544bd@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <7AkGXks9t4bapk0cGxAcBvIYE5wN6ChDCDoG-gvOBGI=.0aee1a66-4ba2-4dcb-b22a-2b699b1544bd@github.com>
Message-ID: <YEiILQtz1CENn5uWIL0irhgQezospPnTPTB6IILMt6w=.01271876-9e28-4a10-883c-c41fc1ee521a@github.com>

On Mon, 1 Dec 2025 17:16:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please make sure to run tier2 before integrating.

@dfuch Thanks Daniel. The new test is in tier2, so far it passes in macOS and Linux. Windows takes more time with tier2...

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3597983722

From schernyshev at openjdk.org  Mon Dec  1 17:47:46 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 1 Dec 2025 17:47:46 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <PTlRzYZLDP-z97hrOWr9C3CQt0TOkr9MSwQ2sOeu3ZE=.cdd8fddd-5659-4fc9-8418-2b5042bd6935@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <PTlRzYZLDP-z97hrOWr9C3CQt0TOkr9MSwQ2sOeu3ZE=.cdd8fddd-5659-4fc9-8418-2b5042bd6935@github.com>
Message-ID: <zfrU4B35UNYr5y5Y7x-f2xe_oib6LnvUa1PxWP9l6Os=.e6b56ebc-aa81-4f00-9fbb-494b18336cc6@github.com>

On Mon, 1 Dec 2025 17:08:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> LGTM. Thanks!

@djelinski Thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3597970287

From vpaprotski at openjdk.org  Mon Dec  1 18:01:24 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 1 Dec 2025 18:01:24 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
Message-ID: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>

- Stop catching exception to make test able to fail
- Remove java-only test variation that cannot fail
- Reduce fuzz repeat count

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

Commit messages:
 - impossible variation
 - fewer repetitions and test impossible to fail

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

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

From mcimadamore at openjdk.org  Mon Dec  1 18:26:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Dec 2025 18:26:47 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <AvxdZJlyuZUh8a7q1xCN6DSQExHyS9m9CLTtgc9c1Bg=.06ff7be3-d968-4b79-8e1c-ccbce6ac0acd@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Thanks for working on this problem.

At the high level I understand your goal here. It is a bit unfortunate that we have to change the API for acquire/release which cascades in many smaller (but simple) changes throughout the JDK. But let's set that aside.

The main (and more serious) issue with this PR is the decoupling of the liveness bit from the ref counting part. This is something that will require some time to work through to ensure correctness is preserved in all cases.

More generally, it is generally advisable for such deep changes to perhaps reach out to panama-dev mailing list first, and maybe have a discussion/reach some consensus there, before moving ahead with a PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3598181959

From smonteith at openjdk.org  Mon Dec  1 19:06:46 2025
From: smonteith at openjdk.org (Stuart Monteith)
Date: Mon, 1 Dec 2025 19:06:46 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <AvxdZJlyuZUh8a7q1xCN6DSQExHyS9m9CLTtgc9c1Bg=.06ff7be3-d968-4b79-8e1c-ccbce6ac0acd@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <AvxdZJlyuZUh8a7q1xCN6DSQExHyS9m9CLTtgc9c1Bg=.06ff7be3-d968-4b79-8e1c-ccbce6ac0acd@github.com>
Message-ID: <SwHx_atpaJJH61nyPYs6s8B-bAZzdL7IsNoOQRadiGg=.8319a405-d5d8-4240-b90d-3e8b30964053@github.com>

On Mon, 1 Dec 2025 18:24:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Thanks for working on this problem.
> 
> At the high level I understand your goal here. It is a bit unfortunate that we have to change the API for acquire/release which cascades in many smaller (but simple) changes throughout the JDK. But let's set that aside.
Yes, that was regrettable.  Originally I retained the "void release0()" that recalculated the "ticket", which resulted in fewer changes. However, it was felt the explicit ticket passing was less likely to introduce errors. 

> 
> The main (and more serious) issue with this PR is the decoupling of the liveness bit from the ref counting part. This is something that will require some time to work through to ensure correctness is preserved in all cases.
> 
Yes, I had been grappling with the  atomicity. The "acquireCount" and "state" are decoupled in the most recent revision of the, so this closing should either fail and not update state, or pass and complete the shutdown. However, the "state" and ScopedAccesses are complex, so I appreciate the scrutiny in that area.

> More generally, it is generally advisable for such deep changes to perhaps reach out to panama-dev mailing list first, and maybe have a discussion/reach some consensus there, before moving ahead with a PR.

That was my mistake - I expected that with the foreign ABI being merged, discussions on internals would have reverted to here.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3598403208

From dfuchs at openjdk.org  Mon Dec  1 20:03:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 1 Dec 2025 20:03:48 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <x_v3WgjWRTrDeLMVicLTumpe_I0gyHVcOMUZvmh1rRE=.5c74b5d5-6d30-4534-9692-f4bf22f4248d@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocker other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28577#pullrequestreview-3526733114

From mullan at openjdk.org  Mon Dec  1 20:49:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 Dec 2025 20:49:56 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <fj3JewRv0ppeGNexhDFVgZk-dS3kbUsfP62GSmHgdOQ=.c408bfbf-30a6-49f7-b3c4-b46acec64184@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <M0_MNSViTpDaV_-ek4AXkQ-_QiQgpuRBcP-9h1nY8VI=.8be542c8-f3a1-4dcc-b004-280ce9a9286f@github.com>
 <fj3JewRv0ppeGNexhDFVgZk-dS3kbUsfP62GSmHgdOQ=.c408bfbf-30a6-49f7-b3c4-b46acec64184@github.com>
Message-ID: <TS4NOHk_6bs-vr9P7J0N6R1TUn1Nd6DrwbyrCGLm_94=.a1553315-7a58-4150-a257-c7331f4f9f22@github.com>

On Wed, 26 Nov 2025 18:03:33 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 86:
>> 
>>> 84:                     "right", "X25519");
>>> 85:             putService(new HybridService(this, "KeyPairGenerator",
>>> 86:                     "X25519MLKEM768", "sun.security.util.Hybrid$KeyPairGeneratorImpl",
>> 
>> Is there a reason why `Hybrid` is in `sun.security.util` instead of `com.sun.crypto.provider`?    This is the only place it's used, so `c.s.c.p` seems to be a more natural place for it, but maybe I'm just not far enough into the guts of the code yet.
>
> Did you place it here because Key Pairs generally live in `s.s.*`?

I would put `Hybrid` in `sun.security.ssl`. If at some point in the future, it becomes more generally valuable outside of JSSE, we can restructure/move it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577990699

From mullan at openjdk.org  Mon Dec  1 20:50:03 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 Dec 2025 20:50:03 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
Message-ID: <ygDE87sA6c4qIkX65GviP1qfh42xjIQ3NBm_o2GFmLk=.791c1ed5-861b-4bfc-b025-3fc1ac3e0124@github.com>

On Mon, 24 Nov 2025 07:51:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update names to uppercase
>  - Remove fallback in engineGeneratePublic
>  - Change default named group list to have only X25519MLKEM768

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 54:

> 52:     private final PublicKey peerPublicKey;
> 53:     private final byte[] keyshare;
> 54:     private final java.security.Provider provider;

Add `java.security.Provider` to imports.

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 162:

> 160:      * to encapsulate a shared secret and returns the encapsulated message.
> 161:      */
> 162:     public KEM.Encapsulated encapsulate(String algorithm)

Can this be package-private?

src/java.base/share/classes/sun/security/util/Hybrid.java line 55:

> 53: import java.util.Locale;
> 54: 
> 55: public class Hybrid {

Add a few comments describing this class.

src/java.base/share/classes/sun/security/util/Hybrid.java line 60:

> 58:         @Override
> 59:         public String getAlgorithm() {
> 60:             return "Hybrid";

Should we just return "Generic" here to align with the KEM spec?

src/java.base/share/classes/sun/security/util/Hybrid.java line 430:

> 428:         @Override
> 429:         public byte[] getEncoded() {
> 430:             return new byte[0];

Should return `null` instead (according to `Key.getEncoded` spec).

src/java.base/share/classes/sun/security/util/Hybrid.java line 444:

> 442:     }
> 443: 
> 444:     public static final NamedParameterSpec X25519_MLKEM768 =

Move these constants to the top of the class so they are more prominent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578565565
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578581181
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2577981590
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578538775
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578037823
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578026970

From bperez at openjdk.org  Mon Dec  1 21:30:24 2025
From: bperez at openjdk.org (Ben Perez)
Date: Mon, 1 Dec 2025 21:30:24 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
Message-ID: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>

An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method

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

Commit messages:
 - Replaced scalar multiplication with neon regs, added vector by element variant of umullv
 - Removed  use, streamlined mask calculation, changed arrangement specifier for ORR
 - Added stubroutine code
 - aarch64 intrinsics for MontgomeryIntegerPolynomialP256.mult()

Changes: https://git.openjdk.org/jdk/pull/27946/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27946&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355216
  Stats: 446 lines in 4 files changed: 445 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27946.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27946/head:pull/27946

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

From aph at openjdk.org  Mon Dec  1 21:30:28 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 1 Dec 2025 21:30:28 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
In-Reply-To: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
Message-ID: <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>

On Thu, 23 Oct 2025 01:39:02 GMT, Ben Perez <bperez at openjdk.org> wrote:

> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method

On 29/10/2025 20:18, Ben Perez wrote:
> Is there by any chance documentation for `RegSet` that I can reference while making these changes?

No, but it's all there in the source.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7144:

> 7142: 
> 7143:   address generate_intpoly_montgomeryMult_P256() {
> 7144: 

As a general point, it would help everyone if you provided pseudocode for the whole thing.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7160:

> 7158:     };
> 7159: 
> 7160:     Register c_ptr = r9;

`rscratch1` and `rscratch2` are used freely by macros, so aliasing them is always rather sketchy. As far as I can tell the arg registers aren't used here, so it makes sense to use `r3`...

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7169:

> 7167:     Register mul_tmp = r14;
> 7168:     Register n = r15;
> 7169: 

Here, you could do something like


    RegSet scratch = RegSet::range(r3, r28) - rscratch1 - rscratch2;

    {
      auto r_it = scratch.begin();
      Register
        c_ptr = *r_it++,
        a_i = *r_it++,
        c_idx = *r_it++, //c_idx is not used at the same time as a_i
        limb_mask_scalar = *r_it++,
        b_j = *r_it++,
        mod_j = *r_it++,
        mod_ptr = *r_it++,
        mul_tmp = *r_it++,
        n = *r_it++;
       ...
    }



Note that a RegSet iterator doesn't affect the RegSet it was created from, so once this block has ended you can allocate again from the set of scratch registers.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7201:

> 7199:     __ mov(limb_mask_scalar, 1);
> 7200:     __ neg(limb_mask_scalar, limb_mask_scalar);
> 7201:     __ lsr(limb_mask_scalar, limb_mask_scalar, 12);

Suggestion:

    __ mov(limb_mask_scalar, -UCONST64(1) >> (64 - BITS_PER_LIMB));

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7229:

> 7227:       __ shl(high_01, __ T2D, high_01, shift1);
> 7228:       __ ushr(tmp, __ T2D, low_01, shift2);
> 7229:       __ orr(high_01, __ T2D, high_01, tmp);

Suggestion:

      __ orr(high_01, __ T16B, high_01, tmp);

everywhere.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7403:

> 7401:     // c3 &= LIMB_MASK;
> 7402: 
> 7403:     __ ldr(mod_j, __ post(mod_ptr, 8));

Best not to use post-increment if you can avoid it.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7440:

> 7438: 
> 7439:     Register res_0 = r9;
> 7440:     Register res_1 = r10;

Aliasing the same register with different names is very dangerous, and has cause hard-to-find failures in production code in the past. You can confine the `Register` instances to block scope. You can also suffix or prefix the local names with canonical register names.

Best of all is to get rid of the manual register allocation altogether, by  creating a `RegSet`, then adding and removing registers that you need, as you go along. That way the need to manually check register usage goes away altogether.

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

PR Comment: https://git.openjdk.org/jdk/pull/27946#issuecomment-3466766156
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460515105
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460510697
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2461123587
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460582673
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2461125143
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460621762
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460612964

From bperez at openjdk.org  Mon Dec  1 21:30:28 2025
From: bperez at openjdk.org (Ben Perez)
Date: Mon, 1 Dec 2025 21:30:28 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
In-Reply-To: <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
Message-ID: <l48FZMwpVg-gJbowobeog1zHjklRJO4khHGvRiEaQ4s=.448c6c83-95df-4bbd-88c5-0a000f91c548@github.com>

On Fri, 24 Oct 2025 13:36:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7144:
> 
>> 7142: 
>> 7143:   address generate_intpoly_montgomeryMult_P256() {
>> 7144: 
> 
> As a general point, it would help everyone if you provided pseudocode for the whole thing.

Happy to add pseudocode but it will be quite long and almost identical to what is already in `MontgomeryIntegerPolynomial256.mult()` except mine uses a loop instead of unrolling the whole thing

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7160:
> 
>> 7158:     };
>> 7159: 
>> 7160:     Register c_ptr = r9;
> 
> `rscratch1` and `rscratch2` are used freely by macros, so aliasing them is always rather sketchy. As far as I can tell the arg registers aren't used here, so it makes sense to use `r3`...

Is there a reason hotspot doesn't leave `r9` open for use as a caller saved local variable like in the ARM docs https://developer.arm.com/documentation/102374/0103/Procedure-Call-Standard. Either way will fix.

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7169:
> 
>> 7167:     Register mul_tmp = r14;
>> 7168:     Register n = r15;
>> 7169: 
> 
> Here, you could do something like
> 
> 
>     RegSet scratch = RegSet::range(r3, r28) - rscratch1 - rscratch2;
> 
>     {
>       auto r_it = scratch.begin();
>       Register
>         c_ptr = *r_it++,
>         a_i = *r_it++,
>         c_idx = *r_it++, //c_idx is not used at the same time as a_i
>         limb_mask_scalar = *r_it++,
>         b_j = *r_it++,
>         mod_j = *r_it++,
>         mod_ptr = *r_it++,
>         mul_tmp = *r_it++,
>         n = *r_it++;
>        ...
>     }
> 
> 
> 
> Note that a RegSet iterator doesn't affect the RegSet it was created from, so once this block has ended you can allocate again from the set of scratch registers.

Is there by any chance documentation for `RegSet` that I can reference while making these changes?

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7229:
> 
>> 7227:       __ shl(high_01, __ T2D, high_01, shift1);
>> 7228:       __ ushr(tmp, __ T2D, low_01, shift2);
>> 7229:       __ orr(high_01, __ T2D, high_01, tmp);
> 
> Suggestion:
> 
>       __ orr(high_01, __ T16B, high_01, tmp);
> 
> everywhere.

thanks for the suggestion! Does using `T16B` improve performance? Similarly, should this be applied to `EOR` as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2475133382
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2539340501
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2475267081
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2474686235

From aph at openjdk.org  Mon Dec  1 21:30:28 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 1 Dec 2025 21:30:28 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
In-Reply-To: <l48FZMwpVg-gJbowobeog1zHjklRJO4khHGvRiEaQ4s=.448c6c83-95df-4bbd-88c5-0a000f91c548@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
 <l48FZMwpVg-gJbowobeog1zHjklRJO4khHGvRiEaQ4s=.448c6c83-95df-4bbd-88c5-0a000f91c548@github.com>
Message-ID: <Q3VleKPv_j0CQFYhlsJ8ZWE1FPoDViSxl67pdB61c_0=.f4db1766-3e12-41bd-af19-bf43b2b9e3c6@github.com>

On Tue, 18 Nov 2025 19:00:21 GMT, Ben Perez <bperez at openjdk.org> wrote:

> Is there a reason hotspot doesn't leave `r9` open for use as a caller saved local variable like in the ARM docs https://developer.arm.com/documentation/102374/0103/Procedure-Call-Standard. Either way will fix.

Yes, because a ton of convenience macros in `MacroAssembler` use it. HotSpot internally doesn't use the APCS.

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7169:
>> 
>>> 7167:     Register mul_tmp = r14;
>>> 7168:     Register n = r15;
>>> 7169: 
>> 
>> Here, you could do something like
>> 
>> 
>>     RegSet scratch = RegSet::range(r3, r28) - rscratch1 - rscratch2;
>> 
>>     {
>>       auto r_it = scratch.begin();
>>       Register
>>         c_ptr = *r_it++,
>>         a_i = *r_it++,
>>         c_idx = *r_it++, //c_idx is not used at the same time as a_i
>>         limb_mask_scalar = *r_it++,
>>         b_j = *r_it++,
>>         mod_j = *r_it++,
>>         mod_ptr = *r_it++,
>>         mul_tmp = *r_it++,
>>         n = *r_it++;
>>        ...
>>     }
>> 
>> 
>> 
>> Note that a RegSet iterator doesn't affect the RegSet it was created from, so once this block has ended you can allocate again from the set of scratch registers.
>
> Is there by any chance documentation for `RegSet` that I can reference while making these changes?

I could talk you through it, or give you a few more examples. It's easy to use once you get used to it.

> thanks for the suggestion! Does using `T16B` improve performance? Similarly, should this be applied to `EOR` as well?

Yes. According to the ARM, only 8B and 16B forms are the official names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2541919496
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2477261216
PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2476966812

From aph at openjdk.org  Mon Dec  1 21:30:29 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 1 Dec 2025 21:30:29 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64
In-Reply-To: <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <opKn1GSXP55kVVKqbbVljAneMYSaYYbjYehCmNlQvSY=.ba551dd2-d89d-451b-8d3a-66531f1c344f@github.com>
Message-ID: <-XQj1n1myEUztrPjw8lc7_-AxeCmRAiFAoBq4k6qmfU=.0f9f4eda-58c8-489f-95a1-5cb994d88031@github.com>

On Fri, 24 Oct 2025 13:57:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7403:
> 
>> 7401:     // c3 &= LIMB_MASK;
>> 7402: 
>> 7403:     __ ldr(mod_j, __ post(mod_ptr, 8));
> 
> Best not to use post-increment if you can avoid it.

It adds a dependency chain between each use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2460624122

From mullan at openjdk.org  Mon Dec  1 21:54:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 Dec 2025 21:54:55 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v11]
In-Reply-To: <_HUUN67SsUDKiW4mhpPssp7bTD-BIiz0Ho1qyltjYeY=.afae4482-6158-4e73-aee1-351d1251d759@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <f1LGOwCPsznfyr2PPV8WapM4335Th4oEs4kR_lT8bBM=.50f62482-94c8-490a-9e02-20c3d2958ea0@github.com>
 <tXOYQ_nde9pAdy2Gn_DhUzmLm9Lu02sf-mGI87I819Q=.758751d0-3684-4fdf-be8b-222ee93e13e3@github.com>
 <_HUUN67SsUDKiW4mhpPssp7bTD-BIiz0Ho1qyltjYeY=.afae4482-6158-4e73-aee1-351d1251d759@github.com>
Message-ID: <nIgkLXhux9Lzc1B7rXGekZkfgiPhNMUPkM7yfGDNmo0=.cde2b511-f03b-4d85-af3f-4f8a8b1ff755@github.com>

On Wed, 26 Nov 2025 21:17:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hi folks, as we know [JDK 26 enters Rampdown Phase One next week](https://mail.openjdk.org/pipermail/jdk-dev/2025-November/010639.html) on Thursday, 4 December.
>> 
>> Please let me know if we'll want this fix to move forward before that happens, and please note that soon I will need to focus on the OJVG work.
>> 
>> If you prefer, I'm fine with using `path.toRealPath()` instead of `path.toFile().getCanonicalFile().toPath()`. That would keep relative includes broken in _Windows_ UWP Java applications and from _Linux_ anonymous pipes and files (where they don't make a lot of sense anyway). But that is better than the current status quo (_Windows_ UWP Java applications break if they load the `java.security.Security` class).
>> 
>> Just let me know if you want to proceed that way and I will, also removing the part of the new test that will break by that change.
>
>> Hi folks, as we know [JDK 26 enters Rampdown Phase One next week](https://mail.openjdk.org/pipermail/jdk-dev/2025-November/010639.html) on Thursday, 4 December.
>> 
>> Please let me know if we'll want this fix to move forward before that happens, and please note that soon I will need to focus on the OJVG work.
>> 
>> If you prefer, I'm fine with using `path.toRealPath()` instead of `path.toFile().getCanonicalFile().toPath()`. That would keep relative includes broken in _Windows_ UWP Java applications and from _Linux_ anonymous pipes and files (where they don't make a lot of sense anyway). But that is better than the current status quo (_Windows_ UWP Java applications break if they load the `java.security.Security` class).
>> 
>> Just let me know if you want to proceed that way and I will, also removing the part of the new test that will break by that change.
> 
> Yes, I agree that seems like a way forward, if not perfect. @AlanBateman ok with you?

> @seanjmullan: with the hope of moving this forward before the JDK 26 Rampdown, I went ahead and implemented the remaining two suggestions. I have re-run the listed test categories from the description in _Windows_ and _Linux_, everything is passing. It should be ready for a final review now.

Ok, I will review the latest changes. Give me a day or so.

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3599119154

From wetmore at openjdk.org  Mon Dec  1 21:58:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 1 Dec 2025 21:58:55 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <nQKlt0nesBkWqzs-qqIU39WTwxbxh4SMZnLFgMX20Is=.5a10b51e-4e78-451c-95c5-3747e45c9f04@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <M0_MNSViTpDaV_-ek4AXkQ-_QiQgpuRBcP-9h1nY8VI=.8be542c8-f3a1-4dcc-b004-280ce9a9286f@github.com>
 <SjX0xqXCA4FsBab_DIX4lG17zSc_OrQx5P9Y-Zn9sFE=.d46430f4-1912-4df2-b552-31c268a18d47@github.com>
 <4Ab4lEzxzAL0YOlNUhk1znrIXcbZheuHNewZ-0hzvak=.cbb45d96-2269-4c7f-87e9-540224a07bb9@github.com>
 <nQKlt0nesBkWqzs-qqIU39WTwxbxh4SMZnLFgMX20Is=.5a10b51e-4e78-451c-95c5-3747e45c9f04@github.com>
Message-ID: <BcX9xdm4WP-5derCSKKHpg13aZI4A-IUmoE_aL_xiOY=.c8a82466-96d8-42b5-bc67-544de4927235@github.com>

On Mon, 1 Dec 2025 15:58:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> One other nit, currently the `Params` class doesn't actually handle `DH`, just `ECDH`/`XDH`.  Should you remove `DH` from the `DH/ECDH/XDH` javadoc?
>
> Also, if it is only used by JSSE, I think it should be in the `sun.security.ssl` package.

We did include the internal `Tls*` implementations Sun in the `SunJCE` provider, but those were actually exposed/available as `KeyGenerator`s.  I was never a fan, but it is what it is.  

`sun.security.ssl` is a better fit for this and `Hybrid.java`, especially since these are strictly internal implementations for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578818202

From wetmore at openjdk.org  Mon Dec  1 21:58:59 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 1 Dec 2025 21:58:59 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <Y7azUkWEoruKxpinhEeiOQ8MH8u9Dz-AyCy_JvgbwkI=.49efad6e-1d35-4721-b5dc-d73ff240dc1d@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <Y7azUkWEoruKxpinhEeiOQ8MH8u9Dz-AyCy_JvgbwkI=.49efad6e-1d35-4721-b5dc-d73ff240dc1d@github.com>
Message-ID: <hQGeRqaqA6UlG-iKFwrTX6vecKUzTXxVDBGs8CBazCI=.52986351-e8e3-4dab-a8cd-008e54b2a640@github.com>

On Mon, 1 Dec 2025 16:13:52 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - Change default named group list to have only X25519MLKEM768
>
> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 66:
> 
>> 64:  * KEMs.
>> 65:  */
>> 66: public class DH implements KEMSpi {
> 
> This class includes more than a DH KEM wrapper implementation. The provider is registering all the hybrid algorithms, including the ML-KEM parts. It feels odd to be hiding the provider inside this class. I suggest creating a separate `HybridProvider` class that is in `sun.security.ssl` package and either encapsulating the DH impl inside that, or better yet, create a separate class for it.

Agreed.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 28:
> 
>> 26: 
>> 27: import java.io.IOException;
>> 28: import java.security.*;
> 
> Probably clearer not to use wildcard imports so we can see all the classes needed, same comment on line 32.

I vaguely remember somewhere the guidance that if there are <= 5 imports, you should list them, otherwise use the wildcard.

> test/jdk/javax/net/ssl/TLSv13/HRRKeyShares.java line 33:
> 
>> 31:  * @summary Use two key share entries
>> 32:  * @library /test/lib
>> 33:  * @run main/othervm -Djdk.tls.namedGroups=x25519,secp256r1,secp384r1,X25519MLKEM768,SecP256r1MLKEM768,SecP384r1MLKEM1024 HRRKeyShares
> 
> Long line, break up into multiple lines.

I noted quite a few <= 80 comments throughout, so fully agree here!  ;)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578840216
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578857585
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578864356

From wetmore at openjdk.org  Mon Dec  1 21:59:00 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 1 Dec 2025 21:59:00 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <TS4NOHk_6bs-vr9P7J0N6R1TUn1Nd6DrwbyrCGLm_94=.a1553315-7a58-4150-a257-c7331f4f9f22@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <M0_MNSViTpDaV_-ek4AXkQ-_QiQgpuRBcP-9h1nY8VI=.8be542c8-f3a1-4dcc-b004-280ce9a9286f@github.com>
 <fj3JewRv0ppeGNexhDFVgZk-dS3kbUsfP62GSmHgdOQ=.c408bfbf-30a6-49f7-b3c4-b46acec64184@github.com>
 <TS4NOHk_6bs-vr9P7J0N6R1TUn1Nd6DrwbyrCGLm_94=.a1553315-7a58-4150-a257-c7331f4f9f22@github.com>
Message-ID: <OwSN1t4pvmevhR6Sg_CZpef4XFiaI_iDQZl_45sCEn8=.1b3dea8c-ffa4-40c3-9084-d4f347292c8f@github.com>

On Mon, 1 Dec 2025 17:28:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Did you place it here because Key Pairs generally live in `s.s.*`?
>
> I would put `Hybrid` in `sun.security.ssl`. If at some point in the future, it becomes more generally valuable outside of JSSE, we can restructure/move it.

Agreed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2578839080

From bperez at openjdk.org  Mon Dec  1 22:19:09 2025
From: bperez at openjdk.org (Ben Perez)
Date: Mon, 1 Dec 2025 22:19:09 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v2]
In-Reply-To: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
Message-ID: <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>

> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method

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

  Fixed typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27946/files
  - new: https://git.openjdk.org/jdk/pull/27946/files/6d6786a0..293ad948

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

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

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

From duke at openjdk.org  Tue Dec  2 08:33:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Dec 2025 08:33:47 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <mlPvhRjZwzG8k4f3rtUUn148GJo1gHNAl2z2t0py04s=.e078ea74-be1a-487c-b331-5bd6c6234ac9@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

@sercher 
Your change (at version 7d1a90321450ac9a875ba78c8f261f1729fdd524) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3600827920

From jpai at openjdk.org  Tue Dec  2 09:19:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 09:19:06 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <Hm63cKxAO6ZBOq1Eg5xlHJLzAiwFjNg3eGr6OUl_mzU=.6edb21e2-25fb-430e-bdfc-a9d4baa6c0f9@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

Hello Sergey, the copyright year on `HttpsClient` will need an update from `2001, 2024,` to `2001, 2025,`

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3601015803

From jpai at openjdk.org  Tue Dec  2 09:32:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 09:32:06 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <QX9h5Z2hBg1I6EgYIJO6kfKPPoWt5PQp23eR0w2lbYw=.b46b8106-1ed2-4c4e-a557-3af1e46f62a7@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478:

> 476:                             !IPAddressUtil.isIPv4LiteralAddress(host) &&
> 477:                             !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' &&
> 478:                                 IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1))

The `host` value here comes from `URL.getHost()` which specifies that it returns an IPv6 address enclosed in `[]`brackets. So what you have here looks fine to me.

One additional thing I would suggest is to make this `protected String host` field of this class `final`. It currently gets assigned in the constructor of the `HttpClient` and `HttpsClient` and making this `final` would give an extra assurance that its value will always be coming from `URL.getHost()` call. 

These 2 `sun.net.www.http.HttpClient` and `HttpsClient` classes are internal to the JDK, so changing this protected field to final shouldn't cause any issues for application code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580356484

From jpai at openjdk.org  Tue Dec  2 09:49:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 09:49:51 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 28:

> 26:  * @bug 8369950
> 27:  * @library /test/lib
> 28:  * @summary TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException

Nit - as per the jtreg tag order recommendation, the `@summary` should come before the `@library` https://openjdk.org/jtreg/tag-spec.html#ORDER

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 71:

> 69:      * currently 3 minutes by default, but you might try to be
> 70:      * smart about it....
> 71:      */

I am not too familiar with these style of tests, but it looks like there are several similar ones in the `javax/net/ssl` area. Would you know if these comments are still accurate and up to date? In other words, do we need these comments in this test?

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 97:

> 95:         bw.write("HTTP/1.1 200 OK\r\n\r\n\r\n");
> 96:         bw.flush();
> 97:         Thread.sleep(5000);

Is the sleep() necessary for this test?

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 165:

> 163:      */
> 164:     SubjectAltNameIPv6() throws Exception {
> 165:         if (separateServerThread) {

Are these if/else blocks needed or could we simplify the test to just expect the server and client to run as separate threads?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580413566
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580386092
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580387059
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580393762

From jpai at openjdk.org  Tue Dec  2 09:49:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 09:49:52 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
Message-ID: <y8TpJOSbXJ8y1UPcBl3KdB9PhYt-5Q0IJyeQ3uWlNiI=.4706926b-95dd-47ed-8add-50e2044fc577@github.com>

On Tue, 2 Dec 2025 09:45:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 28:
> 
>> 26:  * @bug 8369950
>> 27:  * @library /test/lib
>> 28:  * @summary TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException
> 
> Nit - as per the jtreg tag order recommendation, the `@summary` should come before the `@library` https://openjdk.org/jtreg/tag-spec.html#ORDER

Also, this test doesn't exercise the BouncyCastle provider. Would it be better to change this line to say:


@summary Test that the HttpsURLConnection does not set IPv6 address literals for SNI hostname during TLS handshake

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580420910

From djelinski at openjdk.org  Tue Dec  2 09:49:55 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 2 Dec 2025 09:49:55 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
Message-ID: <K9Zu6z_fguF3Av8rY7-90ovsddh6AcKRyHYTM0tZ83A=.ed0806c5-a03f-4a5e-ae21-6cd792d21b1b@github.com>

On Tue, 2 Dec 2025 09:37:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 71:
> 
>> 69:      * currently 3 minutes by default, but you might try to be
>> 70:      * smart about it....
>> 71:      */
> 
> I am not too familiar with these style of tests, but it looks like there are several similar ones in the `javax/net/ssl` area. Would you know if these comments are still accurate and up to date? In other words, do we need these comments in this test?

Let's clean this up in a follow-up PR. There's 60+ files with the same comment.

> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 97:
> 
>> 95:         bw.write("HTTP/1.1 200 OK\r\n\r\n\r\n");
>> 96:         bw.flush();
>> 97:         Thread.sleep(5000);
> 
> Is the sleep() necessary for this test?

Again, copy/paste. Deserves a separate PR to clean up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580403353
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580408136

From jpai at openjdk.org  Tue Dec  2 09:54:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 09:54:46 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <K9Zu6z_fguF3Av8rY7-90ovsddh6AcKRyHYTM0tZ83A=.ed0806c5-a03f-4a5e-ae21-6cd792d21b1b@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
 <K9Zu6z_fguF3Av8rY7-90ovsddh6AcKRyHYTM0tZ83A=.ed0806c5-a03f-4a5e-ae21-6cd792d21b1b@github.com>
Message-ID: <OOGDP_g6tQEhmvVmgFbsZWOVUewYY2SfL80dhiZGjUU=.f1d7e848-ec53-4d5f-830d-b696cf64c362@github.com>

On Tue, 2 Dec 2025 09:42:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 71:
>> 
>>> 69:      * currently 3 minutes by default, but you might try to be
>>> 70:      * smart about it....
>>> 71:      */
>> 
>> I am not too familiar with these style of tests, but it looks like there are several similar ones in the `javax/net/ssl` area. Would you know if these comments are still accurate and up to date? In other words, do we need these comments in this test?
>
> Let's clean this up in a follow-up PR. There's 60+ files with the same comment.

Yes, doing this as a separate PR is fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580437023

From jpai at openjdk.org  Tue Dec  2 09:58:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 09:58:19 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
Message-ID: <nW4B9BxVz4aA1_IwM4kpbxIywTmGbWaTeJ3bV7IVEu8=.4c1c930f-e1c1-4ae7-961b-b91ea0eefcc2@github.com>

On Tue, 2 Dec 2025 09:39:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 165:
> 
>> 163:      */
>> 164:     SubjectAltNameIPv6() throws Exception {
>> 165:         if (separateServerThread) {
> 
> Are these if/else blocks needed or could we simplify the test to just expect the server and client to run as separate threads?

I spoke to Daniel and I agree with him that it's OK to leave this in current form and if needed clean up as a follow up when doing the same for the rest of these tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580451134

From aph at openjdk.org  Tue Dec  2 10:07:41 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 2 Dec 2025 10:07:41 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v2]
In-Reply-To: <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>
Message-ID: <i6wrfDh3bM4iKL6PTIBvBt09nNJS6Za9Pqv1nOl7AuE=.b2136597-38ef-41a6-8ff1-517a5790cebe@github.com>

On Mon, 1 Dec 2025 22:19:09 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 3162:

> 3160:     int l = (size == 0b01) ? ((lane >> 1) & 1) : (lane & 1);
> 3161:     int m = lane & 1;
> 3162:     assert((size == 0b10 ? lane < 4 : lane < 7));

Why `lane < 7`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2580486240

From aph at openjdk.org  Tue Dec  2 10:10:32 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 2 Dec 2025 10:10:32 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v2]
In-Reply-To: <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
 <nSkGY6VVBNf0vfbCIxMvDcURh7YgrECg7O2h8Dei3Lo=.ed9973ea-fb2e-45c1-92fb-e9f74d34d337@github.com>
Message-ID: <XL_0hfh1uns2bWswH6Nxi_Mz9cz423Bxe4DKHkgUon4=.70c3d22d-e00e-4c7f-8d31-14f9a1fbcc5f@github.com>

On Mon, 1 Dec 2025 22:19:09 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 3194:

> 3192:     _umullv(Vd, Ta, Vn, Tb, Vm, Ts, lane);
> 3193:   }
> 3194: 

These seem to be essentially identical except for one assertion.

Suggestion: as elsewhere in class Assembler,` #define INSN` for the common pattern, then use it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27946#discussion_r2580496108

From schernyshev at openjdk.org  Tue Dec  2 10:27:05 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 10:27:05 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <Hm63cKxAO6ZBOq1Eg5xlHJLzAiwFjNg3eGr6OUl_mzU=.6edb21e2-25fb-430e-bdfc-a9d4baa6c0f9@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Hm63cKxAO6ZBOq1Eg5xlHJLzAiwFjNg3eGr6OUl_mzU=.6edb21e2-25fb-430e-bdfc-a9d4baa6c0f9@github.com>
Message-ID: <hnJujIp-Kky0aFfphXeJ6acOxydCP8_msuV1exVZz8s=.4e620125-cc7b-41f6-9781-fe4b5183d284@github.com>

On Tue, 2 Dec 2025 09:16:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Sergey, the copyright year on `HttpsClient` will need an update from `2001, 2024,` to `2001, 2025,`

Thanks @jaikiran. That's correct. I will update the headers.

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3601305090

From azeller at openjdk.org  Tue Dec  2 10:49:54 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Tue, 2 Dec 2025 10:49:54 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
Message-ID: <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>

On Mon, 1 Dec 2025 17:54:21 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - Stop catching exception to make test able to fail
> - Remove java-only test variation that cannot fail
> - Reduce fuzz repeat count

The change looks good, but you might consider using jdk.test.lib.RandomFactory. It allows to get and set a seed that is also printed at every run to make a failure easily reproducible.

And as the test now fails on aarch64 perhaps it should be excluded there and a bug should be opened - or is the behavior expected on aarch64 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3601395815

From mullan at openjdk.org  Tue Dec  2 13:29:20 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 Dec 2025 13:29:20 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
Message-ID: <22ewjC92iHWcTdsRXiGYIbaYO6H8LSL__1ZuCO0BiUc=.f7516646-06d4-4863-b395-68d260865c47@github.com>

On Fri, 28 Nov 2025 18:35:12 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix 8352728.
>> 
>> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following:
>> 
>> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
>> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
>> 
>> #### Windows Case
>> 
>> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
>> 
>> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - Slightly improve ConfigFileTestDirPermissions
>    
>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>    temporary directory cleanup.

test/jdk/java/security/Security/ConfigFileTestDirPermissions.java line 70:

> 68:                 try {
> 69:                     jdk.toRealPath();
> 70:                     throw new jtreg.SkippedException("Must run non-elevated!");

Do you expect this to be a non-common situation? Just wondering if we should treat this as a failure instead of skipping.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2581185162

From mullan at openjdk.org  Tue Dec  2 13:37:28 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 Dec 2025 13:37:28 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v11]
In-Reply-To: <aJSbqHzAXEPP9JwyjDepiLDLlRcXQWTSUG4MlWSP8JU=.a1784e7b-055e-4ae7-978b-ae83fa556006@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <f1LGOwCPsznfyr2PPV8WapM4335Th4oEs4kR_lT8bBM=.50f62482-94c8-490a-9e02-20c3d2958ea0@github.com>
 <tXOYQ_nde9pAdy2Gn_DhUzmLm9Lu02sf-mGI87I819Q=.758751d0-3684-4fdf-be8b-222ee93e13e3@github.com>
 <_HUUN67SsUDKiW4mhpPssp7bTD-BIiz0Ho1qyltjYeY=.afae4482-6158-4e73-aee1-351d1251d759@github.com>
 <aJSbqHzAXEPP9JwyjDepiLDLlRcXQWTSUG4MlWSP8JU=.a1784e7b-055e-4ae7-978b-ae83fa556006@github.com>
Message-ID: <OJokeatkY5HLz91x8AeN24zkNrqhSnU9L3tyydJTeIw=.6139306a-d442-44ee-986c-9c65cad12966@github.com>

On Fri, 28 Nov 2025 18:29:42 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>>> Hi folks, as we know [JDK 26 enters Rampdown Phase One next week](https://mail.openjdk.org/pipermail/jdk-dev/2025-November/010639.html) on Thursday, 4 December.
>>> 
>>> Please let me know if we'll want this fix to move forward before that happens, and please note that soon I will need to focus on the OJVG work.
>>> 
>>> If you prefer, I'm fine with using `path.toRealPath()` instead of `path.toFile().getCanonicalFile().toPath()`. That would keep relative includes broken in _Windows_ UWP Java applications and from _Linux_ anonymous pipes and files (where they don't make a lot of sense anyway). But that is better than the current status quo (_Windows_ UWP Java applications break if they load the `java.security.Security` class).
>>> 
>>> Just let me know if you want to proceed that way and I will, also removing the part of the new test that will break by that change.
>> 
>> Yes, I agree that seems like a way forward, if not perfect. @AlanBateman ok with you?
>
> @seanjmullan: with the hope of moving this forward before the JDK 26 Rampdown, I went ahead and implemented the remaining two suggestions. I have re-run the listed test categories from the description in _Windows_ and _Linux_, everything is passing. It should be ready for a final review now.

@franferrax I think it would be useful to update the PR description now that the fix is different than what was originally proposed.

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3602101766

From mullan at openjdk.org  Tue Dec  2 13:57:44 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 Dec 2025 13:57:44 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <2y7XZvrGxz-h2azJRkuC-4K4h4QBA4GdrfHwE3426oA=.ad803ea6-ebea-4bfa-bd4a-58fadec9093c@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
 <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
 <41RTmykCC1A-4ExHq7HWsqmlS5lobm0PVxDub7P85j0=.281cee13-471e-4863-917e-0bf3094335b6@github.com>
 <2y7XZvrGxz-h2azJRkuC-4K4h4QBA4GdrfHwE3426oA=.ad803ea6-ebea-4bfa-bd4a-58fadec9093c@github.com>
Message-ID: <LBAoDLHX4VrHwsONt4foz92g8MeFgdwCOeMtJPyq028=.f4668d90-88a2-43cf-859a-8a4759b1b7a7@github.com>

On Fri, 28 Nov 2025 18:30:29 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> We can make this an `InternalError`, the most common failure case is one of the two files nonexistence. So before proceeding I want to make sure you are aware that this would make the following filesystem race-condition noticeable:
>> 
>> 1. File **A** is included, _OpenJDK_ starts reading it
>> 2. File **A** is deleted by an administrator who is changing the settings
>>     * But _OpenJDK_ keeps it open, this is possible in _Linux_
>> 3. File **B** is included, _OpenJDK_ wants to check for a circular inclusion
>> 4. `Files.isSameFile(path, activePath)` throws `IOException` when `path` is file **B** and `activePath` is file **A** (now deleted)
>> 5. `IOException` isn't ignored but wrapped in an `InternalError` and thrown
>> 
>> Current code wouldn't fail in this scenario, although I recognize it's a corner case. I decided to ignore the exception under the assumption that `Files.isSameFile(x, y)` can be treated as `false` in this context for cases in which either `x` or `y` is nonexistent.
>
> Addressed in 4e7206c082e4b0152d999b32eba0063a506eff67.

Ok, thanks for the explanation. I agree it is a rare case, but now I think maybe a debug statement is better than throwing an `InternalError` since it seems like the code can still recover and continue w/o unexpected behavior - would you agree?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2581303847

From mullan at openjdk.org  Tue Dec  2 14:15:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 Dec 2025 14:15:58 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
Message-ID: <IStCignijKSnbT7wdpK9lwjraJEZugbQb12PAlREmyg=.03694ee8-3284-49fa-b614-4152da34d0d1@github.com>

On Fri, 28 Nov 2025 18:35:12 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix 8352728.
>> 
>> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following:
>> 
>> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
>> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
>> 
>> #### Windows Case
>> 
>> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
>> 
>> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - Slightly improve ConfigFileTestDirPermissions
>    
>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>    temporary directory cleanup.

test/jdk/java/security/Security/ConfigFileTestAnonymousPipes.sh line 1:

> 1: #

This test failed on linux-x64 in our test systems. Here's a snippet of the logfile:


properties[0x3|main|Security.java:160|2025-12-02 13:35:48.066]: unable to load security properties from <(echo include /dev/stdin)
java.io.FileNotFoundException: <(echo include /dev/stdin)
	at java.base/java.security.Security$SecPropLoader.loadExtraFromPath(Security.java:209)
	at java.base/java.security.Security$SecPropLoader.loadExtraHelper(Security.java:178)
	at java.base/java.security.Security$SecPropLoader.loadExtra(Security.java:157)
	at java.base/java.security.Security$SecPropLoader.loadAll(Security.java:122)
	at java.base/java.security.Security.initialize(Security.java:337)
	at java.base/java.security.Security.<clinit>(Security.java:326)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1195)
	at java.base/java.lang.invoke.MethodHandles$Lookup.ensureInitialized(MethodHandles.java:2750)
	at java.base/jdk.internal.access.SharedSecrets.ensureClassInitialized(SharedSecrets.java:504)
	at java.base/jdk.internal.access.SharedSecrets.getJavaSecurityPropertiesAccess(SharedSecrets.java:320)
	at java.base/sun.launcher.SecuritySettings.printSecurityProperties(SecuritySettings.java:88)
	at java.base/sun.launcher.SecuritySettings.printSecuritySettings(SecuritySettings.java:63)
	at java.base/sun.launcher.LauncherHelper.showSettings(LauncherHelper.java:172)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2581371292

From schernyshev at openjdk.org  Tue Dec  2 14:29:34 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 14:29:34 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:

 - addressed more review comments
 - addressed review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28577/files
  - new: https://git.openjdk.org/jdk/pull/28577/files/7d1a9032..c388c253

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

  Stats: 113 lines in 2 files changed: 17 ins; 69 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/28577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28577/head:pull/28577

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

From dfuchs at openjdk.org  Tue Dec  2 14:29:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 Dec 2025 14:29:36 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <SrHKEuWn5olIN4mv7WqvmlPoX2xntwuLPadNteXa4Gk=.08751532-3d10-4eec-a3c9-9827dd1960cc@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

> @[sercher](https://github.com/sercher) sercher marked this pull request as draft [2 hours ago](https://github.com/openjdk/jdk/pull/28577#event-21302029904)

@sercher did you intend to put this PR back into DRAFT?

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3601855196

From schernyshev at openjdk.org  Tue Dec  2 14:29:37 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 14:29:37 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException
In-Reply-To: <hnJujIp-Kky0aFfphXeJ6acOxydCP8_msuV1exVZz8s=.4e620125-cc7b-41f6-9781-fe4b5183d284@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Hm63cKxAO6ZBOq1Eg5xlHJLzAiwFjNg3eGr6OUl_mzU=.6edb21e2-25fb-430e-bdfc-a9d4baa6c0f9@github.com>
 <hnJujIp-Kky0aFfphXeJ6acOxydCP8_msuV1exVZz8s=.4e620125-cc7b-41f6-9781-fe4b5183d284@github.com>
Message-ID: <RFkoMoOj6XPxDCUrIdOejsbCFUfVEgBpV_2KmqC9DcI=.89479bf0-856b-4ddf-b8f6-1db60ba4ac8a@github.com>

On Tue, 2 Dec 2025 10:23:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hello Sergey, the copyright year on `HttpsClient` will need an update from `2001, 2024,` to `2001, 2025,`
>
>> Hello Sergey, the copyright year on `HttpsClient` will need an update from `2001, 2024,` to `2001, 2025,`
> 
> Thanks @jaikiran. That's correct. I will update the headers.

> @sercher did you intend to put this PR back into DRAFT?

it had already the "sponsor" label when more reviews came. I changed to draft intentionally so no one would sponsor by mistake.

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3602161053

From vyazici at openjdk.org  Tue Dec  2 14:29:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 2 Dec 2025 14:29:41 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
Message-ID: <PoeBw3wuGY9DfpYrIinzpo9-OPvv3KkSqi8iMl9c5nM=.8c999e41-2ae8-4e1d-9663-1e9d869875bc@github.com>

On Tue, 2 Dec 2025 14:25:36 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addressed more review comments
>  - addressed review comments

src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 1:

> 1: /*

Copyright year needs a bump.

src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 476:

> 474:                     // host has been set previously for SSLSocketImpl
> 475:                     if (!(s instanceof SSLSocketImpl) &&
> 476:                             !IPAddressUtil.isIPv4LiteralAddress(host) &&

This introduces a new behavior for both IPv4 and IPv6, yet we only verify the IPv6 behavior. Shouldn't we also verify that when the provided host is an IPv4 literal, `setServerNames()` is left untouched?

src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478:

> 476:                             !IPAddressUtil.isIPv4LiteralAddress(host) &&
> 477:                             !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' &&
> 478:                                 IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1))

There is one more place in `sun.net.www`, which is in this very class, that


(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']') { return host.substring(1, host.length() - 1)


logic is practiced. Would it make sense to refactor this into a `private static Optional<String> ipv6FromHost(String host)` method, preferably with some short explanation in the method's Javadoc on why we do this?

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 1:

> 1: /*

FWIW, _without_ the proposed `HttpsClient` changes, I can reproduce


java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
	at java.base/java.net.IDN.toASCIIInternal(IDN.java:310)
	at java.base/java.net.IDN.toASCII(IDN.java:139)
	at java.base/javax.net.ssl.SNIHostName.<init>(SNIHostName.java:114)
	at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:475)


using this test against `master` (i.e., 7278d2e8e58). Put another way, AFAICT, fix and test is legit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580621834
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580726453
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580631079
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580718016

From schernyshev at openjdk.org  Tue Dec  2 14:29:43 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 14:29:43 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <PoeBw3wuGY9DfpYrIinzpo9-OPvv3KkSqi8iMl9c5nM=.8c999e41-2ae8-4e1d-9663-1e9d869875bc@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <PoeBw3wuGY9DfpYrIinzpo9-OPvv3KkSqi8iMl9c5nM=.8c999e41-2ae8-4e1d-9663-1e9d869875bc@github.com>
Message-ID: <IHcL_eqNIg2ldJ3DvM1CqFcCgJHscX9C0MMreyo4XMc=.8bebe0db-6c3a-4d8c-96df-a33808aa680c@github.com>

On Tue, 2 Dec 2025 11:14:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressed more review comments
>>  - addressed review comments
>
> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 476:
> 
>> 474:                     // host has been set previously for SSLSocketImpl
>> 475:                     if (!(s instanceof SSLSocketImpl) &&
>> 476:                             !IPAddressUtil.isIPv4LiteralAddress(host) &&
> 
> This introduces a new behavior for both IPv4 and IPv6, yet we only verify the IPv6 behavior. Shouldn't we also verify that when the provided host is an IPv4 literal, `setServerNames()` is left untouched?

@vy The test excercises the same code path as in the BCJSSE case, that throws an exception on non-LDH symbols. Segments of IPv4 literal adresses are all LDH, so they do not trigger any exception. Adding an IPAddressUtil.isIPv4LiteralAddress() check in the above condition is purely to mirror SSLSocketImpl behavior, as I thought initially.

On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1' is requested?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580917249

From schernyshev at openjdk.org  Tue Dec  2 14:29:44 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 14:29:44 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <IHcL_eqNIg2ldJ3DvM1CqFcCgJHscX9C0MMreyo4XMc=.8bebe0db-6c3a-4d8c-96df-a33808aa680c@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <PoeBw3wuGY9DfpYrIinzpo9-OPvv3KkSqi8iMl9c5nM=.8c999e41-2ae8-4e1d-9663-1e9d869875bc@github.com>
 <IHcL_eqNIg2ldJ3DvM1CqFcCgJHscX9C0MMreyo4XMc=.8bebe0db-6c3a-4d8c-96df-a33808aa680c@github.com>
Message-ID: <5Xi3KzSpKO5zUPBdESbgG7zc7JQmTjwjWgyVxiqN3Ic=.2464c8db-275e-43b7-9893-4c7cefac9f0e@github.com>

On Tue, 2 Dec 2025 12:15:36 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 476:
>> 
>>> 474:                     // host has been set previously for SSLSocketImpl
>>> 475:                     if (!(s instanceof SSLSocketImpl) &&
>>> 476:                             !IPAddressUtil.isIPv4LiteralAddress(host) &&
>> 
>> This introduces a new behavior for both IPv4 and IPv6, yet we only verify the IPv6 behavior. Shouldn't we also verify that when the provided host is an IPv4 literal, `setServerNames()` is left untouched?
>
> @vy The test excercises the same code path as in the BCJSSE case, that throws an exception on non-LDH symbols. Segments of IPv4 literal adresses are all LDH, so they do not trigger any exception. Adding an IPAddressUtil.isIPv4LiteralAddress() check in the above condition is purely to mirror SSLSocketImpl behavior, as I thought initially.
> 
> On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1' is requested?

@djelinski would you think such a negative test is needed here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581325563

From schernyshev at openjdk.org  Tue Dec  2 14:29:45 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 14:29:45 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <QX9h5Z2hBg1I6EgYIJO6kfKPPoWt5PQp23eR0w2lbYw=.b46b8106-1ed2-4c4e-a557-3af1e46f62a7@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <QX9h5Z2hBg1I6EgYIJO6kfKPPoWt5PQp23eR0w2lbYw=.b46b8106-1ed2-4c4e-a557-3af1e46f62a7@github.com>
Message-ID: <UMw_gK9uCzSqvJl5T84kyeejJPvgwld2E72Np97Jr5U=.c8805aa4-49cf-4730-aaf9-aea11d7db231@github.com>

On Tue, 2 Dec 2025 09:29:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressed more review comments
>>  - addressed review comments
>
> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478:
> 
>> 476:                             !IPAddressUtil.isIPv4LiteralAddress(host) &&
>> 477:                             !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' &&
>> 478:                                 IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1))
> 
> The `host` value here comes from `URL.getHost()` which specifies that it returns an IPv6 address enclosed in `[]`brackets. So what you have here looks fine to me.
> 
> One additional thing I would suggest is to make this `protected String host` field of this class `final`. It currently gets assigned in the constructor of the `HttpClient` and `HttpsClient` and making this `final` would give an extra assurance that its value will always be coming from `URL.getHost()` call. 
> 
> These 2 `sun.net.www.http.HttpClient` and `HttpsClient` classes are internal to the JDK, so changing this protected field to final shouldn't cause any issues for application code.

@jaikiran I think this deserves a separate issue. I could file a bug for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580621085

From jpai at openjdk.org  Tue Dec  2 14:29:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 14:29:46 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <UMw_gK9uCzSqvJl5T84kyeejJPvgwld2E72Np97Jr5U=.c8805aa4-49cf-4730-aaf9-aea11d7db231@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <QX9h5Z2hBg1I6EgYIJO6kfKPPoWt5PQp23eR0w2lbYw=.b46b8106-1ed2-4c4e-a557-3af1e46f62a7@github.com>
 <UMw_gK9uCzSqvJl5T84kyeejJPvgwld2E72Np97Jr5U=.c8805aa4-49cf-4730-aaf9-aea11d7db231@github.com>
Message-ID: <kumB899N_b-QKm0uXQatTU9gsSxpG5Vuty6FhkBP51c=.e7b5bac2-e72d-4d88-bedf-f282375ba77f@github.com>

On Tue, 2 Dec 2025 10:42:02 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478:
>> 
>>> 476:                             !IPAddressUtil.isIPv4LiteralAddress(host) &&
>>> 477:                             !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' &&
>>> 478:                                 IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1))
>> 
>> The `host` value here comes from `URL.getHost()` which specifies that it returns an IPv6 address enclosed in `[]`brackets. So what you have here looks fine to me.
>> 
>> One additional thing I would suggest is to make this `protected String host` field of this class `final`. It currently gets assigned in the constructor of the `HttpClient` and `HttpsClient` and making this `final` would give an extra assurance that its value will always be coming from `URL.getHost()` call. 
>> 
>> These 2 `sun.net.www.http.HttpClient` and `HttpsClient` classes are internal to the JDK, so changing this protected field to final shouldn't cause any issues for application code.
>
> @jaikiran I think this deserves a separate issue. I could file a bug for this.

Yes, it's OK with me if you don't change this field to `final` in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580627052

From dfuchs at openjdk.org  Tue Dec  2 14:29:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 Dec 2025 14:29:48 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <PoeBw3wuGY9DfpYrIinzpo9-OPvv3KkSqi8iMl9c5nM=.8c999e41-2ae8-4e1d-9663-1e9d869875bc@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <PoeBw3wuGY9DfpYrIinzpo9-OPvv3KkSqi8iMl9c5nM=.8c999e41-2ae8-4e1d-9663-1e9d869875bc@github.com>
Message-ID: <jvfng6mGYKjiAfjswiHQcrw3CeXT3SRcS5gKs2rguNc=.f4664a69-c9e7-4fbc-9dbb-f2509fd9b3a4@github.com>

On Tue, 2 Dec 2025 10:45:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressed more review comments
>>  - addressed review comments
>
> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478:
> 
>> 476:                             !IPAddressUtil.isIPv4LiteralAddress(host) &&
>> 477:                             !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' &&
>> 478:                                 IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1))
> 
> There is one more place in `sun.net.www`, which is in this very class, that
> 
> 
> (host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']') { return host.substring(1, host.length() - 1)
> 
> 
> logic is practiced. Would it make sense to refactor this into a `private static Optional<String> ipv6FromHost(String host)` method, preferably with some short explanation in the method's Javadoc on why we do this?

The same thought occurred to me but I'd rather keep refactoring at a minimum in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581000260

From schernyshev at openjdk.org  Tue Dec  2 14:29:50 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 14:29:50 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <y8TpJOSbXJ8y1UPcBl3KdB9PhYt-5Q0IJyeQ3uWlNiI=.4706926b-95dd-47ed-8add-50e2044fc577@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
 <y8TpJOSbXJ8y1UPcBl3KdB9PhYt-5Q0IJyeQ3uWlNiI=.4706926b-95dd-47ed-8add-50e2044fc577@github.com>
Message-ID: <DaLoz0ibsmWdTtYZ3mjgPa5ZrmPizpcDCZx59SYZJUM=.609195f5-be03-431a-93b8-580fbf21816d@github.com>

On Tue, 2 Dec 2025 09:47:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 28:
>> 
>>> 26:  * @bug 8369950
>>> 27:  * @library /test/lib
>>> 28:  * @summary TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException
>> 
>> Nit - as per the jtreg tag order recommendation, the `@summary` should come before the `@library` https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> Also, this test doesn't exercise the BouncyCastle provider. Would it be better to change this line to say:
> 
> 
> @summary Test that the HttpsURLConnection does not set IPv6 address literals for SNI hostname during TLS handshake

> Nit - as per the jtreg tag order recommendation, the `@summary` should come before the `@library` https://openjdk.org/jtreg/tag-spec.html#ORDER

Thanks @jaikiran , i will update the order and the summary text. The BouncyCastle came here from the title of the issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580611708

From myankelevich at openjdk.org  Tue Dec  2 14:29:52 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 2 Dec 2025 14:29:52 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
Message-ID: <AIB8evccHuhTp--ae15jKVqXV4bgD2oEv2s4OMLb0SQ=.cb6f4983-736c-4c27-9389-4f946b8ce089@github.com>

On Tue, 2 Dec 2025 14:25:36 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addressed more review comments
>  - addressed review comments

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 32:

> 30:  */
> 31: 
> 32: import javax.net.ssl.*;

nit: wildcard imports

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 50:

> 48:      * Turn on SSL debugging?
> 49:      */
> 50:     static boolean debug = false;

Could you please change this to be a env variable? something like
```java 
     static boolean debug = Boolean.getBoolean("test.debug");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580968937
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580967566

From schernyshev at openjdk.org  Tue Dec  2 14:29:54 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 14:29:54 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <AIB8evccHuhTp--ae15jKVqXV4bgD2oEv2s4OMLb0SQ=.cb6f4983-736c-4c27-9389-4f946b8ce089@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <AIB8evccHuhTp--ae15jKVqXV4bgD2oEv2s4OMLb0SQ=.cb6f4983-736c-4c27-9389-4f946b8ce089@github.com>
Message-ID: <MZjlrkrWTFrO__VS74DEEQOkDjm09UhV5pyR8bIu1GM=.61e4080e-da46-469f-956b-8888e4dfb206@github.com>

On Tue, 2 Dec 2025 12:30:21 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressed more review comments
>>  - addressed review comments
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 32:
> 
>> 30:  */
>> 31: 
>> 32: import javax.net.ssl.*;
> 
> nit: wildcard imports

Thanks @myankelev . Done.

> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 50:
> 
>> 48:      * Turn on SSL debugging?
>> 49:      */
>> 50:     static boolean debug = false;
> 
> Could you please change this to be a env variable? something like
> ```java 
>      static boolean debug = Boolean.getBoolean("test.debug");

Thanks @myankelev . Accepted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581412259
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581412017

From schernyshev at openjdk.org  Tue Dec  2 14:29:56 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 14:29:56 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <OOGDP_g6tQEhmvVmgFbsZWOVUewYY2SfL80dhiZGjUU=.f1d7e848-ec53-4d5f-830d-b696cf64c362@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
 <K9Zu6z_fguF3Av8rY7-90ovsddh6AcKRyHYTM0tZ83A=.ed0806c5-a03f-4a5e-ae21-6cd792d21b1b@github.com>
 <OOGDP_g6tQEhmvVmgFbsZWOVUewYY2SfL80dhiZGjUU=.f1d7e848-ec53-4d5f-830d-b696cf64c362@github.com>
Message-ID: <IsnONMh6d8jY_KMJE9cbLURgnOgG-J6iZ0Y0I_5sw8E=.12ea55f7-9b31-4f84-be0d-56ea51fad87d@github.com>

On Tue, 2 Dec 2025 09:51:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Let's clean this up in a follow-up PR. There's 60+ files with the same comment.
>
> Yes, doing this as a separate PR is fine with me.

@jaikiran Let me clean up the comments that are not anymore accurate in this particular PR. I personally try to avoid this type of changes that only touch the whitespace or comments blocks, including the copyright header ones, because they increase the number of connections between unrelated changes, that makes the fix less portable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580598800

From jpai at openjdk.org  Tue Dec  2 14:29:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 14:29:57 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <IsnONMh6d8jY_KMJE9cbLURgnOgG-J6iZ0Y0I_5sw8E=.12ea55f7-9b31-4f84-be0d-56ea51fad87d@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <qCwCFD5R7mwt6fqGGE7675rtLIovxYYlYt39mqLoEGU=.c1a18849-e30f-4498-9b61-fb03a50a250e@github.com>
 <K9Zu6z_fguF3Av8rY7-90ovsddh6AcKRyHYTM0tZ83A=.ed0806c5-a03f-4a5e-ae21-6cd792d21b1b@github.com>
 <OOGDP_g6tQEhmvVmgFbsZWOVUewYY2SfL80dhiZGjUU=.f1d7e848-ec53-4d5f-830d-b696cf64c362@github.com>
 <IsnONMh6d8jY_KMJE9cbLURgnOgG-J6iZ0Y0I_5sw8E=.12ea55f7-9b31-4f84-be0d-56ea51fad87d@github.com>
Message-ID: <BYMIIoGYGa11w9HlNfmjKvDhRC4V_S4obZSiTjkJr08=.80afeb97-c779-46d1-bac4-c187e61ff43d@github.com>

On Tue, 2 Dec 2025 10:34:57 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Yes, doing this as a separate PR is fine with me.
>
> @jaikiran Let me clean up the comments that are not anymore accurate in this particular PR. I personally try to avoid this type of changes that only touch the whitespace or comments blocks, including the copyright header ones, because they increase the number of connections between unrelated changes, that makes the fix less portable.

@sercher, it's OK if you leave the test in the current form. Just fixing the `@summary` test on the test definition should be enough. I have spoken to others and the agreement is that since we already have similar tests in this area, it probably is a better thing to let this test stay in this manner instead of devicing some new way to test this. Sorry about the previous guidance to update these test comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580623450

From rrich at openjdk.org  Tue Dec  2 14:45:09 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 2 Dec 2025 14:45:09 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v7]
In-Reply-To: <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>
Message-ID: <QSjd2ii1xcMhG5c9BeIXuXrq5qzLyUabNYFpLZX3S70=.8f860969-3dea-4536-88b0-afb93ab546b2@github.com>

On Mon, 1 Dec 2025 10:27:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr 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 nine additional commits since the last revision:
> 
>  - Minor simplification.
>  - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
>  - Fix missing whitespace.
>  - Address review comments.
>  - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
>  - Remove K from AES_Crypt
>  - More minor cleanup.
>  - Improve comment and minor cleanup.
>  - 8371820: Further AES performance improvements for key schedule generation

The changes look good to me.
Thanks, Richard.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28299#pullrequestreview-3530496843

From djelinski at openjdk.org  Tue Dec  2 14:50:04 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 2 Dec 2025 14:50:04 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <5Xi3KzSpKO5zUPBdESbgG7zc7JQmTjwjWgyVxiqN3Ic=.2464c8db-275e-43b7-9893-4c7cefac9f0e@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <PoeBw3wuGY9DfpYrIinzpo9-OPvv3KkSqi8iMl9c5nM=.8c999e41-2ae8-4e1d-9663-1e9d869875bc@github.com>
 <IHcL_eqNIg2ldJ3DvM1CqFcCgJHscX9C0MMreyo4XMc=.8bebe0db-6c3a-4d8c-96df-a33808aa680c@github.com>
 <5Xi3KzSpKO5zUPBdESbgG7zc7JQmTjwjWgyVxiqN3Ic=.2464c8db-275e-43b7-9893-4c7cefac9f0e@github.com>
Message-ID: <Mjjj0j9tUB5JYow7B2AUTM8bSdxAIRdzakhH0aE-Mjk=.8ae3faba-bbf7-4ee6-8493-df968bcb20a1@github.com>

On Tue, 2 Dec 2025 14:01:20 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> @vy The test excercises the same code path as in the BCJSSE case, that throws an exception on non-LDH symbols. Segments of IPv4 literal adresses are all LDH, so they do not trigger any exception. Adding an IPAddressUtil.isIPv4LiteralAddress() check in the above condition is purely to mirror SSLSocketImpl behavior, as I thought initially.
>> 
>> On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1' is requested?
>
> @djelinski would you think such a negative test is needed here?

> On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1/' is requested?

No, such test would fail whether we use setServerNames or not.

I think @vy is asking for a check that the SSLParameters passed to SSLSocket#setSSLParameters have no serverNames configured. That should be reasonably easy to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581507151

From mdoerr at openjdk.org  Tue Dec  2 14:50:09 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 2 Dec 2025 14:50:09 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v7]
In-Reply-To: <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>
Message-ID: <Bwrn_jk0RCPXZPpprKxNeDkzl3sjSYQ69FDjargeD7I=.13e09715-4dd5-4dd5-a31a-a175e8dfdf17@github.com>

On Mon, 1 Dec 2025 10:27:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr 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 nine additional commits since the last revision:
> 
>  - Minor simplification.
>  - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
>  - Fix missing whitespace.
>  - Address review comments.
>  - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
>  - Remove K from AES_Crypt
>  - More minor cleanup.
>  - Improve comment and minor cleanup.
>  - 8371820: Further AES performance improvements for key schedule generation

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3602426006

From myankelevich at openjdk.org  Tue Dec  2 15:05:29 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 2 Dec 2025 15:05:29 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
Message-ID: <TysOFCScMmUVGHDbWRRPbpCcc8CVGx6SJFfbZDmfC5I=.31e8c597-d7f2-4dc9-ad00-cacbc904bd6d@github.com>

On Tue, 2 Dec 2025 14:29:34 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addressed more review comments
>  - addressed review comments

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 65:

> 63:      * Turn on SSL debugging?
> 64:      */
> 65:     static boolean debug = Boolean.getBoolean("test.debug");

Actually, do we even need this? Wouldn't it be easier to set `javax.net.debug` in the `@run` call? It's `othervm` already. 
Sorry for confusion, didn't think about it at first

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581583526

From schernyshev at openjdk.org  Tue Dec  2 15:20:02 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 15:20:02 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <TysOFCScMmUVGHDbWRRPbpCcc8CVGx6SJFfbZDmfC5I=.31e8c597-d7f2-4dc9-ad00-cacbc904bd6d@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <TysOFCScMmUVGHDbWRRPbpCcc8CVGx6SJFfbZDmfC5I=.31e8c597-d7f2-4dc9-ad00-cacbc904bd6d@github.com>
Message-ID: <kxQJhHMAHM8yhaQyvVvI9DoE6QOpQprRLesfTjmvLgo=.9fb2216e-15d4-4776-9bb1-66b77ce4fe99@github.com>

On Tue, 2 Dec 2025 15:02:23 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressed more review comments
>>  - addressed review comments
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 65:
> 
>> 63:      * Turn on SSL debugging?
>> 64:      */
>> 65:     static boolean debug = Boolean.getBoolean("test.debug");
> 
> Actually, do we even need this? Wouldn't it be easier to set `javax.net.debug` in the `@run` call? It's `othervm` already. 
> Sorry for confusion, didn't think about it at first

@myankelev should I revert the suggested change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581641252

From myankelevich at openjdk.org  Tue Dec  2 15:25:09 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 2 Dec 2025 15:25:09 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <kxQJhHMAHM8yhaQyvVvI9DoE6QOpQprRLesfTjmvLgo=.9fb2216e-15d4-4776-9bb1-66b77ce4fe99@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <TysOFCScMmUVGHDbWRRPbpCcc8CVGx6SJFfbZDmfC5I=.31e8c597-d7f2-4dc9-ad00-cacbc904bd6d@github.com>
 <kxQJhHMAHM8yhaQyvVvI9DoE6QOpQprRLesfTjmvLgo=.9fb2216e-15d4-4776-9bb1-66b77ce4fe99@github.com>
Message-ID: <dkgZpBB-_wfd7t0hHa0ezyQknCzpeglf0M3Hv2qp6lc=.bf3a5db9-670c-4704-97c0-fa2b68465daf@github.com>

On Tue, 2 Dec 2025 15:17:21 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 65:
>> 
>>> 63:      * Turn on SSL debugging?
>>> 64:      */
>>> 65:     static boolean debug = Boolean.getBoolean("test.debug");
>> 
>> Actually, do we even need this? Wouldn't it be easier to set `javax.net.debug` in the `@run` call? It's `othervm` already. 
>> Sorry for confusion, didn't think about it at first
>
> @myankelev should I revert the suggested change?

Nope, it's fine as it is now, but if you want you can remove this debug flag completely. It's up to you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581661759

From dfuchs at openjdk.org  Tue Dec  2 15:30:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 Dec 2025 15:30:47 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
Message-ID: <ipVCrGYaL_YkL29V1cB1slo-ledZNrQjojT8Z2TeqTw=.4eabc9ee-64de-4ce8-8146-7416df49957f@github.com>

On Tue, 2 Dec 2025 14:29:34 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addressed more review comments
>  - addressed review comments

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 137:

> 135:         if (debug) {
> 136:             System.setProperty("javax.net.debug", "all");
> 137:         }

If it's the only place where `debug` is used then I believe @myankelev is right and we don't need it.
You can put an `@comment` to remind the reader that they can pass the  `-Djavax.net.debug=all` on the `@run` line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581674525

From myankelevich at openjdk.org  Tue Dec  2 15:48:08 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 2 Dec 2025 15:48:08 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
Message-ID: <UkS8dlyxpkyf9UV-LyQMHVhuqmq1cY9lGBDz4tSxVjo=.1cf4a053-7f22-4d72-95cb-a92c346fb928@github.com>

On Tue, 2 Dec 2025 14:29:34 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addressed more review comments
>  - addressed review comments

Just a few minor comments

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 60:

> 58:      * Is the server ready to serve?
> 59:      */
> 60:     volatile static boolean serverReady = false;

I think this might be better to make this a `CountDownLatch`

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 76:

> 74:         SSLServerSocketFactory sslssf =
> 75:             new SimpleSSLContext().get().getServerSocketFactory();
> 76:         SSLServerSocket sslServerSocket =

Nit: could you please keep the lines under 80 characters long. There are a few instances in this file

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 110:

> 108: 
> 109:         SSLSocketFactory sf = new SimpleSSLContext().get().getSocketFactory();
> 110:         URL url = new URL("https://[::1]:" + serverPort + "/index.html");

Suggestion:

  URL url = 
          new URI("https://[::1]:" + serverPort + "/index.html").toURL();

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 153:

> 151:     SubjectAltNameIPv6() throws Exception {
> 152:         startServer();
> 153:         startClient();

Do you think it might be better to call doClientSide here directly?

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 165:

> 163: 
> 164:     void startServer() throws Exception {
> 165:         serverThread = new Thread() {

Suggestion:

        serverThread = new Thread(() -> {

What do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/28577#pullrequestreview-3530780325
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581743338
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581725471
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581716748
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581731969
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581757022

From jpai at openjdk.org  Tue Dec  2 15:50:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 15:50:51 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile
Message-ID: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>

Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101.

The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API.

No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change.

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

Commit messages:
 - 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile

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

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

From vpaprotski at openjdk.org  Tue Dec  2 16:11:38 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 2 Dec 2025 16:11:38 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
Message-ID: <73e-Wc4MDwB89ficPzEuz-1d8q-frUZOuw9-QEAlo0c=.6834ed3c-adbe-432a-b410-15da0b440904@github.com>

On Tue, 2 Dec 2025 10:47:29 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The change looks good, but you might consider using jdk.test.lib.RandomFactory. It allows to get and set a seed that is also printed at every run to make a failure easily reproducible.

Thanks for the tip. Thats a pattern I use a lot! My complaint with `RandomFactory` is that now I need to add an extra classpath when calling the test directly. My development pattern is usually calling this command hundreds (thousands??) of times, until it is "convinced" to pass..

make images && ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -cp build/linux-x86_64-server-fastdebug/images/test/lib-test/test-lib.jar --add-opens java.base/sun.security.provider=ALL-UNNAMED --add-exports java.base/sun.security.provider=ALL-UNNAMED -XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java


(That is, I prefer to call java directly, instead of via jtreg)

> And as the test now fails on aarch64 perhaps it should be excluded there and a bug should be opened - or is the behavior expected on aarch64 ?

I would prefer a separate bug report. There really should not be any failures on aarch64 either. But its entirely possible that I needed to constrain the range of RNG further (i.e. in which case this is test issue, not an actual bug in crypto..)

@ferakocz Would you mind having a look at aarch64 failure? I have no idea how its asm works.. I really hope its something like this fix I had to put in: https://github.com/openjdk/jdk/blob/41ab1ec74139a35da789cc09fd2240dcffa49927/test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java#L156
(i.e. without that constraint, the int32 could overflow..)

PS: I am happy to help as I can with the range analysis.. I spent quite a bit agonizing over it in our own internal review.. Perhaps this could.. erm... "help" :D 

<img width="972" height="1144" alt="image" src="https://github.com/user-attachments/assets/a84319a4-2a00-4aa2-b1a9-461f2f26e41a" />


I do not believe the end of the proof above is fully correct; particularly, I do not see how the leap to the range "highlighted in red" is possible.
I believe the conclusion is still valid, here is my own correction to that sentence:
<img width="846" height="438" alt="image" src="https://github.com/user-attachments/assets/7d52ebd0-1113-4191-8277-52131d98ad88" />

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3602818185

From fferrari at openjdk.org  Tue Dec  2 16:13:58 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 2 Dec 2025 16:13:58 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <22ewjC92iHWcTdsRXiGYIbaYO6H8LSL__1ZuCO0BiUc=.f7516646-06d4-4863-b395-68d260865c47@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <22ewjC92iHWcTdsRXiGYIbaYO6H8LSL__1ZuCO0BiUc=.f7516646-06d4-4863-b395-68d260865c47@github.com>
Message-ID: <jKWVkN1FUYuSEGTW4ZVk7pE7WOqGzKjum5DFVlTrjBA=.8dec2f89-9e9d-4c4f-bd07-39d823cdf2a7@github.com>

On Tue, 2 Dec 2025 13:26:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Slightly improve ConfigFileTestDirPermissions
>>    
>>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>>    temporary directory cleanup.
>
> test/jdk/java/security/Security/ConfigFileTestDirPermissions.java line 70:
> 
>> 68:                 try {
>> 69:                     jdk.toRealPath();
>> 70:                     throw new jtreg.SkippedException("Must run non-elevated!");
> 
> Do you expect this to be a non-common situation? Just wondering if we should treat this as a failure instead of skipping.

It depends on how the test is run, is not really a failure, just that the test would pass without actually testing the issue. But I have no problem with considering it a failure anyway.

In my particular case, if I connect through SSH to my Windows VM, I end up elevated, so I need to execute this test from the VM's GUI (my VM setup is a bit unusual: I use _Windows_' native _OpenSSH_ service with _Cygwin_'s `bash.exe` as the shell, and there is a single administrative user in the system).

Originally I thought that making it a failure could break the test inside lots of CI / test-execution environments, but perhaps is not the case. Can you confirm it isn't being skipped on _Oracle_'s runs?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2581882104

From fferrari at openjdk.org  Tue Dec  2 16:18:12 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 2 Dec 2025 16:18:12 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <LBAoDLHX4VrHwsONt4foz92g8MeFgdwCOeMtJPyq028=.f4668d90-88a2-43cf-859a-8a4759b1b7a7@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
 <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
 <41RTmykCC1A-4ExHq7HWsqmlS5lobm0PVxDub7P85j0=.281cee13-471e-4863-917e-0bf3094335b6@github.com>
 <2y7XZvrGxz-h2azJRkuC-4K4h4QBA4GdrfHwE3426oA=.ad803ea6-ebea-4bfa-bd4a-58fadec9093c@github.com>
 <LBAoDLHX4VrHwsONt4foz92g8MeFgdwCOeMtJPyq028=.f4668d90-88a2-43cf-859a-8a4759b1b7a7@github.com>
Message-ID: <Hjk_9_jcAHvuK15eFMtQpvd0kTxGcrGYSOw5efGUhH0=.2b7a5c6f-8814-44d9-8a50-f1a71c4ba9bc@github.com>

On Tue, 2 Dec 2025 13:55:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Addressed in 4e7206c082e4b0152d999b32eba0063a506eff67.
>
> Ok, thanks for the explanation. I agree it is a rare case, but now I think maybe a debug statement is better than throwing an `InternalError` since it seems like the code can still recover and continue w/o unexpected behavior - would you agree?

Yes, I will update it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2581904541

From azeller at openjdk.org  Tue Dec  2 16:24:45 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Tue, 2 Dec 2025 16:24:45 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
Message-ID: <cgdCiRE0ja6wSVZrcwamlEh2s7FMzeWfy7kclS_VFoo=.a34eda29-54d3-4a1e-923a-d1f7798b393c@github.com>

On Mon, 1 Dec 2025 17:54:21 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - Stop catching exception to make test able to fail
> - Remove java-only test variation that cannot fail
> - Reduce fuzz repeat count

Looks good to me but I'm no official "Reviewer".
The aarch64 issue can be solved in a different bug.

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

Marked as reviewed by azeller (Author).

PR Review: https://git.openjdk.org/jdk/pull/28584#pullrequestreview-3531043668

From schernyshev at openjdk.org  Tue Dec  2 16:36:10 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 16:36:10 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <UkS8dlyxpkyf9UV-LyQMHVhuqmq1cY9lGBDz4tSxVjo=.1cf4a053-7f22-4d72-95cb-a92c346fb928@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <UkS8dlyxpkyf9UV-LyQMHVhuqmq1cY9lGBDz4tSxVjo=.1cf4a053-7f22-4d72-95cb-a92c346fb928@github.com>
Message-ID: <OXxA-luSw3edvtSTPZVwAGtCnd-5FtbjjS_L1a9a9sQ=.20867602-6d28-4f0e-98d4-5025205a7009@github.com>

On Tue, 2 Dec 2025 15:36:29 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressed more review comments
>>  - addressed review comments
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 76:
> 
>> 74:         SSLServerSocketFactory sslssf =
>> 75:             new SimpleSSLContext().get().getServerSocketFactory();
>> 76:         SSLServerSocket sslServerSocket =
> 
> Nit: could you please keep the lines under 80 characters long. There are a few instances in this file

ok.

> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 153:
> 
>> 151:     SubjectAltNameIPv6() throws Exception {
>> 152:         startServer();
>> 153:         startClient();
> 
> Do you think it might be better to call doClientSide here directly?

ok, accepted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581969554
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581975687

From alanb at openjdk.org  Tue Dec  2 16:37:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Dec 2025 16:37:02 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile
In-Reply-To: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
Message-ID: <bg4AGYDE9vGrviPdjx6QzI8p4aCrKWZ16Ox_6DBqyRg=.789e8fef-8056-49d0-8d12-e41fb5170283@github.com>

On Tue, 2 Dec 2025 15:44:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101.
> 
> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API.
> 
> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change.

src/java.base/share/classes/java/util/jar/JarFile.java line 1043:

> 1041:             // the JAR verifier
> 1042:             ScopedValue.where(IN_VERIFIER_INIT, true).call(
> 1043:                     new ScopedValue.CallableOp<Void, Exception>() {

ScopedValue.Carrier defines a run method so you could use `ScopedValue.where(IN_VERIFIER_INIT, true).run(..)` here and avoid the exception handling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2581980625

From abarashev at openjdk.org  Tue Dec  2 16:46:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 2 Dec 2025 16:46:08 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
Message-ID: <jMguJDGz6W3zRfcsM4BCTsoobasQSmSmUfTCN3paK8E=.254ebb60-4fc9-492d-8d6c-847a012ec509@github.com>

On Fri, 28 Nov 2025 18:35:12 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix 8352728.
>> 
>> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following:
>> 
>> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
>> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
>> 
>> #### Windows Case
>> 
>> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
>> 
>> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - Slightly improve ConfigFileTestDirPermissions
>    
>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>    temporary directory cleanup.

src/java.base/share/classes/java/security/Security.java line 116:

> 114:         private static Path currentPath;
> 115: 
> 116:         private static final List<Path> activePaths = new ArrayList<>();

Consider using `LinkedHashSet` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2582015460

From abarashev at openjdk.org  Tue Dec  2 16:49:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 2 Dec 2025 16:49:13 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
Message-ID: <prtiPTk2aZ_1M1-3ANQAp1HkUwBoqTEZazAsG7IFiaI=.11b3d0a4-df30-48e0-ba13-50ee71e3f34e@github.com>

On Fri, 28 Nov 2025 18:35:12 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix 8352728.
>> 
>> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following:
>> 
>> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
>> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
>> 
>> #### Windows Case
>> 
>> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
>> 
>> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - Slightly improve ConfigFileTestDirPermissions
>    
>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>    temporary directory cleanup.

src/java.base/share/classes/java/security/Security.java line 258:

> 256:                     }
> 257:                     // We perform symlinks resolution on currentPath under the
> 258:                     // rationale that the original file writer is the one who

Nit: "the one who" is used to refer to people, while "the one that" or "the one which" is used for inanimate objects.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2582024868

From schernyshev at openjdk.org  Tue Dec  2 16:50:23 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 16:50:23 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <UkS8dlyxpkyf9UV-LyQMHVhuqmq1cY9lGBDz4tSxVjo=.1cf4a053-7f22-4d72-95cb-a92c346fb928@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <UkS8dlyxpkyf9UV-LyQMHVhuqmq1cY9lGBDz4tSxVjo=.1cf4a053-7f22-4d72-95cb-a92c346fb928@github.com>
Message-ID: <o7nEHyXhWrmACIBu5Q8xAkwQSN55xOJNMzRonRmoyig=.6a2a275f-a7b0-48ac-861a-14df05b686b4@github.com>

On Tue, 2 Dec 2025 15:40:19 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressed more review comments
>>  - addressed review comments
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 60:
> 
>> 58:      * Is the server ready to serve?
>> 59:      */
>> 60:     volatile static boolean serverReady = false;
> 
> I think this might be better to make this a `CountDownLatch`

ok, accepted.

> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 110:
> 
>> 108: 
>> 109:         SSLSocketFactory sf = new SimpleSSLContext().get().getSocketFactory();
>> 110:         URL url = new URL("https://[::1]:" + serverPort + "/index.html");
> 
> Suggestion:
> 
>   URL url = 
>           new URI("https://[::1]:" + serverPort + "/index.html").toURL();

I think the block is better readable without it.

> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 165:
> 
>> 163: 
>> 164:     void startServer() throws Exception {
>> 165:         serverThread = new Thread() {
> 
> Suggestion:
> 
>         serverThread = new Thread(() -> {
> 
> What do you think?

This makes sense. I will set the /contributer manually later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582027880
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582024160
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582019908

From schernyshev at openjdk.org  Tue Dec  2 16:50:25 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 16:50:25 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <dkgZpBB-_wfd7t0hHa0ezyQknCzpeglf0M3Hv2qp6lc=.bf3a5db9-670c-4704-97c0-fa2b68465daf@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <TysOFCScMmUVGHDbWRRPbpCcc8CVGx6SJFfbZDmfC5I=.31e8c597-d7f2-4dc9-ad00-cacbc904bd6d@github.com>
 <kxQJhHMAHM8yhaQyvVvI9DoE6QOpQprRLesfTjmvLgo=.9fb2216e-15d4-4776-9bb1-66b77ce4fe99@github.com>
 <dkgZpBB-_wfd7t0hHa0ezyQknCzpeglf0M3Hv2qp6lc=.bf3a5db9-670c-4704-97c0-fa2b68465daf@github.com>
Message-ID: <xCXQqp_x8lZhr1WxxEOG0ft1UbrMjSDOiBh2aodGVl4=.e52c361b-b5c3-4968-9943-eeecdc024ea1@github.com>

On Tue, 2 Dec 2025 15:22:27 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> @myankelev should I revert the suggested change?
>
> Nope, it's fine as it is now, but if you want you can remove this debug flag completely. It's up to you

Thanks @myankelev , i will update the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582026811

From myankelevich at openjdk.org  Tue Dec  2 16:54:45 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 2 Dec 2025 16:54:45 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <o7nEHyXhWrmACIBu5Q8xAkwQSN55xOJNMzRonRmoyig=.6a2a275f-a7b0-48ac-861a-14df05b686b4@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <UkS8dlyxpkyf9UV-LyQMHVhuqmq1cY9lGBDz4tSxVjo=.1cf4a053-7f22-4d72-95cb-a92c346fb928@github.com>
 <o7nEHyXhWrmACIBu5Q8xAkwQSN55xOJNMzRonRmoyig=.6a2a275f-a7b0-48ac-861a-14df05b686b4@github.com>
Message-ID: <F4cXjTbazfQdj36CTwneuYBOfQdaLlU2hmte5axiFMw=.36ceedee-e793-458e-b1fb-f0c7a67ce2e2@github.com>

On Tue, 2 Dec 2025 16:46:29 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 110:
>> 
>>> 108: 
>>> 109:         SSLSocketFactory sf = new SimpleSSLContext().get().getSocketFactory();
>>> 110:         URL url = new URL("https://[::1]:" + serverPort + "/index.html");
>> 
>> Suggestion:
>> 
>>   URL url = 
>>           new URI("https://[::1]:" + serverPort + "/index.html").toURL();
>
> I think the block is better readable without it.

It's deprecated since version 20 I think

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582045071

From jpai at openjdk.org  Tue Dec  2 16:56:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 16:56:18 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
Message-ID: <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>

> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101.
> 
> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API.
> 
> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change.

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

  use Runnable() instead of CallableOp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28609/files
  - new: https://git.openjdk.org/jdk/pull/28609/files/6bd7fa84..79539802

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

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

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

From jpai at openjdk.org  Tue Dec  2 16:56:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Dec 2025 16:56:20 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <bg4AGYDE9vGrviPdjx6QzI8p4aCrKWZ16Ox_6DBqyRg=.789e8fef-8056-49d0-8d12-e41fb5170283@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
 <bg4AGYDE9vGrviPdjx6QzI8p4aCrKWZ16Ox_6DBqyRg=.789e8fef-8056-49d0-8d12-e41fb5170283@github.com>
Message-ID: <YmcA2pS4lqBJdDu3f7LHITgEF_goFA7d6C6dK4DVJAY=.4f015a92-0038-43bf-9617-2281ac691959@github.com>

On Tue, 2 Dec 2025 16:34:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use Runnable() instead of CallableOp
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 1043:
> 
>> 1041:             // the JAR verifier
>> 1042:             ScopedValue.where(IN_VERIFIER_INIT, true).call(
>> 1043:                     new ScopedValue.CallableOp<Void, Exception>() {
> 
> ScopedValue.Carrier defines a run method so you could use `ScopedValue.where(IN_VERIFIER_INIT, true).run(..)` here and avoid the exception handling.

I hadn't spotted that API, much cleaner indeed. I've updated the PR with that change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2582048687

From mullan at openjdk.org  Tue Dec  2 17:02:19 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 Dec 2025 17:02:19 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
Message-ID: <WT1vobmotZbk8scOCG0nds5IsyIpdAbSP2ly_wqPI-Y=.db079ed6-cc47-4448-99fc-f79d3e3fa216@github.com>

On Mon, 24 Nov 2025 07:51:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update names to uppercase
>  - Remove fallback in engineGeneratePublic
>  - Change default named group list to have only X25519MLKEM768

test/jdk/sun/security/ssl/CipherSuite/DisabledCurve.java line 43:

> 41:         DisabledCurve DISABLE_NONE PASS
> 42:  * @run main/othervm -Djdk.tls.namedGroups="SecP384r1MLKEM1024"
> 43:         DisabledCurve SecP384r1MLKEM1024 FAIL

A different way to enhance this test so that the hybrids are only tested with TLS 1.3 would be to add additional optional command-line arguments that take the client and server protocols you want to _only_ test with, respectively, ex:


@run main/othervm -Djdk.tls.namedGroups="SecP384r1MLKEM1024"
        DisabledCurve DISABLE_NONE PASS TLSv1.3 TLSv1.3

        
Just for your consideration, if you have time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2582077523

From weijun at openjdk.org  Tue Dec  2 17:08:20 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 2 Dec 2025 17:08:20 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
Message-ID: <DLTrn6RqFdEs_IQzK0Q6Pm3tAUAh1XXZsA7y2LBkDbg=.eed350f5-3c57-4e86-9e80-54676650a05b@github.com>

On Fri, 28 Nov 2025 18:35:12 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix 8352728.
>> 
>> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following:
>> 
>> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
>> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
>> 
>> #### Windows Case
>> 
>> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
>> 
>> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - Slightly improve ConfigFileTestDirPermissions
>    
>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>    temporary directory cleanup.

Please confirm if I understand correctly. So the current fix covers both this bug and the Windows UWP regression. However, if relative include is used in Windows UWP, it is still a problem. Is this right?

If so, if one day someone brings up the relative include problem in Windows UWP, do you expect a different fix that will overwrite this one? Or is it the Windows admin's duty to add more permissions?

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3603087503

From fferrari at openjdk.org  Tue Dec  2 17:08:24 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 2 Dec 2025 17:08:24 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <prtiPTk2aZ_1M1-3ANQAp1HkUwBoqTEZazAsG7IFiaI=.11b3d0a4-df30-48e0-ba13-50ee71e3f34e@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <prtiPTk2aZ_1M1-3ANQAp1HkUwBoqTEZazAsG7IFiaI=.11b3d0a4-df30-48e0-ba13-50ee71e3f34e@github.com>
Message-ID: <ieJiU8FT7ssLPJ9dn9y32QI2POt5XSmGlIjjBMIGS7Q=.8ac6faad-1ad8-4bcc-abb3-992b6dd3bd0e@github.com>

On Tue, 2 Dec 2025 16:46:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Slightly improve ConfigFileTestDirPermissions
>>    
>>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>>    temporary directory cleanup.
>
> src/java.base/share/classes/java/security/Security.java line 258:
> 
>> 256:                     }
>> 257:                     // We perform symlinks resolution on currentPath under the
>> 258:                     // rationale that the original file writer is the one who
> 
> Nit: "the one who" is used to refer to people, while "the one that" or "the one which" is used for inanimate objects.

By "file writer" I mean the person who wrote the properties file issuing a relative `include` directive. But it is definitively confusing, how about the following?

                    // We perform symlinks resolution on currentPath
                    // under the rationale that the person writing the
                    // original properties file is the one who decided
                    // where the relative includes should resolve.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2582103019

From schernyshev at openjdk.org  Tue Dec  2 17:14:15 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 17:14:15 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v3]
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <vFHloSQR1-vNkPTFKZN5wingXuhKipcwOITSWBKuL4w=.8ab2d609-d7d2-4bb2-bb4e-6a78bdb3c2a9@github.com>

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

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

  addressed even more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28577/files
  - new: https://git.openjdk.org/jdk/pull/28577/files/c388c253..fdd0133d

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

  Stats: 60 lines in 1 file changed: 13 ins; 16 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/28577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28577/head:pull/28577

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

From schernyshev at openjdk.org  Tue Dec  2 17:14:16 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 17:14:16 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v2]
In-Reply-To: <F4cXjTbazfQdj36CTwneuYBOfQdaLlU2hmte5axiFMw=.36ceedee-e793-458e-b1fb-f0c7a67ce2e2@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <UkS8dlyxpkyf9UV-LyQMHVhuqmq1cY9lGBDz4tSxVjo=.1cf4a053-7f22-4d72-95cb-a92c346fb928@github.com>
 <o7nEHyXhWrmACIBu5Q8xAkwQSN55xOJNMzRonRmoyig=.6a2a275f-a7b0-48ac-861a-14df05b686b4@github.com>
 <F4cXjTbazfQdj36CTwneuYBOfQdaLlU2hmte5axiFMw=.36ceedee-e793-458e-b1fb-f0c7a67ce2e2@github.com>
Message-ID: <DilTo34JfquiZ5Hyn7LpHAPpXZqBJf5M1ba8eFDlWGc=.76d16332-7b6a-4827-9e89-74723dbc70f2@github.com>

On Tue, 2 Dec 2025 16:51:45 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> I think the block is better readable without it.
>
> It's deprecated since version 20 I think

Ahh, ok, i read it wrong, apologies. URI is the modern one, exactly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582120479

From schernyshev at openjdk.org  Tue Dec  2 17:28:02 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 2 Dec 2025 17:28:02 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v4]
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <C8Rxgt9PYJ8sGevbN6lpB7TzDr1dBUPJQMvXLm7DhSo=.4b9cf913-6c85-4ebb-a2b4-d3ed953a3aa8@github.com>

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

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

  addressed few more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28577/files
  - new: https://git.openjdk.org/jdk/pull/28577/files/fdd0133d..44ed7ddb

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

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

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

From mcimadamore at openjdk.org  Tue Dec  2 17:54:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 2 Dec 2025 17:54:15 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <SwHx_atpaJJH61nyPYs6s8B-bAZzdL7IsNoOQRadiGg=.8319a405-d5d8-4240-b90d-3e8b30964053@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <AvxdZJlyuZUh8a7q1xCN6DSQExHyS9m9CLTtgc9c1Bg=.06ff7be3-d968-4b79-8e1c-ccbce6ac0acd@github.com>
 <SwHx_atpaJJH61nyPYs6s8B-bAZzdL7IsNoOQRadiGg=.8319a405-d5d8-4240-b90d-3e8b30964053@github.com>
Message-ID: <5CMXCgWmWnuATMxROM1zVobe9dv-6FrwCN7hJHfC8dc=.e153adc5-f91f-4fba-9ffe-eced1ab9cac6@github.com>

On Mon, 1 Dec 2025 19:03:50 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> That was my mistake - I expected that with the foreign ABI being merged, discussions on internals would have reverted to here.

In general they are -- but I find that one issue with PRs is that they tend to be very code-centric, whereas in some cases it might be useful to discuss design options more abstractly and _then_ converge towards an implementation. And doing design discussions via PR is suboptimal. But, you did right in bringing this up!

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3603277207

From fferrari at openjdk.org  Tue Dec  2 18:21:26 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 2 Dec 2025 18:21:26 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <jMguJDGz6W3zRfcsM4BCTsoobasQSmSmUfTCN3paK8E=.254ebb60-4fc9-492d-8d6c-847a012ec509@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <jMguJDGz6W3zRfcsM4BCTsoobasQSmSmUfTCN3paK8E=.254ebb60-4fc9-492d-8d6c-847a012ec509@github.com>
Message-ID: <I8b0sqegqGYfIXop5VHYOC2ykf_3PK7EtfWWrJr8TUo=.78a306ec-832e-4973-9633-14ea93d87126@github.com>

On Tue, 2 Dec 2025 16:43:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Slightly improve ConfigFileTestDirPermissions
>>    
>>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>>    temporary directory cleanup.
>
> src/java.base/share/classes/java/security/Security.java line 116:
> 
>> 114:         private static Path currentPath;
>> 115: 
>> 116:         private static final List<Path> activePaths = new ArrayList<>();
> 
> Consider using `LinkedHashSet` instead.

Hi,

Since I've [been previously told](#issuecomment-3414764843) to use `Files::isSameFile`, we are no longer relying on the `Set` features to check the uniqueness of the paths we include. As a consequence, we are iterating `activePaths` each time we need to check for a circular inclusion.

https://github.com/openjdk/jdk/blob/4e7206c082e4b0152d999b32eba0063a506eff67/src/java.base/share/classes/java/security/Security.java#L269-L282

Please also note that `checkCyclicInclude(path)` will reject duplicated entries before adding them to `activePaths`.

https://github.com/openjdk/jdk/blob/4e7206c082e4b0152d999b32eba0063a506eff67/src/java.base/share/classes/java/security/Security.java#L289-L293

With this in mind, I think we shouldn't be paying the `LinkedHashSet` hashing costs given we aren't going to use the `Set` features, i.e. we won't be inserting duplicated entries nor checking `activePaths.contains(path)`.

Please let me know if I'm missing anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2582326379

From abarashev at openjdk.org  Tue Dec  2 18:21:28 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 2 Dec 2025 18:21:28 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <ieJiU8FT7ssLPJ9dn9y32QI2POt5XSmGlIjjBMIGS7Q=.8ac6faad-1ad8-4bcc-abb3-992b6dd3bd0e@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <prtiPTk2aZ_1M1-3ANQAp1HkUwBoqTEZazAsG7IFiaI=.11b3d0a4-df30-48e0-ba13-50ee71e3f34e@github.com>
 <ieJiU8FT7ssLPJ9dn9y32QI2POt5XSmGlIjjBMIGS7Q=.8ac6faad-1ad8-4bcc-abb3-992b6dd3bd0e@github.com>
Message-ID: <azrp_OyQO33R2skJ2f6krdLgnk2co6OyI9rhR0qTGxo=.441c77aa-ecb3-43c3-98f6-9957eac708e6@github.com>

On Tue, 2 Dec 2025 17:05:13 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 258:
>> 
>>> 256:                     }
>>> 257:                     // We perform symlinks resolution on currentPath under the
>>> 258:                     // rationale that the original file writer is the one who
>> 
>> Nit: "the one who" is used to refer to people, while "the one that" or "the one which" is used for inanimate objects.
>
> By "file writer" I mean the person who wrote the properties file issuing a relative `include` directive. But it is definitively confusing, how about the following?
> 
>                     // We perform symlinks resolution on currentPath
>                     // under the rationale that the person writing the
>                     // original properties file is the one who decided
>                     // where the relative includes should resolve.

I see, thanks for explaining. The corrected version looks good to me except I would replace `the one who decided` with `the one who decides`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2582328195

From abarashev at openjdk.org  Tue Dec  2 18:27:29 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 2 Dec 2025 18:27:29 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <I8b0sqegqGYfIXop5VHYOC2ykf_3PK7EtfWWrJr8TUo=.78a306ec-832e-4973-9633-14ea93d87126@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <jMguJDGz6W3zRfcsM4BCTsoobasQSmSmUfTCN3paK8E=.254ebb60-4fc9-492d-8d6c-847a012ec509@github.com>
 <I8b0sqegqGYfIXop5VHYOC2ykf_3PK7EtfWWrJr8TUo=.78a306ec-832e-4973-9633-14ea93d87126@github.com>
Message-ID: <VeiEyyGfntdUunk5Fm-4v7RXow1TI7UFzuTErDZaxgE=.cd75c22b-2bf1-4d2d-8704-976972662052@github.com>

On Tue, 2 Dec 2025 18:17:24 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 116:
>> 
>>> 114:         private static Path currentPath;
>>> 115: 
>>> 116:         private static final List<Path> activePaths = new ArrayList<>();
>> 
>> Consider using `LinkedHashSet` instead.
>
> Hi,
> 
> Since I've [been previously told](#issuecomment-3414764843) to use `Files::isSameFile`, we are no longer relying on the `Set` features to check the uniqueness of the paths we include. As a consequence, we are iterating `activePaths` each time we need to check for a circular inclusion.
> 
> https://github.com/openjdk/jdk/blob/4e7206c082e4b0152d999b32eba0063a506eff67/src/java.base/share/classes/java/security/Security.java#L269-L282
> 
> Please also note that `checkCyclicInclude(path)` will reject duplicated entries before adding them to `activePaths`.
> 
> https://github.com/openjdk/jdk/blob/4e7206c082e4b0152d999b32eba0063a506eff67/src/java.base/share/classes/java/security/Security.java#L289-L293
> 
> With this in mind, I think we shouldn't be paying the `LinkedHashSet` hashing costs given we aren't going to use the `Set` features, i.e. we won't be inserting duplicated entries nor checking `activePaths.contains(path)`.
> 
> Please let me know if I'm missing anything.

Indeed, I missed the fact that we no longer call `activePaths.contains(path)`, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2582345758

From valeriep at openjdk.org  Tue Dec  2 18:56:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 2 Dec 2025 18:56:52 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v7]
In-Reply-To: <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>
Message-ID: <rT4GdutEMDUptYOWQDluKy916SECiLC4MeLAcpft_ew=.170cdb1d-1f51-41cf-94bd-8c08da92ba7d@github.com>

On Mon, 1 Dec 2025 10:27:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr 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 nine additional commits since the last revision:
> 
>  - Minor simplification.
>  - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
>  - Fix missing whitespace.
>  - Address review comments.
>  - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
>  - Remove K from AES_Crypt
>  - More minor cleanup.
>  - Improve comment and minor cleanup.
>  - 8371820: Further AES performance improvements for key schedule generation

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28299#pullrequestreview-3531689005

From mdoerr at openjdk.org  Tue Dec  2 19:36:58 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 2 Dec 2025 19:36:58 GMT
Subject: RFR: 8371820: Further AES performance improvements for key
 schedule generation [v7]
In-Reply-To: <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
 <g7fnhng_dkp3oCDufBY2apAWDbS19I2UUusDDizxPsM=.6b0170ee-590b-46ea-a640-75599e7c6992@github.com>
Message-ID: <fEDq9drWMSNVXRVYQkRi2TDmXRsopysghlTARnXAXdQ=.d1e9b8ac-78a9-4b63-a6be-dcb4d1eab44b@github.com>

On Mon, 1 Dec 2025 10:27:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
>> 
>> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.
>
> Martin Doerr 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 nine additional commits since the last revision:
> 
>  - Minor simplification.
>  - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
>  - Fix missing whitespace.
>  - Address review comments.
>  - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt
>  - Remove K from AES_Crypt
>  - More minor cleanup.
>  - Improve comment and minor cleanup.
>  - 8371820: Further AES performance improvements for key schedule generation

Thanks for all reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3603660124

From vyazici at openjdk.org  Tue Dec  2 19:40:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 2 Dec 2025 19:40:04 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
 <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
Message-ID: <gkJvZM3qFdAIOmLdER0F7ypjYSBDeYHNUo8vyy3EKRQ=.265a55bb-d588-490c-8a11-8107e3c61d3b@github.com>

On Tue, 2 Dec 2025 16:56:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101.
>> 
>> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API.
>> 
>> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Runnable() instead of CallableOp

Marked as reviewed by vyazici (Committer).

src/java.base/share/classes/java/util/jar/JarFile.java line 1047:

> 1045:                 jvInitialized = true;
> 1046:             }
> 1047:         });

You can consider shortening this using a lambda:


ScopedValue.where(IN_VERIFIER_INIT, true).run(() -> {
    initializeVerifier();
    jvInitialized = true;
});

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

PR Review: https://git.openjdk.org/jdk/pull/28609#pullrequestreview-3531826580
PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2582559476

From mdoerr at openjdk.org  Tue Dec  2 19:40:17 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 2 Dec 2025 19:40:17 GMT
Subject: Integrated: 8371820: Further AES performance improvements for key
 schedule generation
In-Reply-To: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
References: <nIGa8VWWxXnGBnnPBPgaAEHrgxgQclNAo66y0mYVYrE=.5842dca0-f8e0-4aef-b798-23818427fcaa@github.com>
Message-ID: <jjIjgXXJTC5Ae7UwvLzLUqKrFPzL0mDdExsZo2DTXQ0=.342c4a3a-63a4-46c4-afd6-26e8a0a148e0@github.com>

On Thu, 13 Nov 2025 16:48:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption.
> 
> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64.

This pull request has now been integrated.

Changeset: 618732ff
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/618732ffc04ef393c9b8a3265c12ba66f31784d9
Stats:     61 lines in 7 files changed: 13 ins; 8 del; 40 mod

8371820: Further AES performance improvements for key schedule generation

Reviewed-by: rrich, valeriep

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

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

From fferrari at openjdk.org  Tue Dec  2 19:48:24 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 2 Dec 2025 19:48:24 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <DLTrn6RqFdEs_IQzK0Q6Pm3tAUAh1XXZsA7y2LBkDbg=.eed350f5-3c57-4e86-9e80-54676650a05b@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <DLTrn6RqFdEs_IQzK0Q6Pm3tAUAh1XXZsA7y2LBkDbg=.eed350f5-3c57-4e86-9e80-54676650a05b@github.com>
Message-ID: <pfz0tlDzNWmBOg5AnXHMsRaQLoHNNrJnzf_OhgnOpPY=.e120a43d-a433-42b6-9b45-d601069a9e0f@github.com>

On Tue, 2 Dec 2025 17:02:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Slightly improve ConfigFileTestDirPermissions
>>    
>>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>>    temporary directory cleanup.
>
> Please confirm if I understand correctly. So the current fix covers both this bug and the Windows UWP regression. However, if relative include is used in Windows UWP, it is still a problem. Is this right?
> 
> If so, if one day someone brings up the relative include problem in Windows UWP, do you expect a different fix that will overwrite this one? Or is it the Windows admin's duty to add more permissions?

Hi @wangweij,

> Please confirm if I understand correctly. So the current fix covers both this bug and the Windows UWP regression. However, if relative include is used in Windows UWP, it is still a problem. Is this right?

Yes.

> If so, if one day someone brings up the relative include problem in Windows UWP, do you expect a different fix that will overwrite this one? Or is it the Windows admin's duty to add more permissions?

I'm not an UWP expert by any means, but I think that changing permissions would be, at the very least, a bad practice (because it would weaken the isolation of the apps).

If the problem is brought up in the future, I would start a discussion with the core-libs team to see what are our alternatives. Between JDK 24 and #27324 (e.g. current JDK 25), `File::getCanonicalFile` was behaving in a way that worked well for this use case, but that was probably a non-guaranteed behavior by the API.

The exchange with the core-libs team should try to go in the direction of answering when a filesystem link/junction should be considered resolvable, under the lack of parent permissions, on each platform. If the answer is "never", is there an API (or should we introduce one?) that can tell us whether a filesystem link/junction exists? (in cases where we are sure there isn't a link/junction, we can use `Path::toAbsolutePath` as a fallback). What do other runtimes do? Does exist a known OS-level API capable of giving a valid resolution for the path under this permissions scenario? If it does, is "never" still a valid answer to the first question?

In parallel, on the security-libs side, we could try fo find any best-effort worth exploring. For example, do we want to unconditionally use `Path::toAbsolutePath` as a fallback, and document something in line with "in the absence of parent directory permissions, all the relative includes will be computed using the unresolved path as the base"?

#### Workaround

In the meantime, we could recommend trying to find a system property that allows the _Windows UWP_ app to calculate the path as an absolute one.

For example, if the file is in the same directory as `java.security`, instead of:


include other.properties


Use:


include ${java.home}\\conf\\security\\other.properties

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3603693159

From fferrari at openjdk.org  Tue Dec  2 19:55:51 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 2 Dec 2025 19:55:51 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <IStCignijKSnbT7wdpK9lwjraJEZugbQb12PAlREmyg=.03694ee8-3284-49fa-b614-4152da34d0d1@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <IStCignijKSnbT7wdpK9lwjraJEZugbQb12PAlREmyg=.03694ee8-3284-49fa-b614-4152da34d0d1@github.com>
Message-ID: <cbP1RlSR-BwieliyM6guzvXbcBeyZsZBBpzW5hdve-M=.d0e69907-484d-4984-9f29-c698d9b108d1@github.com>

On Tue, 2 Dec 2025 14:12:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Slightly improve ConfigFileTestDirPermissions
>>    
>>    Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>>    temporary directory cleanup.
>
> test/jdk/java/security/Security/ConfigFileTestAnonymousPipes.sh line 1:
> 
>> 1: #
> 
> This test failed on linux-x64 and linux-aarch64 on our test systems. Here's a snippet of the logfile:
> 
> 
> properties[0x3|main|Security.java:160|2025-12-02 13:35:48.066]: unable to load security properties from <(echo include /dev/stdin)
> java.io.FileNotFoundException: <(echo include /dev/stdin)
> 	at java.base/java.security.Security$SecPropLoader.loadExtraFromPath(Security.java:209)
> 	at java.base/java.security.Security$SecPropLoader.loadExtraHelper(Security.java:178)
> 	at java.base/java.security.Security$SecPropLoader.loadExtra(Security.java:157)
> 	at java.base/java.security.Security$SecPropLoader.loadAll(Security.java:122)
> 	at java.base/java.security.Security.initialize(Security.java:337)
> 	at java.base/java.security.Security.<clinit>(Security.java:326)
> 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
> 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1195)
> 	at java.base/java.lang.invoke.MethodHandles$Lookup.ensureInitialized(MethodHandles.java:2750)
> 	at java.base/jdk.internal.access.SharedSecrets.ensureClassInitialized(SharedSecrets.java:504)
> 	at java.base/jdk.internal.access.SharedSecrets.getJavaSecurityPropertiesAccess(SharedSecrets.java:320)
> 	at java.base/sun.launcher.SecuritySettings.printSecurityProperties(SecuritySettings.java:88)
> 	at java.base/sun.launcher.SecuritySettings.printSecuritySettings(SecuritySettings.java:63)
> 	at java.base/sun.launcher.LauncherHelper.showSettings(LauncherHelper.java:172)

Looks like `<(echo include /dev/stdin)` is being interpreted literally, instead of defining a [Bash Process Substitution](https://www.gnu.org/software/bash/manual/html_node/Process-Substitution.html).

Thinking Bash would be the execution shell on all the platforms was probably a wrong assumption. Let me see if I can replace it by something else, otherwise I will need to give up and remove that second one.

The first one must be passing, otherwise it would have exited without getting to the second one:

https://github.com/openjdk/jdk/blob/4e7206c082e4b0152d999b32eba0063a506eff67/test/jdk/java/security/Security/ConfigFileTestAnonymousPipes.sh#L54

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2582596652

From mullan at openjdk.org  Tue Dec  2 20:03:24 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 Dec 2025 20:03:24 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v11]
In-Reply-To: <_HUUN67SsUDKiW4mhpPssp7bTD-BIiz0Ho1qyltjYeY=.afae4482-6158-4e73-aee1-351d1251d759@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <f1LGOwCPsznfyr2PPV8WapM4335Th4oEs4kR_lT8bBM=.50f62482-94c8-490a-9e02-20c3d2958ea0@github.com>
 <tXOYQ_nde9pAdy2Gn_DhUzmLm9Lu02sf-mGI87I819Q=.758751d0-3684-4fdf-be8b-222ee93e13e3@github.com>
 <_HUUN67SsUDKiW4mhpPssp7bTD-BIiz0Ho1qyltjYeY=.afae4482-6158-4e73-aee1-351d1251d759@github.com>
Message-ID: <5D1Yihd-yhpCmCh7b-8GGc3OjFmBFumOwj3GnceIDpU=.61c6f036-4797-4902-8f54-90cdc6a822b5@github.com>

On Wed, 26 Nov 2025 21:17:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Hi folks, as we know [JDK 26 enters Rampdown Phase One next week](https://mail.openjdk.org/pipermail/jdk-dev/2025-November/010639.html) on Thursday, 4 December.
> 
> Please let me know if we'll want this fix to move forward before that happens, and please note that soon I will need to focus on the OJVG work.

This is a P3 bug and a regression, so it can be fixed after RDP1 and before RDP2. I have asked other members of our team to review this fix as I am busy with other work. Given that RDP1 is only a couple of days away and these additional reviews and changes are still ongoing, I don't think we can guarantee this will be integrated before RDP1, but hopefully you will have time after that to continue to address feedback, if needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3603743041

From alanb at openjdk.org  Tue Dec  2 20:12:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Dec 2025 20:12:19 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <gkJvZM3qFdAIOmLdER0F7ypjYSBDeYHNUo8vyy3EKRQ=.265a55bb-d588-490c-8a11-8107e3c61d3b@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
 <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
 <gkJvZM3qFdAIOmLdER0F7ypjYSBDeYHNUo8vyy3EKRQ=.265a55bb-d588-490c-8a11-8107e3c61d3b@github.com>
Message-ID: <Bw5HVKGJxX91m-pD8AZmc3O9wPxQkZdkdaKqG8Gogg0=.c4243296-9d89-4bdf-b29d-619507d9a7f1@github.com>

On Tue, 2 Dec 2025 19:36:49 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use Runnable() instead of CallableOp
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 1047:
> 
>> 1045:                 jvInitialized = true;
>> 1046:             }
>> 1047:         });
> 
> You can consider shortening this using a lambda:
> 
> 
> ScopedValue.where(IN_VERIFIER_INIT, true).run(() -> {
>     initializeVerifier();
>     jvInitialized = true;
> });

Yes, but I think would be prudent to run startup benchmarks if you change that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2582636023

From bperez at openjdk.org  Tue Dec  2 21:08:12 2025
From: bperez at openjdk.org (Ben Perez)
Date: Tue, 2 Dec 2025 21:08:12 GMT
Subject: RFR: 8355216: Accelerate P-256 arithmetic on aarch64 [v3]
In-Reply-To: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
References: <EiLAVdcIX_OKisbKoR6H6ADweL9LSuLfIRQgRYYNw7o=.8c823874-0af8-4c54-8e61-a2c43243b2e0@github.com>
Message-ID: <sh8-lsjqj-wo39KcL3k2YTPvumzfxqi0itO-U3xRNeM=.cb21c55e-fcf3-49f1-b324-d8160e5240e3@github.com>

> An aarch64 implementation of the `MontgomeryIntegerPolynomial256.mult()` method

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

  fixed assertions in assembler_aarch64.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27946/files
  - new: https://git.openjdk.org/jdk/pull/27946/files/293ad948..ee2f01ac

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

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

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

From fferrari at openjdk.org  Tue Dec  2 21:12:44 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 2 Dec 2025 21:12:44 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v11]
In-Reply-To: <5D1Yihd-yhpCmCh7b-8GGc3OjFmBFumOwj3GnceIDpU=.61c6f036-4797-4902-8f54-90cdc6a822b5@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <f1LGOwCPsznfyr2PPV8WapM4335Th4oEs4kR_lT8bBM=.50f62482-94c8-490a-9e02-20c3d2958ea0@github.com>
 <tXOYQ_nde9pAdy2Gn_DhUzmLm9Lu02sf-mGI87I819Q=.758751d0-3684-4fdf-be8b-222ee93e13e3@github.com>
 <_HUUN67SsUDKiW4mhpPssp7bTD-BIiz0Ho1qyltjYeY=.afae4482-6158-4e73-aee1-351d1251d759@github.com>
 <5D1Yihd-yhpCmCh7b-8GGc3OjFmBFumOwj3GnceIDpU=.61c6f036-4797-4902-8f54-90cdc6a822b5@github.com>
Message-ID: <MuneGXU38xLu_noqZ0ZEAM_bmKaxnT3JHz39gezAh38=.833dec6d-f368-45f3-af58-fb0a4871bc39@github.com>

On Tue, 2 Dec 2025 20:00:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is a P3 bug and a regression, so it can be fixed after RDP1 and before RDP2. I have asked other members of our team to review this fix as I am busy with other work. Given that RDP1 is only a couple of days away and these additional reviews and changes are still ongoing, I don't think we can guarantee this will be integrated before RDP1, but hopefully you will have time after that to continue to address feedback, if needed.

@seanjmullan: ok, thank you for the time you've invested in this!

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3603976121

From duke at openjdk.org  Tue Dec  2 22:20:54 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 2 Dec 2025 22:20:54 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
Message-ID: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>

The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

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

Commit messages:
 - 8370688: Addressed review comments
 - 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays

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

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

From liach at openjdk.org  Tue Dec  2 22:20:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 22:20:55 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <LwEy6e2oMtJisdLpG8zrQ-Wzu9MUE2VbP0Lyjwf2Zi4=.a9ae257a-d177-49fb-8f63-692f75cc216c@github.com>

On Tue, 2 Dec 2025 20:28:50 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

I don't think we need to go this far as to add a new paragraph. Looking at examples like `Class::getMethods`, I think we can just change the first sentences of "Returns the ... objects" to "Returns an array containing the ... objects", which means the returned array is not the same as the underlying storage format.

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3604141759

From myankelevich at openjdk.org  Tue Dec  2 23:30:12 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 2 Dec 2025 23:30:12 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v4]
In-Reply-To: <C8Rxgt9PYJ8sGevbN6lpB7TzDr1dBUPJQMvXLm7DhSo=.4b9cf913-6c85-4ebb-a2b4-d3ed953a3aa8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <C8Rxgt9PYJ8sGevbN6lpB7TzDr1dBUPJQMvXLm7DhSo=.4b9cf913-6c85-4ebb-a2b4-d3ed953a3aa8@github.com>
Message-ID: <AwwCAuBcRffSeP05mST7W2sCE0vYab3WRU5EV8TSsUg=.9462ba82-1354-4d5d-996a-c57f8c0c1d76@github.com>

On Tue, 2 Dec 2025 17:28:02 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed few more review comments

Marked as reviewed by myankelevich (Committer).

Thanks for considering me as a contributor to this ticket! I really appreciate it. 
I personally feel that my suggestions weren't extensive enough to require adding me as a contributor, so there is need for it unless you think it's appropriate.

Overall the ticket looks good, thank you for your updates!

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

PR Review: https://git.openjdk.org/jdk/pull/28577#pullrequestreview-3532544581
PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3604376915

From liach at openjdk.org  Tue Dec  2 23:39:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 23:39:33 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <s91KIa-U1TCkwQiyiLNn9Hn-QDe09PRTeSh2cGkjKdU=.8cc880d8-5561-41de-8b83-38cf9b1f4099@github.com>

On Tue, 2 Dec 2025 20:28:50 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

Looks good in principle to indicate non-uniqueness. Please find security area reviewers to double check. You should also create a CSR for this specification change.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28615#pullrequestreview-3532560572

From liach at openjdk.org  Tue Dec  2 23:44:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 23:44:52 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <Bw5HVKGJxX91m-pD8AZmc3O9wPxQkZdkdaKqG8Gogg0=.c4243296-9d89-4bdf-b29d-619507d9a7f1@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
 <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
 <gkJvZM3qFdAIOmLdER0F7ypjYSBDeYHNUo8vyy3EKRQ=.265a55bb-d588-490c-8a11-8107e3c61d3b@github.com>
 <Bw5HVKGJxX91m-pD8AZmc3O9wPxQkZdkdaKqG8Gogg0=.c4243296-9d89-4bdf-b29d-619507d9a7f1@github.com>
Message-ID: <7EghUFcjt2c0McjKvpqtG837D_SdF8cTDPjAY9zxr4M=.d6f5e2e3-b0d3-479e-8f19-94e0910283ad@github.com>

On Tue, 2 Dec 2025 20:08:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarFile.java line 1047:
>> 
>>> 1045:                 jvInitialized = true;
>>> 1046:             }
>>> 1047:         });
>> 
>> You can consider shortening this using a lambda:
>> 
>> 
>> ScopedValue.where(IN_VERIFIER_INIT, true).run(() -> {
>>     initializeVerifier();
>>     jvInitialized = true;
>> });
>
> Yes, but I think would be prudent to run startup benchmarks if you change that.

Using a lambda is probably fine given the AOT cache can archive lambdas and avoid the bytecode generation cost.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2583136671

From duke at openjdk.org  Tue Dec  2 23:51:20 2025
From: duke at openjdk.org (Deirdre Connolly)
Date: Tue, 2 Dec 2025 23:51:20 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
Message-ID: <qAg9B-axuBboFeFZGxxDlu2nAvc3d3_2y4lLzaw9_EM=.78a8e5a9-2c6e-4d80-a1cc-4ec6d6926900@github.com>

On Mon, 24 Nov 2025 07:51:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update names to uppercase
>  - Remove fallback in engineGeneratePublic
>  - Change default named group list to have only X25519MLKEM768

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 231:

> 229:     ML_KEM_1024(0x0202, "MLKEM1024",
> 230:             NamedGroupSpec.NAMED_GROUP_KEM,
> 231:             ProtocolVersion.PROTOCOLS_OF_13,

These are needed in general, should we write up a JEP to support them explicitly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2583145498

From weijun at openjdk.org  Wed Dec  3 00:03:16 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 3 Dec 2025 00:03:16 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <qAg9B-axuBboFeFZGxxDlu2nAvc3d3_2y4lLzaw9_EM=.78a8e5a9-2c6e-4d80-a1cc-4ec6d6926900@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <qAg9B-axuBboFeFZGxxDlu2nAvc3d3_2y4lLzaw9_EM=.78a8e5a9-2c6e-4d80-a1cc-4ec6d6926900@github.com>
Message-ID: <Vg1i9tkadn9lbSWOE9jYeuEEpC57LTGT4M4HP3y8ECI=.bb45f666-51c6-472e-aa66-7393847810d4@github.com>

On Tue, 2 Dec 2025 23:48:12 GMT, Deirdre Connolly <duke at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - Change default named group list to have only X25519MLKEM768
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 231:
> 
>> 229:     ML_KEM_1024(0x0202, "MLKEM1024",
>> 230:             NamedGroupSpec.NAMED_GROUP_KEM,
>> 231:             ProtocolVersion.PROTOCOLS_OF_13,
> 
> These are needed in general, should we write up a JEP to support them explicitly?

The current JEP does not cover them. Our plan is to support them in a future enhancement (not as big as a JEP).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2583163312

From schernyshev at openjdk.org  Wed Dec  3 00:42:25 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 3 Dec 2025 00:42:25 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

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

  test that ipv4 literals do not propagate to the server names list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28577/files
  - new: https://git.openjdk.org/jdk/pull/28577/files/44ed7ddb..5c78ce2c

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

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

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

From schernyshev at openjdk.org  Wed Dec  3 00:42:27 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 3 Dec 2025 00:42:27 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v4]
In-Reply-To: <AwwCAuBcRffSeP05mST7W2sCE0vYab3WRU5EV8TSsUg=.9462ba82-1354-4d5d-996a-c57f8c0c1d76@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <C8Rxgt9PYJ8sGevbN6lpB7TzDr1dBUPJQMvXLm7DhSo=.4b9cf913-6c85-4ebb-a2b4-d3ed953a3aa8@github.com>
 <AwwCAuBcRffSeP05mST7W2sCE0vYab3WRU5EV8TSsUg=.9462ba82-1354-4d5d-996a-c57f8c0c1d76@github.com>
Message-ID: <LZwm4UozFDb-kK2x2JoO73y9stLD_em3m0jPCZXUb2I=.89433e0e-59e8-430e-a873-c3e60e8467d3@github.com>

On Tue, 2 Dec 2025 23:26:41 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressed few more review comments
>
> Thanks for considering me as a contributor to this ticket! I really appreciate it. 
> I personally feel that my suggestions weren't extensive enough to require adding me as a contributor, so there is need for it unless you think it's appropriate.
> 
> Overall the ticket looks good, thank you for your updates!

@myankelev Thank you for in-depth review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3604526590

From schernyshev at openjdk.org  Wed Dec  3 00:42:28 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 3 Dec 2025 00:42:28 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <Mjjj0j9tUB5JYow7B2AUTM8bSdxAIRdzakhH0aE-Mjk=.8ae3faba-bbf7-4ee6-8493-df968bcb20a1@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <iLHJNpyE25UXOWhAInVLgScw1GKgNRp1kqa3tAOqPzg=.2d2c925a-20e1-477f-a83f-9e381efb9154@github.com>
 <PoeBw3wuGY9DfpYrIinzpo9-OPvv3KkSqi8iMl9c5nM=.8c999e41-2ae8-4e1d-9663-1e9d869875bc@github.com>
 <IHcL_eqNIg2ldJ3DvM1CqFcCgJHscX9C0MMreyo4XMc=.8bebe0db-6c3a-4d8c-96df-a33808aa680c@github.com>
 <5Xi3KzSpKO5zUPBdESbgG7zc7JQmTjwjWgyVxiqN3Ic=.2464c8db-275e-43b7-9893-4c7cefac9f0e@github.com>
 <Mjjj0j9tUB5JYow7B2AUTM8bSdxAIRdzakhH0aE-Mjk=.8ae3faba-bbf7-4ee6-8493-df968bcb20a1@github.com>
Message-ID: <0Mx2dW6pF5TeWOK9yE8NdzrU3tQaPrYbwGSIzrgLSE4=.94aee8c0-8aaa-4c30-b155-8b02431212e8@github.com>

On Tue, 2 Dec 2025 14:47:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> @djelinski would you think such a negative test is needed here?
>
>> On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1/' is requested?
> 
> No, such test would fail whether we use setServerNames or not.
> 
> I think @vy is asking for a check that the SSLParameters passed to SSLSocket#setSSLParameters have no serverNames configured. That should be reasonably easy to do.

@djelinski @vy We could check the SSL parameters of the internal SSLSocket if the wrapper socket factory passed the inner SSLSocket to the caller. Please take a look at the updated test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2583227229

From fferrari at openjdk.org  Wed Dec  3 01:48:03 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 3 Dec 2025 01:48:03 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <Hjk_9_jcAHvuK15eFMtQpvd0kTxGcrGYSOw5efGUhH0=.2b7a5c6f-8814-44d9-8a50-f1a71c4ba9bc@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>
 <RqBLdkwG_qLbJIuf-vuLasv85aavUABXFatlQ-7BwSM=.d66b0efb-703b-47e0-a25c-97a5289a1fd1@github.com>
 <41RTmykCC1A-4ExHq7HWsqmlS5lobm0PVxDub7P85j0=.281cee13-471e-4863-917e-0bf3094335b6@github.com>
 <2y7XZvrGxz-h2azJRkuC-4K4h4QBA4GdrfHwE3426oA=.ad803ea6-ebea-4bfa-bd4a-58fadec9093c@github.com>
 <LBAoDLHX4VrHwsONt4foz92g8MeFgdwCOeMtJPyq028=.f4668d90-88a2-43cf-859a-8a4759b1b7a7@github.com>
 <Hjk_9_jcAHvuK15eFMtQpvd0kTxGcrGYSOw5efGUhH0=.2b7a5c6f-8814-44d9-8a50-f1a71c4ba9bc@github.com>
Message-ID: <s6kq1usp0SVX87T1UVQM-hiY3CUhMDnolTejgpFwWEY=.689bfde9-0400-441a-8849-87bafbc8a654@github.com>

On Tue, 2 Dec 2025 16:15:45 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Ok, thanks for the explanation. I agree it is a rare case, but now I think maybe a debug statement is better than throwing an `InternalError` since it seems like the code can still recover and continue w/o unexpected behavior - would you agree?
>
> Yes, I will update it.

Done in f16e991cb50292802cfbe89a80fd47d5dbf14b4f.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2583349254

From fferrari at openjdk.org  Wed Dec  3 01:48:01 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 3 Dec 2025 01:48:01 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <azrp_OyQO33R2skJ2f6krdLgnk2co6OyI9rhR0qTGxo=.441c77aa-ecb3-43c3-98f6-9957eac708e6@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <prtiPTk2aZ_1M1-3ANQAp1HkUwBoqTEZazAsG7IFiaI=.11b3d0a4-df30-48e0-ba13-50ee71e3f34e@github.com>
 <ieJiU8FT7ssLPJ9dn9y32QI2POt5XSmGlIjjBMIGS7Q=.8ac6faad-1ad8-4bcc-abb3-992b6dd3bd0e@github.com>
 <azrp_OyQO33R2skJ2f6krdLgnk2co6OyI9rhR0qTGxo=.441c77aa-ecb3-43c3-98f6-9957eac708e6@github.com>
Message-ID: <wBHQvr84x4j6TUc5OYkAGXQfXGNrSEEE8FhPN_rwE8I=.488d0e4d-d9d1-4094-8367-6c6a20341b53@github.com>

On Tue, 2 Dec 2025 18:18:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> By "file writer" I mean the person who wrote the properties file issuing a relative `include` directive. But it is definitively confusing, how about the following?
>> 
>>                     // We perform symlinks resolution on currentPath
>>                     // under the rationale that the person writing the
>>                     // original properties file is the one who decided
>>                     // where the relative includes should resolve.
>
> I see, thanks for explaining. The corrected version looks good to me except I would replace `the one who decided` with `the one who decides`

Thanks, I updated it including your suggestion: cedd43f9d4c39f55752df375103670c0a0e4df5f.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2583350078

From fferrari at openjdk.org  Wed Dec  3 01:48:00 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 3 Dec 2025 01:48:00 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>

> Hi, this is a proposal to fix 8352728.
> 
> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following:
> 
> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
> 
> #### Windows Case
> 
> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
> 
> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/java.base/windows/native/libjava/c...

Francisco Ferrari Bihurriet has updated the pull request incrementally with three additional commits since the last revision:

 - Convert ConfigFileTestAnonymousPipes to Java
 - Review suggestion: go back tolerating IOException
   
   We agreed an IOException in this case is recoverable, and decided to
   tolerate it, while adding a debug log message with the exception.
 - Review suggestion: improve comment clarity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24465/files
  - new: https://git.openjdk.org/jdk/pull/24465/files/4e7206c0..51a3ce86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=12-13

  Stats: 153 lines in 3 files changed: 87 ins; 61 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24465/head:pull/24465

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

From fferrari at openjdk.org  Wed Dec  3 01:49:05 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 3 Dec 2025 01:49:05 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v13]
In-Reply-To: <cbP1RlSR-BwieliyM6guzvXbcBeyZsZBBpzW5hdve-M=.d0e69907-484d-4984-9f29-c698d9b108d1@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <UvnNUCcxAZcSVY0JjfrBivRgN_T1DvB1cYVZq6uAw7E=.0a7390ac-7fec-40dd-9bf9-29fc2aae0824@github.com>
 <IStCignijKSnbT7wdpK9lwjraJEZugbQb12PAlREmyg=.03694ee8-3284-49fa-b614-4152da34d0d1@github.com>
 <cbP1RlSR-BwieliyM6guzvXbcBeyZsZBBpzW5hdve-M=.d0e69907-484d-4984-9f29-c698d9b108d1@github.com>
Message-ID: <L4DM_jezQGL3S5gz1bd7yZg_KFIiDynapZsoKlBLLl8=.92c61212-8b97-4567-ab04-a6dc17646c06@github.com>

On Tue, 2 Dec 2025 19:53:23 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> test/jdk/java/security/Security/ConfigFileTestAnonymousPipes.sh line 1:
>> 
>>> 1: #
>> 
>> This test failed on linux-x64 and linux-aarch64 on our test systems. Here's a snippet of the logfile:
>> 
>> 
>> properties[0x3|main|Security.java:160|2025-12-02 13:35:48.066]: unable to load security properties from <(echo include /dev/stdin)
>> java.io.FileNotFoundException: <(echo include /dev/stdin)
>> 	at java.base/java.security.Security$SecPropLoader.loadExtraFromPath(Security.java:209)
>> 	at java.base/java.security.Security$SecPropLoader.loadExtraHelper(Security.java:178)
>> 	at java.base/java.security.Security$SecPropLoader.loadExtra(Security.java:157)
>> 	at java.base/java.security.Security$SecPropLoader.loadAll(Security.java:122)
>> 	at java.base/java.security.Security.initialize(Security.java:337)
>> 	at java.base/java.security.Security.<clinit>(Security.java:326)
>> 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
>> 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1195)
>> 	at java.base/java.lang.invoke.MethodHandles$Lookup.ensureInitialized(MethodHandles.java:2750)
>> 	at java.base/jdk.internal.access.SharedSecrets.ensureClassInitialized(SharedSecrets.java:504)
>> 	at java.base/jdk.internal.access.SharedSecrets.getJavaSecurityPropertiesAccess(SharedSecrets.java:320)
>> 	at java.base/sun.launcher.SecuritySettings.printSecurityProperties(SecuritySettings.java:88)
>> 	at java.base/sun.launcher.SecuritySettings.printSecuritySettings(SecuritySettings.java:63)
>> 	at java.base/sun.launcher.LauncherHelper.showSettings(LauncherHelper.java:172)
>
> Looks like `<(echo include /dev/stdin)` is being interpreted literally, instead of defining a [Bash Process Substitution](https://www.gnu.org/software/bash/manual/html_node/Process-Substitution.html).
> 
> Thinking Bash would be the execution shell on all the platforms was probably a wrong assumption. Let me see if I can replace it by something else, otherwise I will need to give up and remove that second one.
> 
> The first one must be passing, otherwise it would have exited without getting to the second one:
> 
> https://github.com/openjdk/jdk/blob/4e7206c082e4b0152d999b32eba0063a506eff67/test/jdk/java/security/Security/ConfigFileTestAnonymousPipes.sh#L54

I managed to convert it to a Java test: 51a3ce86649e2e44048ae6028aea1edf0a72812d.

I would greatly appreciate if someone can run the new version in the same testing environment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2583355106

From duke at openjdk.org  Wed Dec  3 05:08:56 2025
From: duke at openjdk.org (Lei Zhu)
Date: Wed, 3 Dec 2025 05:08:56 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags [v4]
In-Reply-To: <NZxu9VbPJdfVybSCKT6Nw0INMAUlDMicqKJvMQHS6vg=.61537368-126c-4c74-b020-47feea7e4cd8@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
 <NZxu9VbPJdfVybSCKT6Nw0INMAUlDMicqKJvMQHS6vg=.61537368-126c-4c74-b020-47feea7e4cd8@github.com>
Message-ID: <sxZOjNIZOZhJeaheA0f-QtvP9sml7o_DP42zXJdMP1E=.2180c300-f259-4dda-a7a9-74d4fcfc3def@github.com>

On Fri, 21 Nov 2025 12:31:28 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.
>> 
>> ### ISSUE :- 
>> In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
>>     
>> -> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();
>> 
>>>   public static String[] addTestJavaOpts(String... userArgs) {
>>>         return prependTestJavaOpts(userArgs);
>>>     }
>> 
>> -> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()
>> 
>>> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>>>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>>>     }
>> 
>> 
>> Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )
>> 
>>> public static String[] getTestJavaOpts() {
>>>         List<String> opts = new ArrayList<String>();
>>>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>>>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>>>         return opts.toArray(new String[0]);
>>>     }
>> 
>> Contributed-by: @Korov 
>> https://github.com/openjdk/jdk/pull/26404
>> 
>> https://bugs.openjdk.org/browse/JDK-8362658
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Removed the list of test case from problemList file.

Looks good to me

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

PR Comment: https://git.openjdk.org/jdk/pull/28428#issuecomment-3605106466

From jpai at openjdk.org  Wed Dec  3 05:21:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Dec 2025 05:21:55 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <7EghUFcjt2c0McjKvpqtG837D_SdF8cTDPjAY9zxr4M=.d6f5e2e3-b0d3-479e-8f19-94e0910283ad@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
 <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
 <gkJvZM3qFdAIOmLdER0F7ypjYSBDeYHNUo8vyy3EKRQ=.265a55bb-d588-490c-8a11-8107e3c61d3b@github.com>
 <Bw5HVKGJxX91m-pD8AZmc3O9wPxQkZdkdaKqG8Gogg0=.c4243296-9d89-4bdf-b29d-619507d9a7f1@github.com>
 <7EghUFcjt2c0McjKvpqtG837D_SdF8cTDPjAY9zxr4M=.d6f5e2e3-b0d3-479e-8f19-94e0910283ad@github.com>
Message-ID: <PKlMKRYAxlz7MPnNr15Dhhf3BDGq3TraYsztwm44udM=.f96ce877-34f7-4f64-a2c8-497e4108efd2@github.com>

On Tue, 2 Dec 2025 23:42:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Yes, but I think would be prudent to run startup benchmarks if you change that.
>
> Using a lambda is probably fine given the AOT cache can archive lambdas and avoid the bytecode generation cost.

Hello Volkan, like Alan notes, for classes that get used very early in the startup, like the JarFile, we have avoided using lambdas so that it doesn't bring in additional lambda related infrastructure during the early startup.

I don't plan to run any performance analysis for this change, so I'll let the change stay in its current form.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2583654376

From alanb at openjdk.org  Wed Dec  3 07:31:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Dec 2025 07:31:04 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
 <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
Message-ID: <x9mXQl2sFRidonwYmx8KAjQlQ6tVt_vM39mFPcf-5qc=.e05e04d7-b226-496b-a7fe-b20a3891fefa@github.com>

On Tue, 2 Dec 2025 16:56:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101.
>> 
>> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API.
>> 
>> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Runnable() instead of CallableOp

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28609#pullrequestreview-3533568653

From alanb at openjdk.org  Wed Dec  3 07:31:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Dec 2025 07:31:06 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <PKlMKRYAxlz7MPnNr15Dhhf3BDGq3TraYsztwm44udM=.f96ce877-34f7-4f64-a2c8-497e4108efd2@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
 <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
 <gkJvZM3qFdAIOmLdER0F7ypjYSBDeYHNUo8vyy3EKRQ=.265a55bb-d588-490c-8a11-8107e3c61d3b@github.com>
 <Bw5HVKGJxX91m-pD8AZmc3O9wPxQkZdkdaKqG8Gogg0=.c4243296-9d89-4bdf-b29d-619507d9a7f1@github.com>
 <7EghUFcjt2c0McjKvpqtG837D_SdF8cTDPjAY9zxr4M=.d6f5e2e3-b0d3-479e-8f19-94e0910283ad@github.com>
 <PKlMKRYAxlz7MPnNr15Dhhf3BDGq3TraYsztwm44udM=.f96ce877-34f7-4f64-a2c8-497e4108efd2@github.com>
Message-ID: <enPHYlnuF-uxo4BfKy-14jT1kom2ymMDE2I2ZJfzm4o=.109548b6-21b0-4393-b6bc-be91448d4637@github.com>

On Wed, 3 Dec 2025 05:19:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Volkan, like Alan notes, for classes that get used very early in the startup, like the JarFile, we have avoided using lambdas so that it doesn't bring in additional lambda related infrastructure during the early startup.
> 
> I don't plan to run any performance analysis for this change, so I'll let the change stay in its current form.

Chen may be right but we could need to re-run startup benchmarks as the signed JAR cases are historically problematic and have bitten the fingers of everyone that has touched it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2583946844

From djelinski at openjdk.org  Wed Dec  3 07:37:05 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Dec 2025 07:37:05 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
Message-ID: <Q9Z0WlGT3DWGyHVL926TMf2SWa5lWVVUk2cCcKSh-8M=.37c97ae2-9823-4c44-888b-ac64ff4c0cd3@github.com>

On Wed, 3 Dec 2025 00:42:25 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test that ipv4 literals do not propagate to the server names list

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 103:

> 101:         OutputStream sslOS = sslSocket.getOutputStream();
> 102:         BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(sslOS));
> 103:         bw.write("HTTP/1.1 200 OK\r\n\r\n\r\n");

Suggestion:

        bw.write("HTTP/1.1 200 OK\r\n\r\n");

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 105:

> 103:         bw.write("HTTP/1.1 200 OK\r\n\r\n\r\n");
> 104:         bw.flush();
> 105:         sslSocket.close();

Now that you removed the Thread.sleep, you can't close the socket without reading the request off the input stream; it will cause intermittent connection reset failures on Windows. You can use the [readOneRequest method](https://github.com/openjdk/jdk/blob/530493fed4066b1efcf3ec22253b110495767eca/test/jdk/sun/net/www/http/HttpClient/CookieHttpClientTest.java#L77-L89).

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 122:

> 120:         if (!ready) {
> 121:             throw new RuntimeException("Server timed out.");
> 122:         }

Suggestion:

        serverReady.await();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2583948756
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2583948186
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2583955178

From djelinski at openjdk.org  Wed Dec  3 07:59:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Dec 2025 07:59:01 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v3]
In-Reply-To: <gts4SYkcbfDLFF3hTv449tZTu7pmjdI0hrhYcVNhS8I=.32c3ee5d-f4fd-4e69-ac53-b54af7fb2764@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <gts4SYkcbfDLFF3hTv449tZTu7pmjdI0hrhYcVNhS8I=.32c3ee5d-f4fd-4e69-ac53-b54af7fb2764@github.com>
Message-ID: <QtT6f0ExwiCH5SE6ZeUO6MKCoQyB59OMFmPu9-jlMTI=.b5925d72-457d-4325-8a4b-a9a72a0a3e95@github.com>

On Mon, 1 Dec 2025 16:11:14 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert logging changes

I'd keep at least some of the class JavaDoc. Other than that, LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28275#pullrequestreview-3533655866

From alanb at openjdk.org  Wed Dec  3 08:44:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Dec 2025 08:44:14 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <YjudxhBPug-ddmXbEvXNBAUfc9dE6085Qr6-xpbJW7s=.78ece7a7-31fe-45b8-b443-2caad8f5c036@github.com>

On Tue, 2 Dec 2025 20:28:50 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

There are a lot of APIs that return an array. Some of them use an array internally and so need to make a defensive copy/clone to return. Jai may be able to say more on the motivation for JDK-8370688. Maybe a concern with code uses identity to check equality, or maybe the concern was that the caller could modify the JarEntry's certs/signers by modifying the array?

I don't think the proposed change addresses either concern. We could potentially change the `@return` description to say that it returns a new array, which makes it a testable assertion. There are many other methods that return arrays, including other methods that return arrays of certs and code signers so we might want to change these at the same time.

@seanjmullan @wangweij Do you know if there has been any discussion about deprecating getCertificates? Developers have been re-directed to use getCodeSigners since JDK 5.

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3605690364

From vyazici at openjdk.org  Wed Dec  3 08:53:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 3 Dec 2025 08:53:41 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
Message-ID: <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>

On Wed, 3 Dec 2025 00:42:25 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test that ipv4 literals do not propagate to the server names list

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 31:

> 29:  * @library /test/lib
> 30:  * @comment Insert -Djavax.net.debug=all into the following lines to enable SSL debugging
> 31:  * @run main/othervm SubjectAltNameIPv6 127.0.0.1

Since we also test against IPv4, I'd remove the mention of IPv6 from the class name (e.g., `SubjectAltNameIP`) and `@summary`.

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 136:

> 134:          */
> 135:         conn.setSSLSocketFactory(wrapSocketFactory(sf,
> 136:                 sslSocket -> clientSSLSocket = sslSocket));

Shall we first assert that `clientSSLSocket == null` before assignment?

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 140:

> 138: 
> 139:         var sniSN = clientSSLSocket.getSSLParameters().getServerNames();
> 140:         if( sniSN != null && !sniSN.isEmpty()) {

`if( sniSN` ? `if (sniSN`

test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 152:

> 150:     public static void main(String[] args) throws Exception {
> 151: 
> 152:         if (!IPSupport.hasIPv6()) {

Suggestion:

        if (IPAddressUtil.isIPv6LiteralAddress(args[0]) && !IPSupport.hasIPv6()) {


Note that you need to import `sun.net.util.IPAddressUtil` first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2584149111
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2584153074
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2584160215
PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2584176475

From jpai at openjdk.org  Wed Dec  3 09:19:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Dec 2025 09:19:50 GMT
Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in
 java.util.jar.JarFile [v2]
In-Reply-To: <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
 <ua9WDqeL7uFmsiLXlRgjmn8JpnZPDEirTmyqN-gNcFI=.43be8027-0813-41fd-ac21-c388df542e50@github.com>
Message-ID: <MmZbAH1_dgCFZ_rgsJakYJmflGlO6d7YGyThVEGtG88=.9809d4d0-ace2-482f-9f05-09a8da981319@github.com>

On Tue, 2 Dec 2025 16:56:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101.
>> 
>> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API.
>> 
>> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Runnable() instead of CallableOp

Thank you all for the reviews. tier1, tier2 and tier3 testing completed with this change without any issues. I'll integrate this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/28609#issuecomment-3605829370

From jpai at openjdk.org  Wed Dec  3 09:19:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Dec 2025 09:19:51 GMT
Subject: Integrated: 8366101: Replace the use of ThreadTracker with ScopedValue
 in java.util.jar.JarFile
In-Reply-To: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
References: <HbPeI2ZeeQfrwCT6OfU_bmBV9radB4XrYBsuiFUXzqU=.6053a454-2c63-498a-a6e4-14df7c0505cb@github.com>
Message-ID: <9oz8VKJ7ugkDCVxXojRliR7aUcJV7B8OrQFHyQA2mvE=.befb8f56-a887-4ca7-9e25-e5a48f89084a@github.com>

On Tue, 2 Dec 2025 15:44:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101.
> 
> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API.
> 
> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change.

This pull request has now been integrated.

Changeset: e65fd45d
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e65fd45dc7c9383a77fbd5171b541c2a003d30d2
Stats:     31 lines in 1 file changed: 11 ins; 15 del; 5 mod

8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile

Reviewed-by: vyazici, alanb

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

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

From hchao at openjdk.org  Wed Dec  3 09:20:47 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 09:20:47 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v10]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <ZpsH3J8q8PZTcdld1EUxJEjx6av9yDBy-nTKtUlUMhQ=.1f690c30-00e7-42cd-a736-380a456fad30@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

 - Updates with Brad's and Sean's comments
 - Move Hybrid.java to sun.security.ssl
 - Move DH.java to sun.security.ssl as DHasKEM.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/194ca589..00d49181

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=08-09

  Stats: 936 lines in 12 files changed: 440 ins; 386 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From hchao at openjdk.org  Wed Dec  3 09:20:49 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 09:20:49 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <BcX9xdm4WP-5derCSKKHpg13aZI4A-IUmoE_aL_xiOY=.c8a82466-96d8-42b5-bc67-544de4927235@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <M0_MNSViTpDaV_-ek4AXkQ-_QiQgpuRBcP-9h1nY8VI=.8be542c8-f3a1-4dcc-b004-280ce9a9286f@github.com>
 <SjX0xqXCA4FsBab_DIX4lG17zSc_OrQx5P9Y-Zn9sFE=.d46430f4-1912-4df2-b552-31c268a18d47@github.com>
 <4Ab4lEzxzAL0YOlNUhk1znrIXcbZheuHNewZ-0hzvak=.cbb45d96-2269-4c7f-87e9-540224a07bb9@github.com>
 <nQKlt0nesBkWqzs-qqIU39WTwxbxh4SMZnLFgMX20Is=.5a10b51e-4e78-451c-95c5-3747e45c9f04@github.com>
 <BcX9xdm4WP-5derCSKKHpg13aZI4A-IUmoE_aL_xiOY=.c8a82466-96d8-42b5-bc67-544de4927235@github.com>
Message-ID: <YlWhcxoN32TC6dMSK0Nrec061pOtikHU8ZOPeJ5C3lM=.b7a72f12-ac53-449f-8caf-4ac04a849f93@github.com>

On Mon, 1 Dec 2025 21:42:12 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Also, if it is only used by JSSE, I think it should be in the `sun.security.ssl` package.
>
> We did include the internal `Tls*` implementations Sun in the `SunJCE` provider, but those were actually exposed/available as `KeyGenerator`s.  I was never a fan, but it is what it is.  
> 
> `sun.security.ssl` is a better fit for this and `Hybrid.java`, especially since these are strictly internal implementations for now.

> The purpose of this class from the opening javadoc was confusing on my first several reads. I expected that this class just created a `KEM` layer for DH, but surprise(!), it also crammed in a Hybrid provider implementation too!
> 
> My preference is to break the `DH` and `Provider`+`HybridService` code into separate files for cleaner abstractions, but if not, then maybe use something like this for the description?
> 
> ```
> /**
>  * The DH class presents a KEM abstraction layer over traditional 
>  * DH-based key exchange, which can be used for either straight
>  * DH/ECDH/XDH or TLS hybrid key exchanges.
>  * 
>  * This class can be alongside standard full post-quantum KEMs
>  * when hybrid implementations are required.
>  */
> ```

Added description as suggested.

> Could this class could be renamed to something more meaningful? e.g. `DHasKEM`, `DHasaKEM` or something similar. A class name of `DH` by itself hints this will be a DH implementation. I would expect a `KeyAgreement` impl, not as a wrapper.

Renamed `DH.java` to `DHasKEM.java`.

> One other nit, currently the `Params` class doesn't actually handle `DH`, just `ECDH`/`XDH`. Should you remove `DH` from the `DH/ECDH/XDH` javadoc?

Removed `DH`.

> Also, if it is only used by JSSE, I think it should be in the `sun.security.ssl` package.

Moved it to `sun.security.ssl` package.

> We did include the internal `Tls*` implementations Sun in the `SunJCE` provider, but those were actually exposed/available as `KeyGenerator`s. I was never a fan, but it is what it is.
> 
> `sun.security.ssl` is a better fit for this and `Hybrid.java`, especially since these are strictly internal implementations for now.

Move done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584262600

From hchao at openjdk.org  Wed Dec  3 09:21:00 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 09:21:00 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <M0_MNSViTpDaV_-ek4AXkQ-_QiQgpuRBcP-9h1nY8VI=.8be542c8-f3a1-4dcc-b004-280ce9a9286f@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <M0_MNSViTpDaV_-ek4AXkQ-_QiQgpuRBcP-9h1nY8VI=.8be542c8-f3a1-4dcc-b004-280ce9a9286f@github.com>
Message-ID: <6hteHKAW4pIAfIWbzD2JuSMb1zwNwqFe68xdY8ebpcM=.4f15fa8d-5e91-4fc4-8b32-a19bbbb53772@github.com>

On Wed, 26 Nov 2025 00:19:13 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - Change default named group list to have only X25519MLKEM768
>
> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 75:
> 
>> 73:         private static final long serialVersionUID = 0L;
>> 74:         private ProviderImpl() {
>> 75:             super("InternalJCE", PROVIDER_VER, "");
> 
> Maybe include an `info` String here?

Added.

> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 75:
> 
>> 73:         private static final long serialVersionUID = 0L;
>> 74:         private ProviderImpl() {
>> 75:             super("InternalJCE", PROVIDER_VER, "");
> 
> Wondering if we might use another name here for the Provider?
> 
> Perhaps `InternalSunJCE`, `InternalJCEKEM`, `InternalJCEHybridJSSE`, `InternalJCEHybridJSSEKEM`, or something similar?
> 
> This may not be necessary, but would help indicate what this is.

Changed the provider name to` InternalJCEDHasKEM`.

> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 82:
> 
>> 80:             // The order of shares in the concatenation for group name
>> 81:             // X25519MLKEM768 has been reversed. This is due to historical
>> 82:             // reasons.
> 
> `...due to IETF historical reasons...`, not JSSE reasons.

Fixed to say `due to IETF.`  Also added some comments for the Provider.

> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 251:
> 
>> 249:                 "XDH", "XDH", NamedParameterSpec.X448),
>> 250:         ;
>> 251:         private final int Nsecret;
> 
> Minor nits:  lower case name starting letters.  
> 
> Maybe `nSecret`/`secretLen` and `nPK`/`publicKeyLen`
> 
> (Is the N prefix a Solaris convention?)

Changed names as suggested. (N prefix is from the DHKEM class)

> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 139:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Is this method actually called?  (I didn't see it in `KEMKeyExchange.KEMReceiverPossession`).  
> 
> I know the method is needed to fully extend the `KeyPairGeneratorSpi`, but it looks like we're doing the actual initialization of both sides in the constructor, and that is considered it's "default method of initialization."
> 
> This duplicate code could probably be removed, and just be a NO-OP.

Changed it to NO-OP.

> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 239:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Maybe add "KeySpec type: " to the Exception message?

Added `KeySpec type:`.

> src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 580:
> 
>> 578:                     shc.handshakeKeyExchange = ke;
>> 579:                     shc.handshakePossessions.add(pos);
>> 580: 
> 
> Noticed several <=80 lines throughout the code.  Will mention just here.
> 
> It helps when reviewing side-by-side not having to vertically scroll.
> 
> Thanks.

Fixed > 80 chars for the code changes in sun.security.ssl package.

> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 568:
> 
>> 566:             shc.serverHelloRandom = shm.serverRandom;
>> 567: 
>> 568:             // Key Encapsulation Mechanism (KEM):
> 
> I really like the details you included here, but a little wordsmithing would improve readability.  
> 
> Can you please add an intro sentence like:  "For key derivation, we'll either use the KA or a KEM model, depending on what group is used."  
> 
> Then add some of the lines from 579-584, then do the KEM and KA sections, and move the final sentence to the KEM section.  
> 
> I think this would read much cleaner.

Updated the comments. Hope it is more cleaner.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 35:
> 
>> 33: import javax.crypto.KEMSpi;
>> 34: import javax.crypto.SecretKey;
>> 35: import java.io.ByteArrayOutputStream;
> 
> import no longer needed.

import removed.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 57:
> 
>> 55: public class Hybrid {
>> 56: 
>> 57:     public record SecretKeyImpl(SecretKey k1, SecretKey k2) implements SecretKey {
> 
> Minor nit:  consider moving`SecretKeyImpl` to keep all the keys `PrivateKeyImpl`/`PublicKeyImpl` together?

Moving done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584262244
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584263097
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584263966
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584263346
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584265282
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584265795
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584262066
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584266212
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584262853
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584265543

From hchao at openjdk.org  Wed Dec  3 09:21:01 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 09:21:01 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <OwSN1t4pvmevhR6Sg_CZpef4XFiaI_iDQZl_45sCEn8=.1b3dea8c-ffa4-40c3-9084-d4f347292c8f@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <M0_MNSViTpDaV_-ek4AXkQ-_QiQgpuRBcP-9h1nY8VI=.8be542c8-f3a1-4dcc-b004-280ce9a9286f@github.com>
 <fj3JewRv0ppeGNexhDFVgZk-dS3kbUsfP62GSmHgdOQ=.c408bfbf-30a6-49f7-b3c4-b46acec64184@github.com>
 <TS4NOHk_6bs-vr9P7J0N6R1TUn1Nd6DrwbyrCGLm_94=.a1553315-7a58-4150-a257-c7331f4f9f22@github.com>
 <OwSN1t4pvmevhR6Sg_CZpef4XFiaI_iDQZl_45sCEn8=.1b3dea8c-ffa4-40c3-9084-d4f347292c8f@github.com>
Message-ID: <P7zUV9_SR5dg_lsFbuXTiQKzNka69_6IrNlZELNYK9Q=.739a69a0-10dd-44e8-8a0b-acb33d1dbc3f@github.com>

On Mon, 1 Dec 2025 21:47:17 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> I would put `Hybrid` in `sun.security.ssl`. If at some point in the future, it becomes more generally valuable outside of JSSE, we can restructure/move it.
>
> Agreed.

Moved Hybrid.java to sun.security.ssl package.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584263613

From hchao at openjdk.org  Wed Dec  3 09:21:19 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 09:21:19 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <ygDE87sA6c4qIkX65GviP1qfh42xjIQ3NBm_o2GFmLk=.791c1ed5-861b-4bfc-b025-3fc1ac3e0124@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <ygDE87sA6c4qIkX65GviP1qfh42xjIQ3NBm_o2GFmLk=.791c1ed5-861b-4bfc-b025-3fc1ac3e0124@github.com>
Message-ID: <Xb9mk6G5X5ZXJ9n_H2oa00XkdKGf4E_ZZlN72IWaDz8=.edaebca0-0cbd-401d-b8b4-8cd3cc84a18a@github.com>

On Mon, 1 Dec 2025 17:25:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - Change default named group list to have only X25519MLKEM768
>
> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 55:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Add a few comments describing this class.

Done.

> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 54:
> 
>> 52:     private final PublicKey peerPublicKey;
>> 53:     private final byte[] keyshare;
>> 54:     private final java.security.Provider provider;
> 
> Add `java.security.Provider` to imports.

Done.

> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 162:
> 
>> 160:      * to encapsulate a shared secret and returns the encapsulated message.
>> 161:      */
>> 162:     public KEM.Encapsulated encapsulate(String algorithm)
> 
> Can this be package-private?

Yes, done.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 35:
> 
>> 33: import sun.security.x509.X509Key;
>> 34: 
>> 35: import javax.crypto.SecretKey;
> 
> Move this import up, after line 29.

Done.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 47:
> 
>> 45:     static final class KEMCredentials implements NamedGroupCredentials {
>> 46: 
>> 47:         final NamedGroup namedGroup;
> 
> Make private, also line 50.

Can not make this line `private` for `namedGroup` as `KeyShareExtension.SHKeyShareProducer::produce()` needs access. Made `private` for the line 50.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 67:
> 
>> 65:         }
>> 66: 
>> 67:         public byte[] getKeyshare() {
> 
> Nit, suggest renaming as "getKeyShare()" since RFC refers to these as two words: "key share".

Renaming done.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 77:
> 
>> 75: 
>> 76:         /**
>> 77:          * Parse the encoded Point into the KEMCredentials using the
> 
> This doesn't do any parsing, it just instantiates a `KEMCredentials` object.

Fixed.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 82:
> 
>> 80:         static KEMCredentials valueOf(NamedGroup namedGroup,
>> 81:                 byte[] encodedPoint) throws IOException,
>> 82:                 GeneralSecurityException {
> 
> This doesn't throw either of these exceptions AFAICT.

Fixed.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 86:
> 
>> 84:             if (namedGroup.spec != NamedGroupSpec.NAMED_GROUP_KEM) {
>> 85:                 throw new RuntimeException(
>> 86:                         "Credentials decoding:  Not KEM named group");
> 
> Nit: only one space after ":".

Removed the extra space.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 97:
> 
>> 95:     }
>> 96: 
>> 97:     static class KEMPossession implements SSLPossession {
> 
> Looks like this can be private.

Fixed.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 98:
> 
>> 96: 
>> 97:     static class KEMPossession implements SSLPossession {
>> 98:         private final NamedGroup namedGroup;
> 
> Nit, add empty lines between variable declarations and method names.

Added.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 128:
> 
>> 126:             } catch (GeneralSecurityException e) {
>> 127:                 throw new RuntimeException(
>> 128:                         "Could not generate XDH keypair", e);
> 
> XDH? Should this be `algName`?

Yes, fixed.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 142:
> 
>> 140:         }
>> 141: 
>> 142:         public PublicKey getPublicKey() {
> 
> This can be package-private, also `getPrivateKey`.

Done.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 153:
> 
>> 151:     static final class KEMSenderPossession extends KEMPossession {
>> 152: 
>> 153:         public SecretKey getKey() {
> 
> This method can be package-private, also `setKey`.

Fixed.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 161:
> 
>> 159:         }
>> 160: 
>> 161:         private SecretKey key;
> 
> Not - move this declaration to before `getKey`.

Done.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 163:
> 
>> 161:         private SecretKey key;
>> 162: 
>> 163:         KEMSenderPossession(NamedGroup namedGroup) {
> 
> Move this ctor up to before the methods.

Done.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 200:
> 
>> 198:             }
>> 199:             context.conContext.fatal(Alert.HANDSHAKE_FAILURE,
>> 200:                     "No sufficient XDHE key agreement "
> 
> Is this always XDHE?

No, fixed.

> src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 599:
> 
>> 597:                                 xp.setKey(encaped.key());
>> 598:                                 keyShare = new KeyShareEntry(ng.id,
>> 599:                                         encaped.encapsulation());
> 
> Should there be a break after this line?

No, we have a break at line #606 for this.

> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 317:
> 
>> 315:                 // Skip AlgorithmParameters for KEMs (not supported)
>> 316:                 if (namedGroupSpec == NamedGroupSpec.NAMED_GROUP_KEM) {
>> 317:                     Provider p = getProvider();
> 
> Nit: you can just use `defaultProvider`, no need to call `getProvider()` or define another variable.

Removed the call.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 60:
> 
>> 58:         @Override
>> 59:         public String getAlgorithm() {
>> 60:             return "Hybrid";
> 
> Should we just return "Generic" here to align with the KEM spec?

Yes, fixed.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 430:
> 
>> 428:         @Override
>> 429:         public byte[] getEncoded() {
>> 430:             return new byte[0];
> 
> Should return `null` instead (according to `Key.getEncoded` spec).

Fixed.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 444:
> 
>> 442:     }
>> 443: 
>> 444:     public static final NamedParameterSpec X25519_MLKEM768 =
> 
> Move these constants to the top of the class so they are more prominent.

Done.

> test/jdk/javax/net/ssl/TLSv13/HRRKeyShares.java line 1:
> 
>> 1: /*
> 
> Is the comment on line 352-353 accurate?:
> 
> 
> // Now we're expecting to reissue the ClientHello, this time
> // with a secp384r1 share.
> 
> Shouldn't this be whatever the hrrNamedGroup parameter passed in is?

Fixed the comment.

> test/jdk/sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java line 84:
> 
>> 82:     };
>> 83: 
>> 84:     private static final String[] HYBRID_NAMEDGROUPS = {
> 
> Somewhat of a nit, but you only access this as a `List` in the code below, so it would be better to just use `List.of` here. In fact, these 3 arrays could all be lists and initialized with `List.of`.

Done as suggested.

> test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java line 51:
> 
>> 49: 
>> 50:     private static volatile int index;
>> 51:     private static final String[][][] protocolForClassic = {
> 
> Nit: suggest naming this `protocolsForClassic`.

Done.

> test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java line 58:
> 
>> 56:     };
>> 57: 
>> 58:     private static final String[][][] protocolForHybrid = {
> 
> Nit: suggest naming this `protocolsForHybrid`.

Done.

> test/micro/org/openjdk/bench/javax/crypto/full/KeyPairGeneratorBench.java line 59:
> 
>> 57:         try {
>> 58:             Class<?> dhClazz = Class.forName("com.sun.crypto.provider.DH");
>> 59:             return (Provider) (dhClazz.getField("PROVIDER").get(null));
> 
> Nit: don't think you need the parens around `dhClazz.getField("PROVIDER").get(null)`

Removed parens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584270431
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584271259
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584271412
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584267054
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584267257
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584267463
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584267949
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584268196
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584267671
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584268630
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584268449
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584269726
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584269450
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584268879
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584269098
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584269260
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584269932
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584270154
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584266540
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584271070
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584270863
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584270663
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584261901
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584264922
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584264409
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584264641
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584264204

From hchao at openjdk.org  Wed Dec  3 09:21:21 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 09:21:21 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <hQGeRqaqA6UlG-iKFwrTX6vecKUzTXxVDBGs8CBazCI=.52986351-e8e3-4dab-a8cd-008e54b2a640@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <Y7azUkWEoruKxpinhEeiOQ8MH8u9Dz-AyCy_JvgbwkI=.49efad6e-1d35-4721-b5dc-d73ff240dc1d@github.com>
 <hQGeRqaqA6UlG-iKFwrTX6vecKUzTXxVDBGs8CBazCI=.52986351-e8e3-4dab-a8cd-008e54b2a640@github.com>
Message-ID: <8LPU1goS2AFVEZ26_gl64bN4AxAP6JJFuAqe73wLka4=.3f76e105-f7e9-45af-9af2-0fcc33d0c4c7@github.com>

On Mon, 1 Dec 2025 21:51:43 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 28:
>> 
>>> 26: 
>>> 27: import java.io.IOException;
>>> 28: import java.security.*;
>> 
>> Probably clearer not to use wildcard imports so we can see all the classes needed, same comment on line 32.
>
> I vaguely remember somewhere the guidance that if there are <= 5 imports, you should list them, otherwise use the wildcard.

Added the imports. (There are more than 5 though).

>> test/jdk/javax/net/ssl/TLSv13/HRRKeyShares.java line 33:
>> 
>>> 31:  * @summary Use two key share entries
>>> 32:  * @library /test/lib
>>> 33:  * @run main/othervm -Djdk.tls.namedGroups=x25519,secp256r1,secp384r1,X25519MLKEM768,SecP256r1MLKEM768,SecP384r1MLKEM1024 HRRKeyShares
>> 
>> Long line, break up into multiple lines.
>
> I noted quite a few <= 80 comments throughout, so fully agree here!  ;)

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584266809
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584261252

From hchao at openjdk.org  Wed Dec  3 09:21:23 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 09:21:23 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <BBbMfCNh0fDcGte1B4veDc7NkgKzMJQBzq7lrA-9xPk=.c3a9719d-ff50-4e5a-afd4-83bd8a1ebd0c@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <BBbMfCNh0fDcGte1B4veDc7NkgKzMJQBzq7lrA-9xPk=.c3a9719d-ff50-4e5a-afd4-83bd8a1ebd0c@github.com>
Message-ID: <p7WKXATeKsqFUWJzSysplILVkPj1XALEtvOBmrLF44g=.e77df08a-b4e0-4d90-a334-bb6b0a4cefd9@github.com>

On Mon, 24 Nov 2025 18:10:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - Change default named group list to have only X25519MLKEM768
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 232:
> 
>> 230:             NamedGroupSpec.NAMED_GROUP_KEM,
>> 231:             ProtocolVersion.PROTOCOLS_OF_13,
>> 232:             null),
> 
> I know the 3 named groups above are not used yet, but the `name` field will be used in the constructor by `KeyFactory.getInstance(name)`. Since "MLKEM1024" is not a standard algorithm name, the call would failed with a NSAE.

The `AlgorithmParameterSpec` for these 3 named groups registry are set to null. In the constructor, the `mediator` will be false for them so that `KeyFactory.getInstance(name)` will not be called to fail with a NSAE. Will do some translation when we support post-quantum ML-KEM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584260461

From hchao at openjdk.org  Wed Dec  3 09:21:27 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 09:21:27 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <oj-SWVUbNrBxXHpXX27-e3krwgG9xCEvivzCxH9r9hw=.334fa53f-9361-4758-bc37-214aa9a0be3e@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <oj-SWVUbNrBxXHpXX27-e3krwgG9xCEvivzCxH9r9hw=.334fa53f-9361-4758-bc37-214aa9a0be3e@github.com>
Message-ID: <0bxgkNU5BVF5AQAbjEB0XDV6ckc1Wv4W5yQyEakRjQQ=.0eaa375c-d7cd-4e24-9612-4564dcd34c70@github.com>

On Thu, 30 Oct 2025 19:28:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
>
> test/jdk/sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java line 200:
> 
>> 198:     }
>> 199: 
>> 200:     private static boolean groupSupportdByCipher(String group,
> 
> Fix this typo in the method name while you are in here: s/groupSupportdByCipher/groupSupportedByCipher/

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2584260759

From jpai at openjdk.org  Wed Dec  3 09:31:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Dec 2025 09:31:43 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <YjudxhBPug-ddmXbEvXNBAUfc9dE6085Qr6-xpbJW7s=.78ece7a7-31fe-45b8-b443-2caad8f5c036@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <YjudxhBPug-ddmXbEvXNBAUfc9dE6085Qr6-xpbJW7s=.78ece7a7-31fe-45b8-b443-2caad8f5c036@github.com>
Message-ID: <o44xzOp5DB93QQvmgMPpIgETAGnXYPniBsQ-peXzifM=.63037eec-2b59-4113-9928-dea3f33a4049@github.com>

On Wed, 3 Dec 2025 08:41:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Jai may be able to say more on the motivation for JDK-8370688. Maybe a concern with code uses identity to check equality, or maybe the concern was that the caller could modify the JarEntry's certs/signers by modifying the array?

What prompted me to file JDK-8370688 is that there's an internal class in the JDK (URLJarFileEntry) which extends `JarEntry` and overrides `getCodeSigners()` and `getCertificates()` to merely clone the returned array. With the way these 2 methods are implemented in `JarEntry`, the returned array is already cloned. So `URLJarFileEntry.getCodeSigners()/getCertificates()` ends up cloning that array twice.

The intention of the JBS issue was to have JarEntry specify this current implementation, so that these sub classes of JarEntry can then rely on that specification and don't have to do the clone() themselves. The current proposed text in this PR, I think, needs to be more precise. The way it's worded currently doesn't allow for applications (or JDK internal classes) to rely on the returned array being a copy of the underlying one. As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance).

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3605890862

From jpai at openjdk.org  Wed Dec  3 09:46:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Dec 2025 09:46:07 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <o44xzOp5DB93QQvmgMPpIgETAGnXYPniBsQ-peXzifM=.63037eec-2b59-4113-9928-dea3f33a4049@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <YjudxhBPug-ddmXbEvXNBAUfc9dE6085Qr6-xpbJW7s=.78ece7a7-31fe-45b8-b443-2caad8f5c036@github.com>
 <o44xzOp5DB93QQvmgMPpIgETAGnXYPniBsQ-peXzifM=.63037eec-2b59-4113-9928-dea3f33a4049@github.com>
Message-ID: <sBg82xTODrYBbDl6ytLBGdy1JHnZt4tfIS9QNxJWVK8=.971d4c77-598a-4598-8c86-1efd37293426@github.com>

On Wed, 3 Dec 2025 09:28:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance).

`javax.net.ssl.SSLParameters` has a few APIs which word this in a couple of different ways:

https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getCipherSuites()

Returns:
    a copy of the array of ciphersuites or null if none have been set.


https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getApplicationProtocols()

This method will return a new array each time it is invoked.

I prefer the "a copy of the array of ..." style, but I'll let Sean and others decide how to word this.

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3605950544

From alanb at openjdk.org  Wed Dec  3 10:38:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Dec 2025 10:38:25 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <sBg82xTODrYBbDl6ytLBGdy1JHnZt4tfIS9QNxJWVK8=.971d4c77-598a-4598-8c86-1efd37293426@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <YjudxhBPug-ddmXbEvXNBAUfc9dE6085Qr6-xpbJW7s=.78ece7a7-31fe-45b8-b443-2caad8f5c036@github.com>
 <o44xzOp5DB93QQvmgMPpIgETAGnXYPniBsQ-peXzifM=.63037eec-2b59-4113-9928-dea3f33a4049@github.com>
 <sBg82xTODrYBbDl6ytLBGdy1JHnZt4tfIS9QNxJWVK8=.971d4c77-598a-4598-8c86-1efd37293426@github.com>
Message-ID: <QDKkqniRipBqi_YqrqgnCQ1iF9sRfYpGsVb4m_7uZU4=.219fb01e-84a7-4d69-8a9f-f839d64342f8@github.com>

On Wed, 3 Dec 2025 09:43:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance).
> 
> `javax.net.ssl.SSLParameters` has a few APIs which word this in a couple of different ways:
> 
> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getCipherSuites()
> 
> ```
> Returns:
>     a copy of the array of ciphersuites or null if none have been set.
> ```
A SSLParameters is optionally created with array of cipher suites so it works there. A JarEntry is not created with an array so I don't think this wording make sense.


> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getApplicationProtocols()
> 
> ```
> This method will return a new array each time it is invoked.
> ```

That could work for JarEntry although debatable if we really need this.

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3606176594

From coffeys at openjdk.org  Wed Dec  3 12:50:18 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 3 Dec 2025 12:50:18 GMT
Subject: RFR: 8371333: Optimize static initialization of SSLContextImpl
 classes and improve logging [v2]
In-Reply-To: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
References: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
Message-ID: <tLNwD3_32dXG1mMxZ2YDRJxu5MvioNh6AC1JWG71VcA=.ff2fa456-a422-427a-8797-61a8e33cbafe@github.com>

> Introduce lazy static initialization logic to SSLContextImpl via use of the new LazyConstant API and improve logging output
> 
> As per JBS comments:
> 
> * Each subclass of AbstractTLSContext (TLSv10. TLSv11 etc) is being initialization at framework initialization time due to the getApplicableSupportedCipherSuites(..) calls made in static block. Such calls are unnecessary if the subclass isn't required. This is especially true for the default JDK configuration where TLSv10, TLSv11 protocols are disabled. I've moved logic to lazy initialization of these fields via LazyConstant
> 
> * The debug prints output never made clear what protocol version each cipher suite was being disabled for. Improved logging there
> * The debug prints never printed out the resulting set of enabled/allowed cipher suites
> 
> There's efficiency gain also in having one less call to the getApplicableEnabledCipherSuites method in the scenario where customized cipher suites are not in use.
> 
> example of new debug output:
> 
> 
> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Ignore disabled cipher suites for protocols:[TLSv1.3, TLSv1.2]
> [TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384
> TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA
> TLS_RSA_WITH_AES_128_CBC_SHA]
> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997 GMT|SSLContextImpl.java:425|Available cipher suites for protocols:[TLSv1.3, TLSv1.2]
> [TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDHE_E...

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 four additional commits since the last revision:

 - Move wrapText method to Utilities
 - Merge branch 'master' into 8371333-ssl-debug
 - use LINE_SEP
 - 8371333

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28511/files
  - new: https://git.openjdk.org/jdk/pull/28511/files/2cba0874..e51e95f5

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

  Stats: 28280 lines in 680 files changed: 16210 ins; 8267 del; 3803 mod
  Patch: https://git.openjdk.org/jdk/pull/28511.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28511/head:pull/28511

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

From coffeys at openjdk.org  Wed Dec  3 12:50:21 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 3 Dec 2025 12:50:21 GMT
Subject: RFR: 8371333: Optimize static initialization of SSLContextImpl
 classes and improve logging [v2]
In-Reply-To: <_xEaVhmdqZiKJc5sZ1Qw65TqNC_yxwGHUdls2YJaWYE=.db4a37cd-9900-4fab-b4f7-b9bb20dc2c8e@github.com>
References: <TZF1SzuB8Pps8O10qrKtOXRrGWWyiGxSFqfZVjvUj0I=.4de2e8f8-bc38-49c7-96bc-8205118c7fc7@github.com>
 <_xEaVhmdqZiKJc5sZ1Qw65TqNC_yxwGHUdls2YJaWYE=.db4a37cd-9900-4fab-b4f7-b9bb20dc2c8e@github.com>
Message-ID: <F3EotDaf7aK_ivoWgcYrsS1AVMq30UWSLpqLPKnEg4w=.745e2e13-a714-4078-a062-bb0a82b4fad9@github.com>

On Wed, 26 Nov 2025 17:39:01 GMT, Jamil Nimeh <jnimeh 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 four additional commits since the last revision:
>> 
>>  - Move wrapText method to Utilities
>>  - Merge branch 'master' into 8371333-ssl-debug
>>  - use LINE_SEP
>>  - 8371333
>
> src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 515:
> 
>> 513:     }
>> 514: 
>> 515:     public static String wrapText(String text, int maxWidth) {
> 
> This seems like it might be useful outside of `SSLContext`.  Do you think it could be part of `SSLLogger` rather than here?  Given that it's static and visible it can stay where it is, but if other classes within SunJSSE could benefit from it it feels more natural to belong to the logger class.

Thanks for the suggestion. I see the Utilities class in same directory has a bunch of helper methods. I've moved the wrapText method in there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28511#discussion_r2584972382

From mullan at openjdk.org  Wed Dec  3 14:00:48 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 3 Dec 2025 14:00:48 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <QDKkqniRipBqi_YqrqgnCQ1iF9sRfYpGsVb4m_7uZU4=.219fb01e-84a7-4d69-8a9f-f839d64342f8@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <YjudxhBPug-ddmXbEvXNBAUfc9dE6085Qr6-xpbJW7s=.78ece7a7-31fe-45b8-b443-2caad8f5c036@github.com>
 <o44xzOp5DB93QQvmgMPpIgETAGnXYPniBsQ-peXzifM=.63037eec-2b59-4113-9928-dea3f33a4049@github.com>
 <sBg82xTODrYBbDl6ytLBGdy1JHnZt4tfIS9QNxJWVK8=.971d4c77-598a-4598-8c86-1efd37293426@github.com>
 <QDKkqniRipBqi_YqrqgnCQ1iF9sRfYpGsVb4m_7uZU4=.219fb01e-84a7-4d69-8a9f-f839d64342f8@github.com>
Message-ID: <rVqlO4qPvi4SEhWexqyxat0xXVYWKy1sa9Hy5rxjIbA=.24d65206-c2df-47de-adb7-5c9ebe7b4b49@github.com>

On Wed, 3 Dec 2025 10:35:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance).
> > 
> > 
> > `javax.net.ssl.SSLParameters` has a few APIs which word this in a couple of different ways:
> > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getCipherSuites()
> > ```
> > Returns:
> >     a copy of the array of ciphersuites or null if none have been set.
> > ```
> 
> A SSLParameters is optionally created with array of cipher suites so it works there. A JarEntry is not created with an array so I don't think this wording make sense.
> 
> > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getApplicationProtocols()
> > ```
> > This method will return a new array each time it is invoked.
> > ```
> 
> That could work for JarEntry although debatable if we really need this.

The second one looks good to me. This will need a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3606998031

From mullan at openjdk.org  Wed Dec  3 14:00:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 3 Dec 2025 14:00:47 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <YjudxhBPug-ddmXbEvXNBAUfc9dE6085Qr6-xpbJW7s=.78ece7a7-31fe-45b8-b443-2caad8f5c036@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <YjudxhBPug-ddmXbEvXNBAUfc9dE6085Qr6-xpbJW7s=.78ece7a7-31fe-45b8-b443-2caad8f5c036@github.com>
Message-ID: <D4H9EMq-_GtsmVobxOARlpTB_c4AkQ42CACBqYa_NsI=.d4af4f7d-beca-4b2e-bd37-17933207a8e3@github.com>

On Wed, 3 Dec 2025 08:41:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are a lot of APIs that return an array. Some of them use an array internally and so need to make a defensive copy/clone to return. Jai may be able to say more on the motivation for JDK-8370688. Maybe a concern with code uses identity to check equality, or maybe the concern was that the caller could modify the JarEntry's certs/signers by modifying the array?
> 
> I don't think the proposed change addresses either concern. We could potentially change the `@return` description to say that it returns a new array, which makes it a testable assertion. There are many other methods that return arrays, including other methods that return arrays of certs and code signers so we might want to change these at the same time.

I agree. The original commit was more aligned with what should be done. For security related information like arrays of certificates, I think the caller often needs to know one way or the other whether mutating the returned value affects the original object's contents. And I think in general, `JarEntry` should be returning a new array each time these methods are called. We can at least ensure that the JDK implementation follows the specification.

> @seanjmullan @wangweij Do you know if there has been any discussion about deprecating getCertificates? Developers have been re-directed to use getCodeSigners since JDK 5.

Not specifically, although I agree that it probably should be deprecated.

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3606987622

From myankelevich at openjdk.org  Wed Dec  3 14:08:37 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 3 Dec 2025 14:08:37 GMT
Subject: RFR: 8373016: Passes instead of skips/ignoring the platform in
 sun/security/mscapi, jarsigner, keytool and pkcs12 tests
Message-ID: <q2cc79w1ZCKBY0ptE05vXLHuwQnAmJAXtMn3_x13ONU=.6cecf1b5-dd34-42a6-b799-4ff6cfbe86a1@github.com>

Passes when shouldn't in these tests:
* test/jdk/sun/security/mscapi/IsSunMSCAPIAvailable.java
* test/jdk/sun/security/mscapi/SignUsingSHA2withRSA.java
* test/jdk/sun/security/mscapi/SignUsingNONEwithRSA.java
* test/jdk/sun/security/mscapi/RSAEncryptDecrypt.java
* test/jdk/sun/security/tools/jarsigner/CertChainUnclosed.java
* test/jdk/sun/security/tools/keytool/StorePasswords.java
* test/jdk/sun/security/pkcs12/StoreSecretKeyTest.java

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

Commit messages:
 - JDK-8373016: Passes instead of skips/ignoring the platform in sun/security/mscapi, jarsigner, keytool and pkcs12 tests

Changes: https://git.openjdk.org/jdk/pull/28635/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373016
  Stats: 106 lines in 8 files changed: 58 ins; 13 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/28635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28635/head:pull/28635

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

From fferrari at openjdk.org  Wed Dec  3 14:43:01 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 3 Dec 2025 14:43:01 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v11]
In-Reply-To: <MuneGXU38xLu_noqZ0ZEAM_bmKaxnT3JHz39gezAh38=.833dec6d-f368-45f3-af58-fb0a4871bc39@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <f1LGOwCPsznfyr2PPV8WapM4335Th4oEs4kR_lT8bBM=.50f62482-94c8-490a-9e02-20c3d2958ea0@github.com>
 <tXOYQ_nde9pAdy2Gn_DhUzmLm9Lu02sf-mGI87I819Q=.758751d0-3684-4fdf-be8b-222ee93e13e3@github.com>
 <_HUUN67SsUDKiW4mhpPssp7bTD-BIiz0Ho1qyltjYeY=.afae4482-6158-4e73-aee1-351d1251d759@github.com>
 <5D1Yihd-yhpCmCh7b-8GGc3OjFmBFumOwj3GnceIDpU=.61c6f036-4797-4902-8f54-90cdc6a822b5@github.com>
 <MuneGXU38xLu_noqZ0ZEAM_bmKaxnT3JHz39gezAh38=.833dec6d-f368-45f3-af58-fb0a4871bc39@github.com>
Message-ID: <LQ-i43GnEbWgNbd01atLEcFn9NH_wO6OI9KqQR71yUI=.3f08a02a-b82a-422a-b333-e61d57aabbe0@github.com>

On Tue, 2 Dec 2025 21:09:59 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>>> Hi folks, as we know [JDK 26 enters Rampdown Phase One next week](https://mail.openjdk.org/pipermail/jdk-dev/2025-November/010639.html) on Thursday, 4 December.
>>> 
>>> Please let me know if we'll want this fix to move forward before that happens, and please note that soon I will need to focus on the OJVG work.
>> 
>> This is a P3 bug and a regression, so it can be fixed after RDP1 and before RDP2. I have asked other members of our team to review this fix as I am busy with other work. Given that RDP1 is only a couple of days away and these additional reviews and changes are still ongoing, I don't think we can guarantee this will be integrated before RDP1, but hopefully you will have time after that to continue to address feedback, if needed.
>
>> This is a P3 bug and a regression, so it can be fixed after RDP1 and before RDP2. I have asked other members of our team to review this fix as I am busy with other work. Given that RDP1 is only a couple of days away and these additional reviews and changes are still ongoing, I don't think we can guarantee this will be integrated before RDP1, but hopefully you will have time after that to continue to address feedback, if needed.
> 
> @seanjmullan: ok, thank you for the time you've invested in this!

> @franferrax I think it would be useful to update the PR description now that the fix is different than what was originally proposed.

@seanjmullan: done.

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3607188719

From weijun at openjdk.org  Wed Dec  3 15:44:26 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 3 Dec 2025 15:44:26 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
Message-ID: <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>

On Wed, 3 Dec 2025 01:48:00 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this is a proposal to fix [JDK-8352728](https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions").
>> 
>> Path resolution with `Path::toRealPath` fails under the following conditions:
>> 
>> * When there is a restricted [_ACL_](https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) in a parent directory (_Windows_)
>> * When dealing with an anonymous file only accesible through the _procfs_, such as `/proc/<pid>/fd/<fd>` (_Linux_)
>>     * Such a file can be created by a pipe, deleting an opened file, or with the [`memfd_create` _Linux_ API](https://man7.org/linux/man-pages/man2/memfd_create.2.html)
>> 
>> Original code from [JDK-8319332: Security properties files inclusion](https://bugs.openjdk.org/browse/JDK-8319332) unconditionally resolves with `Path::toRealPath` all the processed properties files. This PR avoids resolving the paths unless strictly necessary: when determining the base path to compute a relative `include` directive. Cyclic includes detection is now performed with the unresolved paths and `Files::isSameFile`, so `activePaths` no longer needs to be a `Set`.
>> 
>> #### Still unsupported use-case
>> 
>> In _Linux_, a relative `include` from an anonymous file referenced as `/proc/<pid>/fd/<fd>` makes little sense.
>> 
>> However, in _Windows_, a relative `include` from a file where any of the parent directories has a restricted _ACL_ will be expected to work. It's important to note that such a restricted directory permissions scenario occurs to every [_UWP_](https://learn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) app (see [JDK-8369741](https://bugs.openjdk.org/browse/JDK-8369741 "cannot use java.security inside of UWP apps")).
>> 
>> When computing a relative `include`, we perform symlinks resolution of the parent file under the rationale that the person writing the original properties file is the one who decides where the relative includes should resolve. In the absence of a recommended way or API to deal with resolution under this restricted directory permissions scenario, this use-case is left unsupported. This compromise-solution is better than the current status of _UWP_ apps, where simply loading the `java.security.Security` class breaks the JVM initialization by a failed attempt to resolve the `java.security` path (not from an `include` statement, nor a relative path).
>> 
>> <details>
>> <summary>Previous approach and...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Convert ConfigFileTestAnonymousPipes to Java
>  - Review suggestion: go back tolerating IOException
>    
>    We agreed an IOException in this case is recoverable, and decided to
>    tolerate it, while adding a debug log message with the exception.
>  - Review suggestion: improve comment clarity

src/java.base/share/classes/java/security/Security.java line 260:

> 258:                     // under the rationale that the person writing the
> 259:                     // original properties file is the one who decides
> 260:                     // where the relative includes should resolve.

The person writing the original properties file may have expected includes to resolve relative to its own location, but whoever created the symlink may have intended a different resolution path. If they wanted the original location, they could have just used the real file directly instead of introducing a symlink.

For a comparison, I tried `jextract` on a C header that includes another header, the included file was resolved based on the header?s named path, not its real path.

I know you might have a backward compatibility concern here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2585623241

From schernyshev at openjdk.org  Wed Dec  3 15:44:25 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 3 Dec 2025 15:44:25 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
 <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>
Message-ID: <nDLXxbhBvgcWPG1viDVOrmzRoUDrQZE5uiZ5o_8tKMg=.eb1f168a-4e97-4c3f-8a5d-d872cc0fb044@github.com>

On Wed, 3 Dec 2025 08:44:05 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test that ipv4 literals do not propagate to the server names list
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 136:
> 
>> 134:          */
>> 135:         conn.setSSLSocketFactory(wrapSocketFactory(sf,
>> 136:                 sslSocket -> clientSSLSocket = sslSocket));
> 
> Shall we first assert that `clientSSLSocket == null` before assignment?

The method `doClientSide()` is called from constructor, the `clientSSLSocket` is non-static and was set to `null`. Therefore, it's the only assignment of clientSSLSocket per instance. Or do you mean the check must be in the the lambda-expr?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2585626177

From Martijn.de.Haar at topicus.nl  Mon Dec  1 09:53:25 2025
From: Martijn.de.Haar at topicus.nl (Martijn de Haar)
Date: Mon, 1 Dec 2025 09:53:25 +0000
Subject: =?Windows-1252?Q?Request_to_include_=93HARICA_TLS_RSA_Root_CA_2021=94_and?=
 =?Windows-1252?Q?_=93HARICA_TLS_ECC_Root_CA_2021=94_in_OpenJDK_cacerts?=
Message-ID: <GV1P192MB27809284C7A452A6444A812BCDDBA@GV1P192MB2780.EURP192.PROD.OUTLOOK.COM>

Dear OpenJDK Security Team,

I would like to request the inclusion of the following HARICA root certificates in the default OpenJDK cacerts truststore:

  *   HARICA TLS RSA Root CA 2021

  *   HARICA TLS ECC Root CA 2021

These roots are part of HARICA?s 2021 TLS Root hierarchy and are already included in all major trust programs (Apple, Microsoft, Mozilla, Google, Oracle) and in modern operating system trust stores. However, they do not appear to be present in the current OpenJDK cacerts file, while the older HARICA 2015 roots are included (added under JDK-8260597).

This absence causes Java applications to fail TLS validation when connecting to services that use certificates issued under the 2021 HARICA hierarchy.

Thank you for your time and consideration.

Kind regards,

Martijn de Haar



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251201/21d5c0b6/attachment.htm>

From duke at openjdk.org  Wed Dec  3 18:46:40 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 3 Dec 2025 18:46:40 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v2]
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <s_EXrv484Os8Le2KqxofBSc-KNZsAfBrnj5XO2IyDpw=.15347558-ee5c-468e-92e7-e3c2ec2bc834@github.com>

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8370688: Addressed review comments - add explicit note similar to SSLParameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28615/files
  - new: https://git.openjdk.org/jdk/pull/28615/files/c9c87bfa..59abe38b

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

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

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

From vyazici at openjdk.org  Wed Dec  3 19:56:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 3 Dec 2025 19:56:09 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <nDLXxbhBvgcWPG1viDVOrmzRoUDrQZE5uiZ5o_8tKMg=.eb1f168a-4e97-4c3f-8a5d-d872cc0fb044@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
 <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>
 <nDLXxbhBvgcWPG1viDVOrmzRoUDrQZE5uiZ5o_8tKMg=.eb1f168a-4e97-4c3f-8a5d-d872cc0fb044@github.com>
Message-ID: <YAPM5blxlyplQB-Fvc3zyL7X7vBi9VFvMxX74RQxJgc=.429028e6-ba15-4408-a555-a1d292c300fb@github.com>

On Wed, 3 Dec 2025 15:41:58 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 136:
>> 
>>> 134:          */
>>> 135:         conn.setSSLSocketFactory(wrapSocketFactory(sf,
>>> 136:                 sslSocket -> clientSSLSocket = sslSocket));
>> 
>> Shall we first assert that `clientSSLSocket == null` before assignment?
>
> The method `doClientSide()` is called from constructor, the `clientSSLSocket` is non-static and was set to `null`. Therefore, it's the only assignment of clientSSLSocket per instance. Or do you mean the check must be in the the lambda-expr?

I mean something like:

Suggestion:

                sslSocket -> {
                    assertNull(clientSSLSocket);
                    clientSSLSocket = sslSocket;
                }));


To avoid double-assignment and eventually causing verification of the wrong value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2586419546

From hchao at openjdk.org  Wed Dec  3 21:11:03 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 21:11:03 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <7zrw8Ap-KrTjfZnWSsVdSoEull2pnavxROnJthCoEbU=.7f07d25f-6d80-4088-857d-8954fd2ea4d8@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <osmzSDvG9ftU7Ha53P0VNZIl29cH0YN3O8ToCsNd-0g=.3159d9c7-6505-416e-8ba6-39661ec7b942@github.com>
 <7zrw8Ap-KrTjfZnWSsVdSoEull2pnavxROnJthCoEbU=.7f07d25f-6d80-4088-857d-8954fd2ea4d8@github.com>
Message-ID: <k8RKUNVW0rb6zLGrBIM3AePKaXUTO1RBZvGbFeOSoDA=.8415b30e-69fb-4d70-bfcc-9870e77a75ae@github.com>

On Thu, 9 Oct 2025 11:46:29 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> Can you add these new groups to `test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java`?

Added.

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

PR Comment: https://git.openjdk.org/jdk/pull/27614#issuecomment-3608846285

From hchao at openjdk.org  Wed Dec  3 21:11:05 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 21:11:05 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v10]
In-Reply-To: <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
Message-ID: <9kxNkGHge8jZeLA8Vk9mPs2h47lkon4FNGbnDCEpmbw=.381415c4-b904-4fb6-b317-d40503cdfc0f@github.com>

On Fri, 3 Oct 2025 17:26:01 GMT, Bernd <duke at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Updates with Brad's and Sean's comments
>>  - Move Hybrid.java to sun.security.ssl
>>  - Move DH.java to sun.security.ssl as DHasKEM.java
>
> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 230:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Isn?t that Part formte named groups, maybe Look it up instead?

The working code is fine as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2586612805

From hchao at openjdk.org  Wed Dec  3 21:18:40 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 3 Dec 2025 21:18:40 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <KYSSrxBVjnA9ywOOdnqarc5IgOjSlQAQHZtQXKH_LOE=.572f68d0-04fd-4fed-b14e-61646e366c5e@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <Xn5fgBEoZezVWRO8PVXWfyLXMowqEa3dlmoY8czBPD0=.2e8b93c8-7f49-4791-822f-cb61989f3292@github.com>
 <_lllGSzlmS7Y5J-s3SwxculXHsm87QZkbA1-j-H-eg0=.853eb2eb-6594-48b2-8626-112066af3137@github.com>
 <KYSSrxBVjnA9ywOOdnqarc5IgOjSlQAQHZtQXKH_LOE=.572f68d0-04fd-4fed-b14e-61646e366c5e@github.com>
Message-ID: <CspmD0Tv0HjG26iyr1TH0bH6h6bgNlDjJmcf3uVSAIA=.6ded9b73-0f56-4ad0-8411-398ed4d205fd@github.com>

On Wed, 26 Nov 2025 03:36:15 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> We introduce DH Provider that implements DH as a KEM, and DH is wrapped as a KEM for encapsulate and decapsulate. It is an internal translation layer, not a real new public algorithm, so it is not exposed to public.
>
> The `Provider` needs much more info here about what it's doing, and that this `Provider` doesn't actually get installed in the system's list of security providers that is searched at runtime.
> 
> This is strictly an internal provider used in the JSSE code.

Comments added for the `Provider` as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2586634107

From mdoerr at openjdk.org  Wed Dec  3 21:36:07 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 3 Dec 2025 21:36:07 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
Message-ID: <4EQdnKyb8EU5rJFsRY_oRX7o_GHQZ-aydifUJURpcqY=.e9696df6-12a6-40e4-bc8a-a26e46ab0c5c@github.com>

On Mon, 1 Dec 2025 17:54:21 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - Stop catching exception to make test able to fail
> - Remove java-only test variation that cannot fail
> - Reduce fuzz repeat count

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28584#pullrequestreview-3536994784

From vpaprotski at openjdk.org  Wed Dec  3 21:36:08 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 3 Dec 2025 21:36:08 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
Message-ID: <4Aewr7umEVP_PCEXHOfd9mIx7MVqBiyU2pxtQZBQV0M=.de6e3258-9054-4cf1-9289-0396871dc243@github.com>

On Mon, 1 Dec 2025 17:54:21 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - Stop catching exception to make test able to fail
> - Remove java-only test variation that cannot fail
> - Reduce fuzz repeat count

Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3608918930

From vpaprotski at openjdk.org  Wed Dec  3 21:36:09 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 3 Dec 2025 21:36:09 GMT
Subject: Integrated: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
Message-ID: <lKnJyjNrRfcoxjwTDGVaP6fAaNBfd-aThX7M4Cp4eqk=.873b0b7a-5390-4861-9666-b3b2849e0482@github.com>

On Mon, 1 Dec 2025 17:54:21 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - Stop catching exception to make test able to fail
> - Remove java-only test variation that cannot fail
> - Reduce fuzz repeat count

This pull request has now been integrated.

Changeset: 70e2bc87
Author:    Volodymyr Paprotski <vpaprotski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70e2bc876abe35b3d447f8004245bdbf2fead59f
Stats:     23 lines in 1 file changed: 1 ins; 12 del; 10 mod

8372816: New test sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of error

Reviewed-by: azeller, mdoerr

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

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

From mullan at openjdk.org  Wed Dec  3 22:20:25 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 3 Dec 2025 22:20:25 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <Xb9mk6G5X5ZXJ9n_H2oa00XkdKGf4E_ZZlN72IWaDz8=.edaebca0-0cbd-401d-b8b4-8cd3cc84a18a@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <ygDE87sA6c4qIkX65GviP1qfh42xjIQ3NBm_o2GFmLk=.791c1ed5-861b-4bfc-b025-3fc1ac3e0124@github.com>
 <Xb9mk6G5X5ZXJ9n_H2oa00XkdKGf4E_ZZlN72IWaDz8=.edaebca0-0cbd-401d-b8b4-8cd3cc84a18a@github.com>
Message-ID: <mLWA4LyCRIfu9SZ5Nts-MY_5ck86e_9VbHPrIfeSVvM=.821020c4-a3df-4f41-93b5-2d9ba706cdcf@github.com>

On Wed, 3 Dec 2025 09:16:48 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 599:
>> 
>>> 597:                                 xp.setKey(encaped.key());
>>> 598:                                 keyShare = new KeyShareEntry(ng.id,
>>> 599:                                         encaped.encapsulation());
>> 
>> Should there be a break after this line?
>
> No, we have a break at line #606 for this.

But at this point we have created a KeyShare, why continue further through the loop?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2586793081

From dholmes at openjdk.org  Wed Dec  3 23:59:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Dec 2025 23:59:11 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
Message-ID: <nRbdIojalU2u22iZCTHULVANMW7NKkW5WvWgFDaZZYE=.5a07673f-dd7a-48f9-b42b-b337994633f4@github.com>

On Mon, 1 Dec 2025 17:54:21 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - Stop catching exception to make test able to fail
> - Remove java-only test variation that cannot fail
> - Reduce fuzz repeat count

The test now fails in our CI

java.lang.RuntimeException: [Seed 3895491853102776133 at 5549] Result mult mismatch: fff0061f00128d23ffdbb433001c7a8a002d562effc43fe4001f6377001f7065ffeb1455ffd22289000872f8ffd1e03b0030157bffe420330031c9eb000138f8ffd7853f00172cf5ffd4a6d900377fabffc130e30033c31700168743ffcd3857001e6944fffc92d5002222ebffc240c7ffecb8d20027be25002a6fc7fff2d430002d63d800041a8e00329bfbffff19a3ffdc90fa00331163fff5b3be002e64e2002d94abffed410efff5f1f1ffc6ca8affed5c89ffd7ade3002f76b7003710c9ffec3d900032c19000078e9900144b62ffdf8ac800278c730027710a0037938affe96fd500180a2100040ea60011e0890026771c0009dc3fffdb18d6001280320036ea6a002606c0fffc59a6ffdbf812003948d80011b321ffdc21570040b2f800318a49fff70942001d2d85fff3afb5ffed3e6800350ea7ffdeff9f0029322cfff3fe4e003e4092ffec13d5ffdb300bffea957dfff6d551ffd4d6b6ffcd6298000a0f13ffdbb59effec6d6effca3d90000281de00342dccffc2b23c00020a84000f7e5d00204e73ffd74e630027873effec166cffe10d2c000a7633fff69dd40013d48a0040d1fe002a0b12002d9142000d8a34003611260011c7d0ffd0542e0018d4fd0020e664fff6
 b857ffe28094ffcdf56d00265624ffd1959bffed104f003d4c1e003d6514ffcaba43fffb42dbffffaac7ffdcf21affde30c3ffc1403500284751fffbdac3fff852caffc457a6002f84a40016a7dc00346fd0002bcc660025a001002ca06cfffd7d7a0005836c00196d51ffc54cb90032202dffcff2d0ffc20746fff65d800011b965ffd69a78ffe3ead3000af25a001fd2b6002aed57fff525cf0023acb4ffdc4505fff4a991ffe7eaf5003d3e7a0016101b0005edefffdaa2280010e4470020388b00243769ffeabebb0026f2910032ea28002bbadb00311a08001bfd3dfff57759ffcd969cffd9f38a0036519cffe06383003acb950017b420002ea308ffe45730ffbe3676ffcddd09ffeb6c8d003de2f5001c67caffdda044ffe29b4e000e443fffc71b240011e37bfff78b1300003622ffedee67ffca12b4ffeb43a4001cb086ffc48e8500083e48ffc094d2003dd646003d545dfffd10ea00014d88001c8c1d0015a16800124736ffeeb98dffc47dd000332948000420a00042f554ffdac256ffd787b4fff3cdfd00145203ffea1843ffe0301e00149d65001a9f5a0033e519001cacb2000fd3a500265d8d001eff1e000d29ceffe899160004328c000dd45afff54bb7ffc97978ffe81823ffcf53e1fff233afffc8d6350005d44500232f700008f9e2fff42792fff5f01000169917f
 fd72777fff39350ffd7b655ffeb282d000f2bab001db15effe3b005ffcc2ff2fffb2a26003beed6fffa0d66ffcaa34e000ba76d001f4238ffcd1b0fffd5de94000b264d != fff0061f00128d23ffdbb433001c7a8affad762dffc43fe4001f6377001f7065ffeb1455ffd22289000872f8ffd1e03b0030157bffe420330031c9eb000138f8ffd7853f00172cf5ffd4a6d9ffb79faaffc130e30033c31700168743ffcd3857001e6944fffc92d5002222ebffc240c7ffecb8d20027be25002a6fc7fff2d430002d63d800041a8e00329bfbffff19a3ffdc90fa00331163fff5b3be002e64e2002d94abffed410efff5f1f10046aa8bffed5c89ffd7ade3ffaf96b6003710c9ffec3d900032c19000078e9900144b62ffdf8ac800278c730027710a0037938affe96fd500180a2100040ea60011e0890026771c0009dc3fffdb18d6001280320036ea6a002606c0fffc59a6ffdbf812003948d80011b321ffdc21570040b2f800318a49fff70942001d2d85fff3afb5ffed3e6800350ea7ffdeff9f0029322cfff3fe4e003e4092ffec13d5ffdb300bffea957dfff6d551ffd4d6b6ffcd6298000a0f13ffdbb59effec6d6effca3d90000281de00342dccffc2b23c00020a84000f7e5d00204e73ffd74e630027873effec166cffe10d2c000a7633fff69dd40013d48a0040d1fe002a0b1200
 2d9142000d8a34003611260011c7d0ffd0542e0018d4fd0020e664fff6b857ffe28094ffcdf56d002656240051759cffed104f003d4c1e003d6514ffcaba43fffb42dbffffaac7ffdcf21affde30c3ffc1403500284751fffbdac3fff852caffc457a6002f84a40016a7dc00346fd0002bcc660025a001002ca06cfffd7d7a0005836c00196d51ffc54cb90032202dffcff2d0ffc20746fff65d800011b965ffd69a78ffe3ead3000af25a001fd2b6002aed57fff525cf0023acb4ffdc4505fff4a991ffe7eaf5003d3e7a0016101b0005edefffdaa2280010e4470020388b00243769ffeabebb0026f2910032ea28002bbadb00311a08001bfd3dfff57759ffcd969cffd9f38a0036519cffe06383003acb950017b420002ea308ffe45730ffbe3676004dbd0affeb6c8d003de2f5001c67caffdda044ffe29b4e000e443fffc71b240011e37bfff78b1300003622ffedee670049f2b5ffeb43a4001cb086ffc48e8500083e48ffc094d2ffbdf645003d545dfffd10ea00014d88001c8c1d0015a16800124736ffeeb98dffc47dd000332948000420a00042f554ffdac256ffd787b4fff3cdfd00145203ffea1843ffe0301e00149d65001a9f5affb40518001cacb2000fd3a500265d8d001eff1e000d29ceffe899160004328c000dd45afff54bb7ffc97978ffe81823ffcf53e1fff233a
 fffc8d6350005d44500232f700008f9e2fff42792fff5f01000169917ffd72777fff39350ffd7b655ffeb282d000f2bab001db15effe3b005ffcc2ff2fffb2a26003beed6fffa0d66ffcaa34e000ba76d001f4238ffcd1b0fffd5de94000b264d
	at ML_DSA_Intrinsic_Test.testMult(ML_DSA_Intrinsic_Test.java:143)
	at ML_DSA_Intrinsic_Test.main(ML_DSA_Intrinsic_Test.java:120)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1516)

test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java line 51:

> 49: 
> 50: public class ML_DSA_Intrinsic_Test {
> 51:     public static void main(String[] args) throws Exception, Throwable {

FYI the `Exception` is redundant now you have added `Throwable`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3609317636
PR Review Comment: https://git.openjdk.org/jdk/pull/28584#discussion_r2586967168

From vpaprotski at openjdk.org  Wed Dec  3 23:59:11 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 3 Dec 2025 23:59:11 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <nRbdIojalU2u22iZCTHULVANMW7NKkW5WvWgFDaZZYE=.5a07673f-dd7a-48f9-b42b-b337994633f4@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <nRbdIojalU2u22iZCTHULVANMW7NKkW5WvWgFDaZZYE=.5a07673f-dd7a-48f9-b42b-b337994633f4@github.com>
Message-ID: <pKk5K-XNCzTBdp75uMDgaN81tvBQtRIoVCa3yom54UA=.8f4096cd-c5ee-4548-b2a7-c72c0b74b6f9@github.com>

On Wed, 3 Dec 2025 23:53:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> - Stop catching exception to make test able to fail
>> - Remove java-only test variation that cannot fail
>> - Reduce fuzz repeat count
>
> The test now fails in our CI
> 
> java.lang.RuntimeException: [Seed 3895491853102776133 at 5549] Result mult mismatch: fff0061f00128d23ffdbb433001c7a8a002d562effc43fe4001f6377001f7065ffeb1455ffd22289000872f8ffd1e03b0030157bffe420330031c9eb000138f8ffd7853f00172cf5ffd4a6d900377fabffc130e30033c31700168743ffcd3857001e6944fffc92d5002222ebffc240c7ffecb8d20027be25002a6fc7fff2d430002d63d800041a8e00329bfbffff19a3ffdc90fa00331163fff5b3be002e64e2002d94abffed410efff5f1f1ffc6ca8affed5c89ffd7ade3002f76b7003710c9ffec3d900032c19000078e9900144b62ffdf8ac800278c730027710a0037938affe96fd500180a2100040ea60011e0890026771c0009dc3fffdb18d6001280320036ea6a002606c0fffc59a6ffdbf812003948d80011b321ffdc21570040b2f800318a49fff70942001d2d85fff3afb5ffed3e6800350ea7ffdeff9f0029322cfff3fe4e003e4092ffec13d5ffdb300bffea957dfff6d551ffd4d6b6ffcd6298000a0f13ffdbb59effec6d6effca3d90000281de00342dccffc2b23c00020a84000f7e5d00204e73ffd74e630027873effec166cffe10d2c000a7633fff69dd40013d48a0040d1fe002a0b12002d9142000d8a34003611260011c7d0ffd0542e0018d4fd0020e664ff
 f6b857ffe28094ffcdf56d00265624ffd1959bffed104f003d4c1e003d6514ffcaba43fffb42dbffffaac7ffdcf21affde30c3ffc1403500284751fffbdac3fff852caffc457a6002f84a40016a7dc00346fd0002bcc660025a001002ca06cfffd7d7a0005836c00196d51ffc54cb90032202dffcff2d0ffc20746fff65d800011b965ffd69a78ffe3ead3000af25a001fd2b6002aed57fff525cf0023acb4ffdc4505fff4a991ffe7eaf5003d3e7a0016101b0005edefffdaa2280010e4470020388b00243769ffeabebb0026f2910032ea28002bbadb00311a08001bfd3dfff57759ffcd969cffd9f38a0036519cffe06383003acb950017b420002ea308ffe45730ffbe3676ffcddd09ffeb6c8d003de2f5001c67caffdda044ffe29b4e000e443fffc71b240011e37bfff78b1300003622ffedee67ffca12b4ffeb43a4001cb086ffc48e8500083e48ffc094d2003dd646003d545dfffd10ea00014d88001c8c1d0015a16800124736ffeeb98dffc47dd000332948000420a00042f554ffdac256ffd787b4fff3cdfd00145203ffea1843ffe0301e00149d65001a9f5a0033e519001cacb2000fd3a500265d8d001eff1e000d29ceffe899160004328c000dd45afff54bb7ffc97978ffe81823ffcf53e1fff233afffc8d6350005d44500232f700008f9e2fff42792fff5f0100016991
 7ffd72777fff39350ffd7b655ffeb282d000f2bab001db15effe3b005ffcc2ff2fffb2a26003beed6fffa0d66ffcaa34e000ba76d001f4238ffcd1b0fffd5de94000b264d != fff0061f00128d23ffdbb433001c7a8affad762dffc43fe4001f6377001f7065ffeb1455ffd22289000872f8ffd1e03b0030157bffe420330031c9eb000138f8ffd7853f00172cf5ffd4a6d9ffb79faaffc130e30033c31700168743ffcd3857001e6944fffc92d5002222ebffc240c7ffecb8d20027be25002a6fc7fff2d430002d63d800041a8e00329bfbffff19a3ffdc90fa00331163fff5b3be002e64e2002d94abffed410e...

@dholmes-ora aarch64? might have to disable the test for it for now.. if its on x86_64.. then I need to investigate..

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3609324920

From hchao at openjdk.org  Thu Dec  4 00:03:49 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 4 Dec 2025 00:03:49 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v11]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  Remove null check to not assume key is returned

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/00d49181..37a69689

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=09-10

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

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

From dholmes at openjdk.org  Thu Dec  4 00:14:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 00:14:14 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <pKk5K-XNCzTBdp75uMDgaN81tvBQtRIoVCa3yom54UA=.8f4096cd-c5ee-4548-b2a7-c72c0b74b6f9@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <nRbdIojalU2u22iZCTHULVANMW7NKkW5WvWgFDaZZYE=.5a07673f-dd7a-48f9-b42b-b337994633f4@github.com>
 <pKk5K-XNCzTBdp75uMDgaN81tvBQtRIoVCa3yom54UA=.8f4096cd-c5ee-4548-b2a7-c72c0b74b6f9@github.com>
Message-ID: <cL4a2iBxS5ORl5DkQkoxgiMkpeMcmNgeFpCrvZF0j5U=.52824906-298d-4b36-907a-95cc1936c4ef@github.com>

On Wed, 3 Dec 2025 23:56:26 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> The test now fails in our CI
>> 
>> java.lang.RuntimeException: [Seed 3895491853102776133 at 5549] Result mult mismatch: fff0061f00128d23ffdbb433001c7a8a002d562effc43fe4001f6377001f7065ffeb1455ffd22289000872f8ffd1e03b0030157bffe420330031c9eb000138f8ffd7853f00172cf5ffd4a6d900377fabffc130e30033c31700168743ffcd3857001e6944fffc92d5002222ebffc240c7ffecb8d20027be25002a6fc7fff2d430002d63d800041a8e00329bfbffff19a3ffdc90fa00331163fff5b3be002e64e2002d94abffed410efff5f1f1ffc6ca8affed5c89ffd7ade3002f76b7003710c9ffec3d900032c19000078e9900144b62ffdf8ac800278c730027710a0037938affe96fd500180a2100040ea60011e0890026771c0009dc3fffdb18d6001280320036ea6a002606c0fffc59a6ffdbf812003948d80011b321ffdc21570040b2f800318a49fff70942001d2d85fff3afb5ffed3e6800350ea7ffdeff9f0029322cfff3fe4e003e4092ffec13d5ffdb300bffea957dfff6d551ffd4d6b6ffcd6298000a0f13ffdbb59effec6d6effca3d90000281de00342dccffc2b23c00020a84000f7e5d00204e73ffd74e630027873effec166cffe10d2c000a7633fff69dd40013d48a0040d1fe002a0b12002d9142000d8a34003611260011c7d0ffd0542e0018d4fd0020e664f
 ff6b857ffe28094ffcdf56d00265624ffd1959bffed104f003d4c1e003d6514ffcaba43fffb42dbffffaac7ffdcf21affde30c3ffc1403500284751fffbdac3fff852caffc457a6002f84a40016a7dc00346fd0002bcc660025a001002ca06cfffd7d7a0005836c00196d51ffc54cb90032202dffcff2d0ffc20746fff65d800011b965ffd69a78ffe3ead3000af25a001fd2b6002aed57fff525cf0023acb4ffdc4505fff4a991ffe7eaf5003d3e7a0016101b0005edefffdaa2280010e4470020388b00243769ffeabebb0026f2910032ea28002bbadb00311a08001bfd3dfff57759ffcd969cffd9f38a0036519cffe06383003acb950017b420002ea308ffe45730ffbe3676ffcddd09ffeb6c8d003de2f5001c67caffdda044ffe29b4e000e443fffc71b240011e37bfff78b1300003622ffedee67ffca12b4ffeb43a4001cb086ffc48e8500083e48ffc094d2003dd646003d545dfffd10ea00014d88001c8c1d0015a16800124736ffeeb98dffc47dd000332948000420a00042f554ffdac256ffd787b4fff3cdfd00145203ffea1843ffe0301e00149d65001a9f5a0033e519001cacb2000fd3a500265d8d001eff1e000d29ceffe899160004328c000dd45afff54bb7ffc97978ffe81823ffcf53e1fff233afffc8d6350005d44500232f700008f9e2fff42792fff5f010001699
 17ffd72777fff39350ffd7b655ffeb282d000f2bab001db15effe3b005ffcc2ff2fffb2a26003beed6fffa0d66ffcaa34e000ba76d001f4238ffcd1b0fffd5de94000b264d != fff0061f00128d23ffdbb433001c7a8affad762dffc43fe4001f6377001f7065ffeb1455ffd22289000872f8ffd1e03b0030157bffe420330031c9eb000138f8ffd7853f00172cf5ffd4a6d9ffb79faaffc130e30033c31700168743ffcd3857001e6944fffc92d5002222ebffc240c7ffecb8d20027be25002a6fc7fff2d430002d63d800041a8e00329bfbffff19a3ffdc90fa00331163fff5b3be002e64e2002d94abff...
>
> @dholmes-ora aarch64? might have to disable the test for it for now.. if its on x86_64.. then I need to investigate..

@vpaprotsk  Aarch64. I'm filing a new bug

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3609351526

From vpaprotski at openjdk.org  Thu Dec  4 00:14:15 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 4 Dec 2025 00:14:15 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <cL4a2iBxS5ORl5DkQkoxgiMkpeMcmNgeFpCrvZF0j5U=.52824906-298d-4b36-907a-95cc1936c4ef@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <nRbdIojalU2u22iZCTHULVANMW7NKkW5WvWgFDaZZYE=.5a07673f-dd7a-48f9-b42b-b337994633f4@github.com>
 <pKk5K-XNCzTBdp75uMDgaN81tvBQtRIoVCa3yom54UA=.8f4096cd-c5ee-4548-b2a7-c72c0b74b6f9@github.com>
 <cL4a2iBxS5ORl5DkQkoxgiMkpeMcmNgeFpCrvZF0j5U=.52824906-298d-4b36-907a-95cc1936c4ef@github.com>
Message-ID: <0PGq1cKej4CVWVbpsUZpsdrgd9FF1nc74ZKDcZyqacM=.faebd5a7-bfa5-43c7-94b5-8bdb4be18591@github.com>

On Thu, 4 Dec 2025 00:09:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dholmes-ora aarch64? might have to disable the test for it for now.. if its on x86_64.. then I need to investigate..
>
> @vpaprotsk  Aarch64. I'm filing a new bug

@dholmes-ora  Will create a PR to disable it for AARCH for now, if you could approve, we could merge

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3609353612

From dholmes at openjdk.org  Thu Dec  4 00:14:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 00:14:16 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
Message-ID: <RNHo7ww-cFL12Fa1NbpfBfYUg-aaac6a8TGVcoTUyAo=.c8004604-4df9-4a85-b711-d635bbd8d977@github.com>

On Mon, 1 Dec 2025 17:54:21 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - Stop catching exception to make test able to fail
> - Remove java-only test variation that cannot fail
> - Reduce fuzz repeat count

Filed [JDK-8373059](https://bugs.openjdk.org/browse/JDK-8373059)

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3609356200

From vpaprotski at openjdk.org  Thu Dec  4 00:35:09 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 4 Dec 2025 00:35:09 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <RNHo7ww-cFL12Fa1NbpfBfYUg-aaac6a8TGVcoTUyAo=.c8004604-4df9-4a85-b711-d635bbd8d977@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <RNHo7ww-cFL12Fa1NbpfBfYUg-aaac6a8TGVcoTUyAo=.c8004604-4df9-4a85-b711-d635bbd8d977@github.com>
Message-ID: <Hfcrbb9aPlHdPPEDHxVqBLnpWeWPhYvdUOo39yWMPsc=.1399ef5e-83f0-4a91-afe3-245b4ea30235@github.com>

On Thu, 4 Dec 2025 00:11:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> - Stop catching exception to make test able to fail
>> - Remove java-only test variation that cannot fail
>> - Reduce fuzz repeat count
>
> Filed [JDK-8373059](https://bugs.openjdk.org/browse/JDK-8373059)

@dholmes-ora https://github.com/openjdk/jdk/pull/28650

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3609401668

From vpaprotski at openjdk.org  Thu Dec  4 00:43:20 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 4 Dec 2025 00:43:20 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java fails on Aarch64 after
 JDK-8372816
Message-ID: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>

I would expect the  test case to pass on aarch64. But since it breaks CI, disabling for now. 

I would appreciate somebody from aarch64 team would investigate why there is a mismatch between the intrinsic ands its java version.

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

Commit messages:
 - disable test on non-x86 for now to investigate aarch64

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

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

From dholmes at openjdk.org  Thu Dec  4 04:23:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 04:23:56 GMT
Subject: RFR: 8373063: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java fails on Aarch64 after
 JDK-8372816
In-Reply-To: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
References: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
Message-ID: <zUfDoqjF-6fAGfJv0OqgRFm1RlhrhQZbuVTd-4JKeCE=.3cd0e7f3-c6ec-4659-8b4f-9bd7d8e4849c@github.com>

On Thu, 4 Dec 2025 00:32:05 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> I would expect the  test case to pass on aarch64. But since it breaks CI, disabling for now. 
> 
> I would appreciate somebody from aarch64 team would investigate why there is a mismatch between the intrinsic ands its java version.

Looks fine to me. Wish I'd seen this PR earlier.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28650#pullrequestreview-3537956226

From ascarpino at openjdk.org  Thu Dec  4 04:49:04 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 4 Dec 2025 04:49:04 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
Message-ID: <8lnYV8RwAV9gKz0t8CQXiYKmy4b7QSdbNBfQw_mwHew=.6af3b9e1-ff40-4dcc-8e2d-ab2efc4a85ad@github.com>

On Tue, 2 Dec 2025 10:47:29 GMT, Arno Zeller <azeller at openjdk.org> wrote:

>> - Stop catching exception to make test able to fail
>> - Remove java-only test variation that cannot fail
>> - Reduce fuzz repeat count
>
> The change looks good, but you might consider using jdk.test.lib.RandomFactory. It allows to get and set a seed that is also printed at every run to make a failure easily reproducible.
> 
> And as the test now fails on aarch64 perhaps it should be excluded there and a bug should be opened - or is the behavior expected on aarch64 ?

The integration of this change is unacceptable. The known aarch64 issue should have been resolved before integration, not deferred to another bug. If reviewers (@ArnoZeller @TheRealMDoerr) cannot verify other architectures, then the PR should not be approved unless the submitter is explicitly required to validate on all relevant platforms first.

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3610102780

From ascarpino at openjdk.org  Thu Dec  4 05:22:55 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 4 Dec 2025 05:22:55 GMT
Subject: RFR: 8373063: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java fails on Aarch64 after
 JDK-8372816
In-Reply-To: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
References: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
Message-ID: <zqZr_aITo1QtcoLIux5qvmTXNvsqszEl17F0r0DwoSE=.8b930b10-1656-4fd3-931a-64ac7c241757@github.com>

On Thu, 4 Dec 2025 00:32:05 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> I would expect the  test case to pass on aarch64. But since it breaks CI, disabling for now. 
> 
> I would appreciate somebody from aarch64 team would investigate why there is a mismatch between the intrinsic ands its java version.

x64 and aarch64 tests passed

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

PR Review: https://git.openjdk.org/jdk/pull/28650#pullrequestreview-3538162947

From jpai at openjdk.org  Thu Dec  4 07:13:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 Dec 2025 07:13:01 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v2]
In-Reply-To: <s_EXrv484Os8Le2KqxofBSc-KNZsAfBrnj5XO2IyDpw=.15347558-ee5c-468e-92e7-e3c2ec2bc834@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <s_EXrv484Os8Le2KqxofBSc-KNZsAfBrnj5XO2IyDpw=.15347558-ee5c-468e-92e7-e3c2ec2bc834@github.com>
Message-ID: <NZfw9kx_UKBig6TXMUfvwh-KU3sXMsnEkSt-x5wzd3g=.fb8c0f6e-a8f9-4e27-9d1a-6b42479e5431@github.com>

On Wed, 3 Dec 2025 18:46:40 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370688: Addressed review comments - add explicit note similar to SSLParameters

Looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28615#pullrequestreview-3538474729

From mdoerr at openjdk.org  Thu Dec  4 09:40:16 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 4 Dec 2025 09:40:16 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
Message-ID: <rt3VXsQQ6eTQs3SZ7Yf9tkC8wtnTUqczBKYD21ZHNuk=.d209079a-ff6a-425b-9e3b-e75e90e58a54@github.com>

On Tue, 2 Dec 2025 10:47:29 GMT, Arno Zeller <azeller at openjdk.org> wrote:

>> - Stop catching exception to make test able to fail
>> - Remove java-only test variation that cannot fail
>> - Reduce fuzz repeat count
>
> The change looks good, but you might consider using jdk.test.lib.RandomFactory. It allows to get and set a seed that is also printed at every run to make a failure easily reproducible.
> 
> And as the test now fails on aarch64 perhaps it should be excluded there and a bug should be opened - or is the behavior expected on aarch64 ?

> The integration of this change is unacceptable. The known aarch64 issue should have been resolved before integration, not deferred to another bug. If reviewers (@ArnoZeller @TheRealMDoerr) cannot verify other architectures, then the PR should not be approved unless the submitter is explicitly required to validate on all relevant platforms first.

That was a bit too quick. Sorry for that. We should add the test to the problem list if we can't fix it quickly.

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3611114149

From mdoerr at openjdk.org  Thu Dec  4 09:57:00 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 4 Dec 2025 09:57:00 GMT
Subject: RFR: 8373063: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java fails on Aarch64 after
 JDK-8372816
In-Reply-To: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
References: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
Message-ID: <Eum-pXDWh5arlpBy31TXd3lvQmk-0PWY8RePbc19Hvs=.0054e5e8-add7-4f7d-aaea-420bb034301d@github.com>

On Thu, 4 Dec 2025 00:32:05 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> I would expect the  test case to pass on aarch64. But since it breaks CI, disabling for now. 
> 
> I would appreciate somebody from aarch64 team would investigate why there is a mismatch between the intrinsic ands its java version.

I would have added it to the problem list for aarch64, but this is fine with me, too.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28650#pullrequestreview-3539045911

From azeller at openjdk.org  Thu Dec  4 09:58:12 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 4 Dec 2025 09:58:12 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
Message-ID: <jt-_gKKKlOWgwm_Ql_Qfq7SUoCXCAGCW3QI1FibiRTQ=.d0ac28ad-7206-493f-a37a-c230b0a07741@github.com>

On Tue, 2 Dec 2025 10:47:29 GMT, Arno Zeller <azeller at openjdk.org> wrote:

>> - Stop catching exception to make test able to fail
>> - Remove java-only test variation that cannot fail
>> - Reduce fuzz repeat count
>
> The change looks good, but you might consider using jdk.test.lib.RandomFactory. It allows to get and set a seed that is also printed at every run to make a failure easily reproducible.
> 
> And as the test now fails on aarch64 perhaps it should be excluded there and a bug should be opened - or is the behavior expected on aarch64 ?

> The integration of this change is unacceptable. The known aarch64 issue should have been resolved before integration, not deferred to another bug. If reviewers (@ArnoZeller @TheRealMDoerr) cannot verify other architectures, then the PR should not be approved unless the submitter is explicitly required to validate on all relevant platforms first.

Sorry for the to early approval and the issues caused by that! 
There is a PR to disable the test on non X86: #28650

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3611197708

From vpaprotski at openjdk.org  Thu Dec  4 10:22:13 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 4 Dec 2025 10:22:13 GMT
Subject: RFR: 8373063: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java fails on Aarch64 after
 JDK-8372816
In-Reply-To: <Eum-pXDWh5arlpBy31TXd3lvQmk-0PWY8RePbc19Hvs=.0054e5e8-add7-4f7d-aaea-420bb034301d@github.com>
References: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
 <Eum-pXDWh5arlpBy31TXd3lvQmk-0PWY8RePbc19Hvs=.0054e5e8-add7-4f7d-aaea-420bb034301d@github.com>
Message-ID: <lLOUa2UPhD_l7txs9sUNIfB2PmRvPffuSke5J9EZ4Lc=.2c34274b-02ea-4333-aece-5d03f64a15d0@github.com>

On Thu, 4 Dec 2025 09:54:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I would have added it to the problem list for aarch64, but this is fine with me, too.

Thanks for the approval. I probably should integrate sooner to clear-up me breaking CI..

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

PR Comment: https://git.openjdk.org/jdk/pull/28650#issuecomment-3611335054

From vpaprotski at openjdk.org  Thu Dec  4 10:25:14 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 4 Dec 2025 10:25:14 GMT
Subject: Integrated: 8373063: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java fails on Aarch64 after
 JDK-8372816
In-Reply-To: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
References: <OgD_ZAWq32brsXaKgIZ9e0xkRbkrea5fv9rfxxHKoHc=.78ae4c5e-0da2-45cf-a709-b7ef2875e2f4@github.com>
Message-ID: <UVyrDviuVOZ94h15hVQLc8RwhNan6h-yOq76r-SwVLA=.34706e1b-9677-4a97-b5a1-2b1af06dcc6c@github.com>

On Thu, 4 Dec 2025 00:32:05 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> I would expect the  test case to pass on aarch64. But since it breaks CI, disabling for now. 
> 
> I would appreciate somebody from aarch64 team would investigate why there is a mismatch between the intrinsic ands its java version.

This pull request has now been integrated.

Changeset: b5970c97
Author:    Volodymyr Paprotski <vpaprotski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5970c97bdd5b1e079e9ada0fbd469850c0e23b4
Stats:     8 lines in 1 file changed: 2 ins; 0 del; 6 mod

8373063: Test sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java fails on Aarch64 after JDK-8372816

Reviewed-by: dholmes, mdoerr

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

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

From vpaprotski at openjdk.org  Thu Dec  4 11:22:08 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 4 Dec 2025 11:22:08 GMT
Subject: RFR: 8372816: New test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java succeeds in case of
 error
In-Reply-To: <jt-_gKKKlOWgwm_Ql_Qfq7SUoCXCAGCW3QI1FibiRTQ=.d0ac28ad-7206-493f-a37a-c230b0a07741@github.com>
References: <qhkpIrdO2PmSaYXkGEFkAFGKHn0rGRZBgeWZXPDo8Y4=.f3adba1a-fe5f-4278-a52b-31963d7c076a@github.com>
 <f-JmmI5pXl7yyeEQI7lbsI0lv99Pup8vhF0z075dFdo=.45540763-17a0-4a12-ba7a-161a6e1d8144@github.com>
 <jt-_gKKKlOWgwm_Ql_Qfq7SUoCXCAGCW3QI1FibiRTQ=.d0ac28ad-7206-493f-a37a-c230b0a07741@github.com>
Message-ID: <ZkPfLk0mqt7kKtCduV9VkiU7Iu7IRvNTUrqppvpCHoI=.e06a9773-1ef6-4e66-9fc0-ff188154ca68@github.com>

On Thu, 4 Dec 2025 09:55:24 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The integration of this change is unacceptable. The known aarch64 issue should have been resolved before integration, not deferred to another bug. If reviewers (@ArnoZeller @TheRealMDoerr) cannot verify other architectures, then the PR should not be approved unless the submitter is explicitly required to validate on all relevant platforms first.

Mea culpa.. was a bit too eager to push this off my plate. Should had thought before calling integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/28584#issuecomment-3611653482

From duke at openjdk.org  Thu Dec  4 11:31:46 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 4 Dec 2025 11:31:46 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v14]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

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

  Update the devkit build scripts to allow the devkit to include the
  required packages for KRB5 (libkrb and libcom_err).
  
  This was run on RHEL8, building for OL6, which required adding isl to
  allow the latest gcc to build (this has been required for some time I
  think).
  
  It also fixes one missing `--prefix` option which was causing things to
  not be correctly installed in the sysroot.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/ed56092b..e3d9c23b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=12-13

  Stats: 34 lines in 1 file changed: 31 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075

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

From duke at openjdk.org  Thu Dec  4 11:31:47 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 4 Dec 2025 11:31:47 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <BxIyyval1TxVnnJXtTKlqFRocvM3tXXetg3mea5wfaE=.f5921cb4-92af-4c6f-919b-9827ed821e1e@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
 <4_rkUaOwuH6_uQRt0HnZKey0t4Z83CQvcrHEqS-VYys=.c825780e-778b-431e-9800-b3a548f1355d@github.com>
 <ZO1hyrSpqBaLEJUS5ondq0v3tiPvuJxJyiZYQ4gHgDs=.98949ddd-e7c4-4502-b1df-dbc5ebbedfb9@github.com>
 <xdUWLsVlUtG9pNOw8nH-im3jaIzN8hO_sF-EvbXbvGo=.775b77bd-5f31-4874-a3fa-fa5374a2f494@github.com>
 <BxIyyval1TxVnnJXtTKlqFRocvM3tXXetg3mea5wfaE=.f5921cb4-92af-4c6f-919b-9827ed821e1e@github.com>
Message-ID: <F70Blrz9Q3uPrDTVnfz_hrFItVU2fotojlcP2-gTswM=.5c64d3eb-4ec1-4749-be66-ad2b0902a56d@github.com>

On Mon, 1 Dec 2025 14:54:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> If you want to drive adoption, or even think about making this mandatory at build time, then at the very least you need to make sure the devkits produced by the makefiles under `make/devkit/...` contain the necessary build time dependencies and generally work with this feature. At least at Oracle we rely on these for our builds and my impression is that at least some other vendors do too.
>> 
>> Thanks.  I had a go at this today, but am struggling to build a devkit (even without any changes).  Can you recommend a suitable host OS for building one, and which OS targets I should use to build the devkits to test?
>> 
>> (I've tried building a devkit for Fedora 41 using both RHEL8 and Fedora 41 as host OSes, but am getting a variety of issues in the build)
>
>> Thanks. I had a go at this today, but am struggling to build a devkit (even without any changes). Can you recommend a suitable host OS for building one, and which OS targets I should use to build the devkits to test?
>> 
>> (I've tried building a devkit for Fedora 41 using both RHEL8 and Fedora 41 as host OSes, but am getting a variety of issues in the build)
> 
> I haven't used this myself in a while, but I believe our internal kits use Oracle Linux 7 as host (in a container) and Oracle Linux 6 as target. RHEL should be equivalent to Oracle Linux, at least in this context. These are quite old, but the motivation for us to use devkits is to guarantee compatibility with old Linux versions. The host OS dictates the oldest where the kit itself can be used and the target dictates the oldest where the subsequently built JDK can be used. 
> 
> That said, getting a devkit to compile can be finicky for all sorts of reasons. The important part in this case is the sysroot, which is what you are going to change here, by adding extra packages. At least in theory, you could generate just a sysroot and supply that to the JDK build to verify this. I don't think there is a readily available make target for that though.

@erikj79 after a little playing around, I've managed to get this to work.

I can now build an Oracle Linux 6 devkit (from RHEL8) and can build a JDK wih my changes from this devkit.  It required a few changes beyond just the packages for libkrb5 - there was a missing library (ISL) required for the newer gcc, and a bug causing some of the files to attempt to install in /usr/local (missing `--prefix`).  I'm not sure if this was exactly what you're looking for, but it's all on the latest commit on this branch for your review.  I'm not sure how to test beyond the tests I've done locally.

[`e3d9c23` (#28075)](https://github.com/openjdk/jdk/pull/28075/commits/e3d9c23b9f724abbac02cef225e6749ffb97e76d)

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3611689545

From schernyshev at openjdk.org  Thu Dec  4 13:31:22 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 4 Dec 2025 13:31:22 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v6]
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <cRAqQzT83jkEiFke9oKVdt2gImvrkWYWHj53uXBl8SY=.e090067f-e2fd-4910-9ff9-34cf5ad4a350@github.com>

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

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

  Apply suggestions from code review
  
  Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28577/files
  - new: https://git.openjdk.org/jdk/pull/28577/files/5c78ce2c..f1067afd

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

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

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

From mullan at openjdk.org  Thu Dec  4 13:39:35 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 4 Dec 2025 13:39:35 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v2]
In-Reply-To: <s_EXrv484Os8Le2KqxofBSc-KNZsAfBrnj5XO2IyDpw=.15347558-ee5c-468e-92e7-e3c2ec2bc834@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <s_EXrv484Os8Le2KqxofBSc-KNZsAfBrnj5XO2IyDpw=.15347558-ee5c-468e-92e7-e3c2ec2bc834@github.com>
Message-ID: <XtvYsxYobPufK0Ia4_v9-HtLXuiIfkgcvo2tiaD10uM=.33470434-5b05-4bf5-9cdc-39927c709887@github.com>

On Wed, 3 Dec 2025 18:46:40 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370688: Addressed review comments - add explicit note similar to SSLParameters

src/java.base/share/classes/java/util/jar/JarEntry.java line 117:

> 115:      * to trust the entry signed by the signers.
> 116:      *
> 117:      * <p>This method will return a new array each time it is invoked.

This sentence is not completely true, because the method may also return `null`. I suggest moving this sentence to the @return label (as the second sentence), and rephrasing it as "If non-null, this method returns a new array each time it is invoked". I removed "will" as I think present tense sounds better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28615#discussion_r2589119626

From sean.mullan at oracle.com  Thu Dec  4 13:42:05 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 4 Dec 2025 08:42:05 -0500
Subject: =?UTF-8?Q?Re=3A_Request_to_include_=E2=80=9CHARICA_TLS_RSA_Root_CA_?=
 =?UTF-8?B?MjAyMeKAnSBhbmQg4oCcSEFSSUNBIFRMUyBFQ0MgUm9vdCBDQSAyMDIx4oCdIGlu?=
 =?UTF-8?Q?_OpenJDK_cacerts?=
In-Reply-To: <GV1P192MB27809284C7A452A6444A812BCDDBA@GV1P192MB2780.EURP192.PROD.OUTLOOK.COM>
References: <GV1P192MB27809284C7A452A6444A812BCDDBA@GV1P192MB2780.EURP192.PROD.OUTLOOK.COM>
Message-ID: <fde88f95-9ae6-41e2-9e8d-1bd53aea4242@oracle.com>

Hi,

Thanks for your inquiry.

All root CA certificate requests should be initiated by the Certificate 
Authority using the process defined at 
https://www.oracle.com/java/technologies/javase/carootcertsprogram.html

In this case, an application has already been filed by Harica for the 
roots below and it is being evaluated.

--Sean

On 12/1/25 4:53 AM, Martijn de Haar wrote:
> Dear OpenJDK Security Team,
> 
> I would like to request the inclusion of the following HARICA root 
> certificates in the default OpenJDK |cacerts|?truststore:
> 
>   *
> 
>     *HARICA TLS RSA Root CA 2021*
> 
>   *
> 
>     *HARICA TLS ECC Root CA 2021*
> 
> These roots are part of HARICA?s 2021 TLS Root hierarchy and are already 
> included in all major trust programs (Apple, Microsoft, Mozilla, Google, 
> Oracle) and in modern operating system trust stores. However, they do 
> not appear to be present in the current OpenJDK |cacerts|?file, while 
> the older HARICA 2015 roots are included (added under JDK-8260597).
> 
> This absence causes Java applications to fail TLS validation when 
> connecting to services that use certificates issued under the 2021 
> HARICA hierarchy.
> 
> Thank you for your time and consideration.
> 
> Kind regards,
> 
> Martijn de Haar
> 
> 
> 
> 


From schernyshev at openjdk.org  Thu Dec  4 14:00:35 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 4 Dec 2025 14:00:35 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <Q9Z0WlGT3DWGyHVL926TMf2SWa5lWVVUk2cCcKSh-8M=.37c97ae2-9823-4c44-888b-ac64ff4c0cd3@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
 <Q9Z0WlGT3DWGyHVL926TMf2SWa5lWVVUk2cCcKSh-8M=.37c97ae2-9823-4c44-888b-ac64ff4c0cd3@github.com>
Message-ID: <oOTmRyQZyF9UEygeVEpfzt9TVJaiGKL9tJHuHXxteck=.12ff3748-a4ce-4dc1-b863-f1a6704da62b@github.com>

On Wed, 3 Dec 2025 07:28:53 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test that ipv4 literals do not propagate to the server names list
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIP.java line 105:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Now that you removed the Thread.sleep, you can't close the socket without reading the request off the input stream; it will cause intermittent connection reset failures on Windows. You can use the [readOneRequest method](https://github.com/openjdk/jdk/blob/530493fed4066b1efcf3ec22253b110495767eca/test/jdk/sun/net/www/http/HttpClient/CookieHttpClientTest.java#L77-L89).

Thanks @djelinski for spotting this. Added the method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2589187574

From schernyshev at openjdk.org  Thu Dec  4 14:00:32 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 4 Dec 2025 14:00:32 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v7]
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <6GTacCykz6WSOZCbU4CIJvHf4_dCG_j8FlsupgiC0uA=.83dbb600-11c8-48e8-8894-97c40c7d0c51@github.com>

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:

 - Apply suggestions from code review
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - addressed more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28577/files
  - new: https://git.openjdk.org/jdk/pull/28577/files/f1067afd..36c08741

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

  Stats: 737 lines in 2 files changed: 379 ins; 358 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28577/head:pull/28577

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

From schernyshev at openjdk.org  Thu Dec  4 14:00:38 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 4 Dec 2025 14:00:38 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
 <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>
Message-ID: <k0vKWH8pL5K88SC36nVijXbvxgshORgKZU2sM19HeRU=.4334c80e-7899-4b91-82b5-1db331e184a1@github.com>

On Wed, 3 Dec 2025 08:45:54 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test that ipv4 literals do not propagate to the server names list
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 140:
> 
>> 138: 
>> 139:         var sniSN = clientSSLSocket.getSSLParameters().getServerNames();
>> 140:         if( sniSN != null && !sniSN.isEmpty()) {
> 
> `if( sniSN` ? `if (sniSN`

Thanks, done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2589190236

From schernyshev at openjdk.org  Thu Dec  4 14:06:22 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 4 Dec 2025 14:06:22 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
 <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>
Message-ID: <4CtGYN_bElH3bVMVRPnBR9PW_az_0ejyvEyl5mxKWnI=.75cbd517-41fe-414f-aea3-a83a1548ee35@github.com>

On Wed, 3 Dec 2025 08:42:54 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test that ipv4 literals do not propagate to the server names list
>
> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 31:
> 
>> 29:  * @library /test/lib
>> 30:  * @comment Insert -Djavax.net.debug=all into the following lines to enable SSL debugging
>> 31:  * @run main/othervm SubjectAltNameIPv6 127.0.0.1
> 
> Since we also test against IPv4, I'd remove the mention of IPv6 from the class name (e.g., `SubjectAltNameIP`) and `@summary`.

Thanks, done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2589213316

From schernyshev at openjdk.org  Thu Dec  4 14:06:24 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 4 Dec 2025 14:06:24 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v5]
In-Reply-To: <YAPM5blxlyplQB-Fvc3zyL7X7vBi9VFvMxX74RQxJgc=.429028e6-ba15-4408-a555-a1d292c300fb@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <Zf9Ox7gLklZdixAutgvE4jW4Jait-Km7yDwGslH2BoY=.071e26f2-e68c-44c6-9a0d-2048e89915e5@github.com>
 <nXnm1q0yP2LiNLSMs5edUmS1vuw_SDNoL67zcyMVJpU=.f0006fac-ecc5-4202-9eee-176efe7a8bb1@github.com>
 <nDLXxbhBvgcWPG1viDVOrmzRoUDrQZE5uiZ5o_8tKMg=.eb1f168a-4e97-4c3f-8a5d-d872cc0fb044@github.com>
 <YAPM5blxlyplQB-Fvc3zyL7X7vBi9VFvMxX74RQxJgc=.429028e6-ba15-4408-a555-a1d292c300fb@github.com>
Message-ID: <prsRdjaVn-JxQnwx1DjphLfCnIEKUKss-Ys9BYyTrNg=.a61595b5-39c6-4f92-be70-2d423324d1c8@github.com>

On Wed, 3 Dec 2025 19:53:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> The method `doClientSide()` is called from constructor, the `clientSSLSocket` is non-static and was set to `null`. Therefore, it's the only assignment of clientSSLSocket per instance. Or do you mean the check must be in the the lambda-expr?
>
> I mean something like:
> 
> Suggestion:
> 
>                 sslSocket -> {
>                     assertNull(clientSSLSocket);
>                     clientSSLSocket = sslSocket;
>                 }));
> 
> 
> To avoid double-assignment and eventually causing verification of the wrong value.

I made `assertEquals` instead, otherwise it shows an incorrect message - it prints the left hand operand as "expected" value, which in the case of `assertNull` is in the right hand operand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2589205237

From mullan at openjdk.org  Thu Dec  4 14:08:34 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 4 Dec 2025 14:08:34 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v11]
In-Reply-To: <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>
Message-ID: <0HIiMXsclfM97MKJLcj4IyzzUaRBKuG5yTfu7OEcu0g=.5dc9d357-f4ae-4859-8bfe-990c8f94e0b7@github.com>

On Thu, 4 Dec 2025 00:03:49 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove null check to not assume key is returned

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 79:

> 77:     // It registers Hybrid KeyPairGenerator, KeyFactory, and KEM
> 78:     // implementations for hybrid named groups as Provider services.
> 79:     private static class ProviderImpl extends Provider {

This provider is not DH specific so doesn't fit right with being in this class. Move this `Provider` out into a separate class and call it `HybridProvider`, or alternatively put it inside the `Hybrid` class (so it would be `Hybrid.ProviderImpl`.) I know it also contains DHasKEM, which is not hybrid, but that is the only case, so I still think Hybrid is a suitable name, with a comment explaining there is one exception.

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 83:

> 81:         private static final long serialVersionUID = 0L;
> 82:         private ProviderImpl() {
> 83:             super("InternalJCEDHasKEM", PROVIDER_VER,

This provider supports more than DH, so suggest calling this "HybridAndDHAsKEM" or something like that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2589205332
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2589211009

From djelinski at openjdk.org  Thu Dec  4 15:29:37 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 4 Dec 2025 15:29:37 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v7]
In-Reply-To: <6GTacCykz6WSOZCbU4CIJvHf4_dCG_j8FlsupgiC0uA=.83dbb600-11c8-48e8-8894-97c40c7d0c51@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <6GTacCykz6WSOZCbU4CIJvHf4_dCG_j8FlsupgiC0uA=.83dbb600-11c8-48e8-8894-97c40c7d0c51@github.com>
Message-ID: <9kY0jI8q-onrT2gyc1z3Ldx9Iz1Y9TQwxObWhlMfHdI=.b7c542c3-568c-44f5-bedb-af8b0b48e98a@github.com>

On Thu, 4 Dec 2025 14:00:32 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - addressed more review comments

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28577#pullrequestreview-3540588435

From weijun at openjdk.org  Thu Dec  4 15:39:39 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 4 Dec 2025 15:39:39 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v11]
In-Reply-To: <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>
Message-ID: <0mcEyqh5bZ_RKhpaahdPDlrCx1AkXIAfNuAInnzdWLI=.55b615b2-50a8-484f-a459-c175c2fc90e9@github.com>

On Thu, 4 Dec 2025 00:03:49 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove null check to not assume key is returned

Some comments.

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 214:

> 212:             if (from == 0 && to == params.secretLen) {
> 213:                 return key;
> 214:             } else if ("RAW".equalsIgnoreCase(key.getFormat())) {

I think it's not worth supporting key slicing because it should never happen. Otherwise there might be a programming error. Throw an AssertionError here.

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 406:

> 404:         // getFormat() returns "RAW" if both keys are X509Key; otherwise null.
> 405:         @Override
> 406:         public String getFormat() {

My understanding is that this will always return "RAW" even if `left` or `right` comes from 3rd-party providers and is not `X509Key`.

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 420:

> 418:             if (left instanceof X509Key xk1 && right instanceof X509Key xk2) {
> 419:                 return concat(xk1.getKeyAsBytes(), xk2.getKeyAsBytes());
> 420:             } else {

Here, we should be prepared for 3rd-party providers -- just call `getEncoded` and strip the ASN.1 headers of algorithm identifiers.

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 459:

> 457: 
> 458:         static boolean isXDH(String name) {
> 459:             return name != null && name.equals("X25519");

Can `name` in the two methods above be null? This might be hiding a bug.

Also, I think it's not worth putting them into a separate class `APS`.

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 184:

> 182:                     KEM.getInstance(algorithmName, provider) :
> 183:                     KEM.getInstance(algorithmName);
> 184:             KEM.Encapsulator e = kem.newEncapsulator(pk);

`newEncapsulator` is called without an `SecureRandom` argument. Is this intended? Otherwise, we had a chance to pass in a user-provided random when `KEMSenderPossession` is created and it can be passed here.

src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 116:

> 114:         private final PublicKey publicKey;
> 115: 
> 116:         KEMReceiverPossession(NamedGroup namedGroup, SecureRandom random) {

`random` is ignored. Is this intended?

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

PR Review: https://git.openjdk.org/jdk/pull/27614#pullrequestreview-3540372956
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2589356191
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2589475112
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2589478265
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2589389536
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2589439762
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2589412239

From smonteith at openjdk.org  Thu Dec  4 16:24:25 2025
From: smonteith at openjdk.org (Stuart Monteith)
Date: Thu, 4 Dec 2025 16:24:25 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3613061007

From rhalade at openjdk.org  Thu Dec  4 17:07:56 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 4 Dec 2025 17:07:56 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags [v4]
In-Reply-To: <NZxu9VbPJdfVybSCKT6Nw0INMAUlDMicqKJvMQHS6vg=.61537368-126c-4c74-b020-47feea7e4cd8@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
 <NZxu9VbPJdfVybSCKT6Nw0INMAUlDMicqKJvMQHS6vg=.61537368-126c-4c74-b020-47feea7e4cd8@github.com>
Message-ID: <D-KQK0bm61OT79rjVRRqp20CgVEKj6ZQ74TzhXyO86A=.12ce1f6b-e577-4d51-a8f1-ba873058724c@github.com>

On Fri, 21 Nov 2025 12:31:28 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.
>> 
>> ### ISSUE :- 
>> In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
>>     
>> -> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();
>> 
>>>   public static String[] addTestJavaOpts(String... userArgs) {
>>>         return prependTestJavaOpts(userArgs);
>>>     }
>> 
>> -> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()
>> 
>>> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>>>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>>>     }
>> 
>> 
>> Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )
>> 
>>> public static String[] getTestJavaOpts() {
>>>         List<String> opts = new ArrayList<String>();
>>>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>>>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>>>         return opts.toArray(new String[0]);
>>>     }
>> 
>> Contributed-by: @Korov 
>> https://github.com/openjdk/jdk/pull/26404
>> 
>> https://bugs.openjdk.org/browse/JDK-8362658
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Removed the list of test case from problemList file.

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28428#pullrequestreview-3541075242

From rhalade at openjdk.org  Thu Dec  4 17:09:05 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 4 Dec 2025 17:09:05 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap [v2]
In-Reply-To: <Di_c-9qRwxGMtJ7X_eiCVKY_L5lNfM2GCb5kNfLvCL4=.feb4db1d-c356-405d-8a68-79cec50d06f9@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
 <Di_c-9qRwxGMtJ7X_eiCVKY_L5lNfM2GCb5kNfLvCL4=.feb4db1d-c356-405d-8a68-79cec50d06f9@github.com>
Message-ID: <tmi7_OM_PGcvpbl1TarTJeoQY66R1S-cgiTFqKK7-qM=.d2ea5000-8346-47e1-983f-5e45364a3c9c@github.com>

On Fri, 21 Nov 2025 12:07:32 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases. 
>> 
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Corrected copyright format.

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27847#pullrequestreview-3541078381

From rhalade at openjdk.org  Thu Dec  4 17:12:25 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 4 Dec 2025 17:12:25 GMT
Subject: RFR: 8356544: Implement additional tests for ciphersuites disabled
 with wildcards [v2]
In-Reply-To: <4bTAGA8qNdKX38bXrg9Z4Mc84XtjeMEEUtuz14tGFX8=.d09de3f2-5749-46af-9f7f-d4b702fe7373@github.com>
References: <je_VCMu-DDtmPzrrRawpZGSXmsPv6ttLD6-k4QORWVc=.e83e6d61-1494-4c28-88fa-8d8d202ce87d@github.com>
 <4bTAGA8qNdKX38bXrg9Z4Mc84XtjeMEEUtuz14tGFX8=.d09de3f2-5749-46af-9f7f-d4b702fe7373@github.com>
Message-ID: <GlFIyh_QHiG2JnlDL1lLcC4SYfQ5jW38DpcYpS4AV7c=.50361ceb-a7cc-4560-a9f1-8611c1512561@github.com>

On Mon, 24 Nov 2025 17:50:32 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR extends the tests from JDK-8341964 and verifies a TLS server (or client) will not negotiate a ciphersuite requested by the remote peer but disabled with a wildcard.
>
> Matthew Donovan 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:
> 
>  - Addressed PR comments
>  - Merge branch 'master' into cipher-wildcard
>  - 8356544: Implement additional tests for ciphersuites disabled with wildcards

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28003#pullrequestreview-3541095779

From rhalade at openjdk.org  Thu Dec  4 17:15:45 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 4 Dec 2025 17:15:45 GMT
Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass
 when they should skip [v6]
In-Reply-To: <4MPhZ2Uv1E3Wv2ohROMgeu7_KHe1YLrZr4GvDuplgSU=.855e6aa2-d6c4-49d3-8e41-fd89d0e5b619@github.com>
References: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
 <4MPhZ2Uv1E3Wv2ohROMgeu7_KHe1YLrZr4GvDuplgSU=.855e6aa2-d6c4-49d3-8e41-fd89d0e5b619@github.com>
Message-ID: <FQBMbPvIwBlGgIB5KWpQI-xMtWXmopvKRTGhaZBVbbE=.7b3ab95f-eda5-434c-a9bf-1895fb488172@github.com>

On Mon, 1 Dec 2025 14:12:36 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java
>> * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
>> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java
>> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java
>> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java
>> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java
>> * test/jdk/sun/security/pkcs11/Signature/TestDSA.java
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked skipped logic to be list based

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27367#pullrequestreview-3541113575

From fferrari at openjdk.org  Thu Dec  4 17:27:25 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 4 Dec 2025 17:27:25 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
Message-ID: <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>

On Wed, 3 Dec 2025 15:41:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Convert ConfigFileTestAnonymousPipes to Java
>>  - Review suggestion: go back tolerating IOException
>>    
>>    We agreed an IOException in this case is recoverable, and decided to
>>    tolerate it, while adding a debug log message with the exception.
>>  - Review suggestion: improve comment clarity
>
> src/java.base/share/classes/java/security/Security.java line 260:
> 
>> 258:                     // under the rationale that the person writing the
>> 259:                     // original properties file is the one who decides
>> 260:                     // where the relative includes should resolve.
> 
> The person writing the original properties file may have expected includes to resolve relative to its own location, but whoever created the symlink may have intended a different resolution path. If they wanted the original location, they could have just used the real file directly instead of introducing a symlink.
> 
> For a comparison, I write a tiny C program that includes another file, the included file was resolved based on the base file's named path, not its real path.
> 
> I know you might have a backward compatibility concern here.

Hi @wangweij, indeed is a fair and interesting point of view!

I like the idea of not doing any resolution at all to get rid of the possible problems. But let me do a similar test with some other programs supporting include directives in their configuration files (such as [OpenSSL](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Other%20files%20can,ignore%20the%20include%2e), [OpenSSH](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=it%2e-,Include,inclusion%2e), [Git](https://git-scm.com/docs/git-config#_includes) and [Apache HTTP Server](https://httpd.apache.org/docs/2.4/mod/core.html#include)), to collect more real world examples (beyond C includes which you already tested).

Regarding the backward compatibility, this is not the main use case, and if we could back-port that to 25 in the future, we would get the same behavior in all the supported JDKs shipping [JDK-8319332](https://bugs.openjdk.org/browse/JDK-8319332 "Security properties files inclusion") (as 24 reached end of support).

Would you think that such a change requires a CSR? If that's the case I would support the change but in a separate enhancement, so we can get this bug fixed in 26.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2589946016

From weijun at openjdk.org  Thu Dec  4 17:35:42 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 4 Dec 2025 17:35:42 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
Message-ID: <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>

On Thu, 4 Dec 2025 17:24:03 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 260:
>> 
>>> 258:                     // under the rationale that the person writing the
>>> 259:                     // original properties file is the one who decides
>>> 260:                     // where the relative includes should resolve.
>> 
>> The person writing the original properties file may have expected includes to resolve relative to its own location, but whoever created the symlink may have intended a different resolution path. If they wanted the original location, they could have just used the real file directly instead of introducing a symlink.
>> 
>> For a comparison, I write a tiny C program that includes another file, the included file was resolved based on the base file's named path, not its real path.
>> 
>> I know you might have a backward compatibility concern here.
>
> Hi @wangweij, indeed is a fair and interesting point of view!
> 
> I like the idea of not doing any resolution at all to get rid of the possible problems. But let me do a similar test with some other programs supporting include directives in their configuration files (such as [OpenSSL](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Other%20files%20can,ignore%20the%20include%2e), [OpenSSH](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=it%2e-,Include,inclusion%2e), [Git](https://git-scm.com/docs/git-config#_includes) and [Apache HTTP Server](https://httpd.apache.org/docs/2.4/mod/core.html#include)), to collect more real world examples (beyond C includes which you already tested).
> 
> Regarding the backward compatibility, this is not the main use case, and if we could back-port that to 25 in the future, we would get the same behavior in all the supported JDKs shipping [JDK-8319332](https://bugs.openjdk.org/browse/JDK-8319332 "Security properties files inclusion") (as 24 reached end of support).
> 
> Would you think that such a change requires a CSR? If that's the case I would support the change but in a separate enhancement, so we can get this bug fixed in 26.

Yes, it's good to see how this behaves on other programs, especially in configuration files. I know `krb5.conf` also supports it but it requires the included file having an absolute path.

> Would you think that such a change requires a CSR?

Maybe not. I see nowhere in its description in `java.security` talking about relative path resolution, so you have no specification to update.

A release note is enough, IMO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2589975871

From mikael at openjdk.org  Thu Dec  4 17:46:40 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 4 Dec 2025 17:46:40 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v14]
In-Reply-To: <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
Message-ID: <X4HSw5HkJ2Fjqqd6FdBstwg_xYayjmLpdEUGtGC8_yU=.cf5c1cc0-f470-430d-a95d-26849e1c91b9@github.com>

On Thu, 4 Dec 2025 11:31:46 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the devkit build scripts to allow the devkit to include the
>   required packages for KRB5 (libkrb and libcom_err).
>   
>   This was run on RHEL8, building for OL6, which required adding isl to
>   allow the latest gcc to build (this has been required for some time I
>   think).
>   
>   It also fixes one missing `--prefix` option which was causing things to
>   not be correctly installed in the sysroot.

If I understand this correctly, the ISL addition to devkit/Tools.gmk is orthogonal to the kerberos related changes. If so, can I suggest splitting that out into a separate change please?

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3613507509

From weijun at openjdk.org  Thu Dec  4 18:18:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 4 Dec 2025 18:18:51 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v14]
In-Reply-To: <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
Message-ID: <wmZTpAh5j2ZEri7NrGWjbc3TIl2UY3Nn4PffuVzOHDs=.efdc5d6d-c98e-4bd2-a107-5d9427d8d424@github.com>

On Thu, 4 Dec 2025 11:31:46 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the devkit build scripts to allow the devkit to include the
>   required packages for KRB5 (libkrb and libcom_err).
>   
>   This was run on RHEL8, building for OL6, which required adding isl to
>   allow the latest gcc to build (this has been required for some time I
>   think).
>   
>   It also fixes one missing `--prefix` option which was causing things to
>   not be correctly installed in the sysroot.

Hi Nick, Thank you for the extra work on updating the devkit. After thinking it through, it?s probably not ideal to continue with the current JNI-based approach. Newer releases encourage using FFM for native interaction, and the JNI path adds extra build-time dependencies. If you?re open to it, this is a good opportunity to rewrite the feature with FFM. I?ve tried parts of it and it looks feasible.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3613683504

From erikj at openjdk.org  Thu Dec  4 18:40:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 4 Dec 2025 18:40:45 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <BxIyyval1TxVnnJXtTKlqFRocvM3tXXetg3mea5wfaE=.f5921cb4-92af-4c6f-919b-9827ed821e1e@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
 <4_rkUaOwuH6_uQRt0HnZKey0t4Z83CQvcrHEqS-VYys=.c825780e-778b-431e-9800-b3a548f1355d@github.com>
 <ZO1hyrSpqBaLEJUS5ondq0v3tiPvuJxJyiZYQ4gHgDs=.98949ddd-e7c4-4502-b1df-dbc5ebbedfb9@github.com>
 <xdUWLsVlUtG9pNOw8nH-im3jaIzN8hO_sF-EvbXbvGo=.775b77bd-5f31-4874-a3fa-fa5374a2f494@github.com>
 <BxIyyval1TxVnnJXtTKlqFRocvM3tXXetg3mea5wfaE=.f5921cb4-92af-4c6f-919b-9827ed821e1e@github.com>
Message-ID: <nMUq_q34bsuCXuleFTJY0cskoi0f0uizGmddXjaUHwo=.6fdb9a59-85f8-4684-a77a-d3089336f690@github.com>

On Mon, 1 Dec 2025 14:54:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> If you want to drive adoption, or even think about making this mandatory at build time, then at the very least you need to make sure the devkits produced by the makefiles under `make/devkit/...` contain the necessary build time dependencies and generally work with this feature. At least at Oracle we rely on these for our builds and my impression is that at least some other vendors do too.
>> 
>> Thanks.  I had a go at this today, but am struggling to build a devkit (even without any changes).  Can you recommend a suitable host OS for building one, and which OS targets I should use to build the devkits to test?
>> 
>> (I've tried building a devkit for Fedora 41 using both RHEL8 and Fedora 41 as host OSes, but am getting a variety of issues in the build)
>
>> Thanks. I had a go at this today, but am struggling to build a devkit (even without any changes). Can you recommend a suitable host OS for building one, and which OS targets I should use to build the devkits to test?
>> 
>> (I've tried building a devkit for Fedora 41 using both RHEL8 and Fedora 41 as host OSes, but am getting a variety of issues in the build)
> 
> I haven't used this myself in a while, but I believe our internal kits use Oracle Linux 7 as host (in a container) and Oracle Linux 6 as target. RHEL should be equivalent to Oracle Linux, at least in this context. These are quite old, but the motivation for us to use devkits is to guarantee compatibility with old Linux versions. The host OS dictates the oldest where the kit itself can be used and the target dictates the oldest where the subsequently built JDK can be used. 
> 
> That said, getting a devkit to compile can be finicky for all sorts of reasons. The important part in this case is the sysroot, which is what you are going to change here, by adding extra packages. At least in theory, you could generate just a sysroot and supply that to the JDK build to verify this. I don't think there is a readily available make target for that though.

> @erikj79 after a little playing around, I've managed to get this to work.
> 
> I can now build an Oracle Linux 6 devkit (from RHEL8) and can build a JDK wih my changes from this devkit. It required a few changes beyond just the packages for libkrb5 - there was a missing library (ISL) required for the newer gcc, and a bug causing some of the files to attempt to install in /usr/local (missing `--prefix`). I'm not sure if this was exactly what you're looking for, but it's all on the latest commit on this branch for your review. I'm not sure how to test beyond the tests I've done locally.

That's impressive getting it to work. As Mikael says, I think it would be better to break out any additional changes you made to the devkit makefile into a separate change, if we still want to go that route. I haven't looked into the ISL dependency much, but it looks like something we should add to the devkit for newer GCCs. For this change I was mostly interested in the extra libraries that would be needed in the sysroot. However, as @wangweij pointed out, if this could be handled with FFM instead of JNI, that would be even better and avoid all this hassle.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3613800173

From mdonovan at openjdk.org  Thu Dec  4 18:43:54 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 4 Dec 2025 18:43:54 GMT
Subject: Integrated: 8356544: Implement additional tests for ciphersuites
 disabled with wildcards
In-Reply-To: <je_VCMu-DDtmPzrrRawpZGSXmsPv6ttLD6-k4QORWVc=.e83e6d61-1494-4c28-88fa-8d8d202ce87d@github.com>
References: <je_VCMu-DDtmPzrrRawpZGSXmsPv6ttLD6-k4QORWVc=.e83e6d61-1494-4c28-88fa-8d8d202ce87d@github.com>
Message-ID: <d6E6Buae2561iS5YU3gfLHME4yQgztp0Gzx9qeCIC68=.2e69fe4a-c571-46e7-8584-32510b3947f0@github.com>

On Mon, 27 Oct 2025 15:54:34 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR extends the tests from JDK-8341964 and verifies a TLS server (or client) will not negotiate a ciphersuite requested by the remote peer but disabled with a wildcard.

This pull request has now been integrated.

Changeset: b19163b1
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b19163b107584118056073dc24a960ca04ca14e4
Stats:     158 lines in 1 file changed: 158 ins; 0 del; 0 mod

8356544: Implement additional tests for ciphersuites disabled with wildcards

Reviewed-by: rhalade

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

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

From myankelevich at openjdk.org  Thu Dec  4 18:45:52 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 4 Dec 2025 18:45:52 GMT
Subject: Integrated: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests
 pass when they should skip
In-Reply-To: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
References: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
Message-ID: <kAn1xPYxK-NK7yi9Cyp1-6B-gc-FZNJpMmREm1PyYiU=.b304ea33-567c-42c3-bacb-fbbd71abd47e@github.com>

On Thu, 18 Sep 2025 14:56:13 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java
> * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java
> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java
> * test/jdk/sun/security/pkcs11/Signature/TestDSA.java

This pull request has now been integrated.

Changeset: ef7532e7
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef7532e7e625628d6181c65116804ebb65f18061
Stats:     175 lines in 7 files changed: 115 ins; 15 del; 45 mod

8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip

Reviewed-by: rhalade

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

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

From mdonovan at openjdk.org  Thu Dec  4 18:58:56 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 4 Dec 2025 18:58:56 GMT
Subject: RFR: 8373101: JdkClient and JdkServer test classes ignore namedGroups
 field
Message-ID: <xclTtN9JD3D4bQQOi5nV69exU7HzNllXXmTv_f6-Z3M=.eb524c86-50ad-4e1d-8763-a4856f05b856@github.com>

This PR updates a couple test utility classes, JdkClient and JdkServer. Theseclasses extend AbstractPeer which contains a `namedGroup` field however, when creating/configuring the objects, the field is ignored. This PR just makes sure to include named groups if they are specified.

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

Commit messages:
 - 8373101: JdkClient and JdkServer test classes ignore namedGroups field

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

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

From mullan at openjdk.org  Thu Dec  4 21:27:16 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 4 Dec 2025 21:27:16 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v3]
In-Reply-To: <gts4SYkcbfDLFF3hTv449tZTu7pmjdI0hrhYcVNhS8I=.32c3ee5d-f4fd-4e69-ac53-b54af7fb2764@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <gts4SYkcbfDLFF3hTv449tZTu7pmjdI0hrhYcVNhS8I=.32c3ee5d-f4fd-4e69-ac53-b54af7fb2764@github.com>
Message-ID: <jp-V1LMyBXVcsIdkKula43BZOuoEzcT7Gnv0k61InpM=.cf9aa76a-48fe-400d-9926-1b90b0e63245@github.com>

On Mon, 1 Dec 2025 16:11:14 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert logging changes

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 41:

> 39: import sun.security.validator.*;
> 40: 
> 41: /**

It seems only the last few sentences are outdated. Also, although we don't use `@author` labels anymore, we typically leave existing ones in place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2590617925

From duke at openjdk.org  Thu Dec  4 21:28:30 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 4 Dec 2025 21:28:30 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v3]
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <bjIGB9ayk6evSwmGqpZWojUma84b_7J9J9PENUBbiPM=.d5ab4246-b093-49d9-b43f-f2031a0eac3b@github.com>

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8370688: Addressed review comments-moved the sentence to return label

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28615/files
  - new: https://git.openjdk.org/jdk/pull/28615/files/59abe38b..d53fe8ff

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

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

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

From hchao at openjdk.org  Fri Dec  5 02:36:13 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 5 Dec 2025 02:36:13 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v11]
In-Reply-To: <0mcEyqh5bZ_RKhpaahdPDlrCx1AkXIAfNuAInnzdWLI=.55b615b2-50a8-484f-a459-c175c2fc90e9@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>
 <0mcEyqh5bZ_RKhpaahdPDlrCx1AkXIAfNuAInnzdWLI=.55b615b2-50a8-484f-a459-c175c2fc90e9@github.com>
Message-ID: <C85jHZoVNuKLuNLSkxBLZwa9lR3eAOdBZXlfRn1Z_aU=.164e57f2-4683-48a2-af82-213668844f1a@github.com>

On Thu, 4 Dec 2025 14:41:34 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:
>> 
>>   Remove null check to not assume key is returned
>
> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 214:
> 
>> 212:             if (from == 0 && to == params.secretLen) {
>> 213:                 return key;
>> 214:             } else if ("RAW".equalsIgnoreCase(key.getFormat())) {
> 
> I think it's not worth supporting key slicing because it should never happen. Otherwise there might be a programming error. Throw an AssertionError here.

Removed key slicing.

> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 406:
> 
>> 404:         // getFormat() returns "RAW" if both keys are X509Key; otherwise null.
>> 405:         @Override
>> 406:         public String getFormat() {
> 
> My understanding is that this will always return "RAW" even if `left` or `right` comes from 3rd-party providers and is not `X509Key`.

Fixed.

> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 420:
> 
>> 418:             if (left instanceof X509Key xk1 && right instanceof X509Key xk2) {
>> 419:                 return concat(xk1.getKeyAsBytes(), xk2.getKeyAsBytes());
>> 420:             } else {
> 
> Here, we should be prepared for 3rd-party providers -- just call `getEncoded` and strip the ASN.1 headers of algorithm identifiers.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2591211285
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2591211533
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2591211933

From hchao at openjdk.org  Fri Dec  5 02:42:21 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 5 Dec 2025 02:42:21 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v12]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <NpUgvcyFos5pK1446Mnw645lmjJfgKGOE-tXyyqRZ3g=.b3b7eba2-ac42-425b-a100-4bdbbdfd9e4d@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  Updates with Weijun's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/37a69689..276ff264

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=10-11

  Stats: 44 lines in 2 files changed: 21 ins; 16 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From hchao at openjdk.org  Fri Dec  5 03:39:22 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 5 Dec 2025 03:39:22 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v13]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <BVcSY03gYWzvnGa1dun-Z30NwjZE4xQajljY0PRBHHs=.8d3f3dfc-1da5-456a-a357-f95f8ff22cb3@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - reapply changes after merge
 - Merge
 - backout conflict change in KeyShareExtension.java
 - Updates with Weijun's comments
 - Remove null check to not assume key is returned
 - Updates with Brad's and Sean's comments
 - Move Hybrid.java to sun.security.ssl
 - Move DH.java to sun.security.ssl as DHasKEM.java
 - Update names to uppercase
 - Remove fallback in engineGeneratePublic
 - ... and 17 more: https://git.openjdk.org/jdk/compare/7e91d34f...9c362c3e

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

Changes: https://git.openjdk.org/jdk/pull/27614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=12
  Stats: 1809 lines in 21 files changed: 1695 ins; 41 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From vyazici at openjdk.org  Fri Dec  5 08:20:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 5 Dec 2025 08:20:00 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v7]
In-Reply-To: <6GTacCykz6WSOZCbU4CIJvHf4_dCG_j8FlsupgiC0uA=.83dbb600-11c8-48e8-8894-97c40c7d0c51@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <6GTacCykz6WSOZCbU4CIJvHf4_dCG_j8FlsupgiC0uA=.83dbb600-11c8-48e8-8894-97c40c7d0c51@github.com>
Message-ID: <xyxXpD-zMr94RebpEUjw3hoXOgYY0IoEYueq54Z57uU=.589322cf-7b1e-4b5c-b644-df6f00f89aa3@github.com>

On Thu, 4 Dec 2025 14:00:32 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - addressed more review comments

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28577#pullrequestreview-3543570009

From duke at openjdk.org  Fri Dec  5 11:10:20 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 5 Dec 2025 11:10:20 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <nMUq_q34bsuCXuleFTJY0cskoi0f0uizGmddXjaUHwo=.6fdb9a59-85f8-4684-a77a-d3089336f690@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <tGp6Qqn9spJFH4vnWERCenE-KtQuZ7DsILizt3lcwbA=.c2832c5c-9949-447e-b9a1-3cc262d16e8b@github.com>
 <4_rkUaOwuH6_uQRt0HnZKey0t4Z83CQvcrHEqS-VYys=.c825780e-778b-431e-9800-b3a548f1355d@github.com>
 <ZO1hyrSpqBaLEJUS5ondq0v3tiPvuJxJyiZYQ4gHgDs=.98949ddd-e7c4-4502-b1df-dbc5ebbedfb9@github.com>
 <xdUWLsVlUtG9pNOw8nH-im3jaIzN8hO_sF-EvbXbvGo=.775b77bd-5f31-4874-a3fa-fa5374a2f494@github.com>
 <BxIyyval1TxVnnJXtTKlqFRocvM3tXXetg3mea5wfaE=.f5921cb4-92af-4c6f-919b-9827ed821e1e@github.com>
 <nMUq_q34bsuCXuleFTJY0cskoi0f0uizGmddXjaUHwo=.6fdb9a59-85f8-4684-a77a-d3089336f690@github.com>
Message-ID: <qgTCsWqa3Zn6zhE9e6Lx9llQQ9K5hB-gdaouPf-JoMo=.70c485fb-6b91-43be-bf65-2e678a99e56b@github.com>

On Thu, 4 Dec 2025 18:38:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > @erikj79 after a little playing around, I've managed to get this to work.
> > I can now build an Oracle Linux 6 devkit (from RHEL8) and can build a JDK wih my changes from this devkit. It required a few changes beyond just the packages for libkrb5 - there was a missing library (ISL) required for the newer gcc, and a bug causing some of the files to attempt to install in /usr/local (missing `--prefix`). I'm not sure if this was exactly what you're looking for, but it's all on the latest commit on this branch for your review. I'm not sure how to test beyond the tests I've done locally.
> 
> That's impressive getting it to work. As Mikael says, I think it would be better to break out any additional changes you made to the devkit makefile into a separate change, if we still want to go that route. I haven't looked into the ISL dependency much, but it looks like something we should add to the devkit for newer GCCs. For this change I was mostly interested in the extra libraries that would be needed in the sysroot. However, as @wangweij pointed out, if this could be handled with FFM instead of JNI, that would be even better and avoid all this hassle.

Happy to - will somebody need to create me an issue in the tracker so I can raise a PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3616413154

From duke at openjdk.org  Fri Dec  5 12:15:01 2025
From: duke at openjdk.org (Neha Joshi)
Date: Fri, 5 Dec 2025 12:15:01 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap [v3]
In-Reply-To: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
Message-ID: <8XbuRLOTYZOf2gxGV5gtkbOK-EDCVo9ATj6fmJKk9xY=.b9e24391-924d-4415-a78a-e195f1613d99@github.com>

> This PR contain changes to handle skipped exception for below test cases. 
> 
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java

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

 - JDK-8368524 : Resolved merge conflicts.
 - JDK-8368524 : Resolved merge conflicts.
 - JDK-8368524 : Corrected copyright format.
 - JDK-8368524 : Review comment changes.
 - JDK-8368524 : Removed commented imports.
 - JDK-8368524 : Review comment changes.
 - JDK-8368524 : Removed wildcard imports
 - JDK-8368524 : Updated Skipped exception message
 - JDK-8368524 : Copyright date updated.
 - JDK-8368524 : Handle skipped exceptions.

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

Changes: https://git.openjdk.org/jdk/pull/27847/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27847&range=02
  Stats: 17 lines in 3 files changed: 4 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27847/head:pull/27847

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

From duke at openjdk.org  Fri Dec  5 12:24:37 2025
From: duke at openjdk.org (Neha Joshi)
Date: Fri, 5 Dec 2025 12:24:37 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap [v4]
In-Reply-To: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
Message-ID: <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>

> This PR contain changes to handle skipped exception for below test cases. 
> 
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java

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

  JDK-8368524 : Formatting issue resolved.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27847/files
  - new: https://git.openjdk.org/jdk/pull/27847/files/8f531df1..afcffbdb

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

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

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

From weijun at openjdk.org  Fri Dec  5 12:35:00 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 Dec 2025 12:35:00 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v14]
In-Reply-To: <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
Message-ID: <92a9NBPWwWbektJmI-RKJF9boCN9OpwNs4A5eX4uQT0=.0545f526-3fcd-4d4d-a76e-7f394d13eede@github.com>

On Thu, 4 Dec 2025 11:31:46 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the devkit build scripts to allow the devkit to include the
>   required packages for KRB5 (libkrb and libcom_err).
>   
>   This was run on RHEL8, building for OL6, which required adding isl to
>   allow the latest gcc to build (this has been required for some time I
>   think).
>   
>   It also fixes one missing `--prefix` option which was causing things to
>   not be correctly installed in the sysroot.

A new enhancement is filed at https://bugs.openjdk.org/browse/JDK-8373137.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3616738507

From myankelevich at openjdk.org  Fri Dec  5 12:39:01 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 5 Dec 2025 12:39:01 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap [v4]
In-Reply-To: <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
 <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
Message-ID: <qiv0tG-iajh6-d1_M5lb2zkQDhLmGJA9jZPaxGFf7SE=.b53358aa-393a-4e48-94d2-436891c00fc6@github.com>

On Fri, 5 Dec 2025 12:24:37 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases. 
>> 
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Formatting issue resolved.

Marked as reviewed by myankelevich (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27847#pullrequestreview-3544590104

From myankelevich at openjdk.org  Fri Dec  5 13:32:02 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 5 Dec 2025 13:32:02 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap [v4]
In-Reply-To: <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
 <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
Message-ID: <oMDB7L9BwIfexC07_RR8wPIn1draf1g4i7lorBDWOxA=.d60248a5-70bf-4b66-abb3-5d999328a00b@github.com>

On Fri, 5 Dec 2025 12:24:37 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases. 
>> 
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Formatting issue resolved.

Thanks for fixing issues caused by [JDK-8371262](https://bugs.openjdk.org/browse/JDK-8371262)!

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

PR Comment: https://git.openjdk.org/jdk/pull/27847#issuecomment-3616938548

From duke at openjdk.org  Fri Dec  5 13:41:57 2025
From: duke at openjdk.org (Neha Joshi)
Date: Fri, 5 Dec 2025 13:41:57 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap [v4]
In-Reply-To: <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
 <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
Message-ID: <JibcWOoymTYcvoIh0jvpS9yeVWaW_e9Ek-1eAvzHYNQ=.007d49aa-088d-4299-94fe-f656d8b8eafa@github.com>

On Fri, 5 Dec 2025 12:24:37 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases. 
>> 
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Formatting issue resolved.

There is a slight change in the PR earlier, this PR contained changes to handle skipped exception for below test cases. 

* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java

But there is similar ticket https://bugs.openjdk.org/browse/JDK-8371262 which got merged before this change so, now in this PR we are fixing the issues caused by that ticket  which is adding the continue in the loop.

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

PR Comment: https://git.openjdk.org/jdk/pull/27847#issuecomment-3616969290

From mullan at openjdk.org  Fri Dec  5 13:51:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 5 Dec 2025 13:51:29 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v3]
In-Reply-To: <bjIGB9ayk6evSwmGqpZWojUma84b_7J9J9PENUBbiPM=.d5ab4246-b093-49d9-b43f-f2031a0eac3b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <bjIGB9ayk6evSwmGqpZWojUma84b_7J9J9PENUBbiPM=.d5ab4246-b093-49d9-b43f-f2031a0eac3b@github.com>
Message-ID: <eAq6gnrmarBYfsH5lt7YEN6cEW7qgtDyAvXEZnWZ3Ko=.ca7f608e-bf7c-41a1-8b34-7b0bb6be7ec0@github.com>

On Thu, 4 Dec 2025 21:28:30 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370688: Addressed review comments-moved the sentence to return label

src/java.base/share/classes/java/util/jar/JarEntry.java line 118:

> 116:      *
> 117:      * @return the {@code Certificate} objects for this entry, or
> 118:      * {@code null} if none. If non-null, this method returns a new

I think you can remove the "this method" words as it is implied by being in the "@return".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28615#discussion_r2592754088

From duke at openjdk.org  Fri Dec  5 13:58:31 2025
From: duke at openjdk.org (duke)
Date: Fri, 5 Dec 2025 13:58:31 GMT
Subject: RFR: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm
 flags [v4]
In-Reply-To: <NZxu9VbPJdfVybSCKT6Nw0INMAUlDMicqKJvMQHS6vg=.61537368-126c-4c74-b020-47feea7e4cd8@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
 <NZxu9VbPJdfVybSCKT6Nw0INMAUlDMicqKJvMQHS6vg=.61537368-126c-4c74-b020-47feea7e4cd8@github.com>
Message-ID: <4BnuEPeigdMv1pay3gqIy3lEiP72XadU8ysUpDTkDFs=.9d179abd-105a-403e-953b-2d42f833d23b@github.com>

On Fri, 21 Nov 2025 12:31:28 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.
>> 
>> ### ISSUE :- 
>> In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
>>     
>> -> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();
>> 
>>>   public static String[] addTestJavaOpts(String... userArgs) {
>>>         return prependTestJavaOpts(userArgs);
>>>     }
>> 
>> -> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()
>> 
>>> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>>>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>>>     }
>> 
>> 
>> Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )
>> 
>>> public static String[] getTestJavaOpts() {
>>>         List<String> opts = new ArrayList<String>();
>>>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>>>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>>>         return opts.toArray(new String[0]);
>>>     }
>> 
>> Contributed-by: @Korov 
>> https://github.com/openjdk/jdk/pull/26404
>> 
>> https://bugs.openjdk.org/browse/JDK-8362658
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Removed the list of test case from problemList file.

@nehajoshinj 
Your change (at version c641c6ef601d4a10b896e706899bfca1ceb26df9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28428#issuecomment-3617028108

From weijun at openjdk.org  Fri Dec  5 16:13:25 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 Dec 2025 16:13:25 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v13]
In-Reply-To: <BVcSY03gYWzvnGa1dun-Z30NwjZE4xQajljY0PRBHHs=.8d3f3dfc-1da5-456a-a357-f95f8ff22cb3@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <BVcSY03gYWzvnGa1dun-Z30NwjZE4xQajljY0PRBHHs=.8d3f3dfc-1da5-456a-a357-f95f8ff22cb3@github.com>
Message-ID: <I9-6-_eX9_sSPELp6Clt1tiwkr2-NJ7fgdO-Su4xs4Q=.d45d5a0a-1434-4745-b511-0cf93e5118af@github.com>

On Fri, 5 Dec 2025 03:39:22 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - reapply changes after merge
>  - Merge
>  - backout conflict change in KeyShareExtension.java
>  - Updates with Weijun's comments
>  - Remove null check to not assume key is returned
>  - Updates with Brad's and Sean's comments
>  - Move Hybrid.java to sun.security.ssl
>  - Move DH.java to sun.security.ssl as DHasKEM.java
>  - Update names to uppercase
>  - Remove fallback in engineGeneratePublic
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/7e91d34f...9c362c3e

src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 731:

> 729:                         nps.getName() : null;
> 730:                 return algName != null && constraints.permits(
> 731:                         EnumSet.of(CryptoPrimitive.KEY_AGREEMENT),

Should this be `KEY_ENCAPSULATION`? How did we test this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2593205603

From mullan at openjdk.org  Fri Dec  5 16:25:45 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 5 Dec 2025 16:25:45 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <mLWA4LyCRIfu9SZ5Nts-MY_5ck86e_9VbHPrIfeSVvM=.821020c4-a3df-4f41-93b5-2d9ba706cdcf@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <ygDE87sA6c4qIkX65GviP1qfh42xjIQ3NBm_o2GFmLk=.791c1ed5-861b-4bfc-b025-3fc1ac3e0124@github.com>
 <Xb9mk6G5X5ZXJ9n_H2oa00XkdKGf4E_ZZlN72IWaDz8=.edaebca0-0cbd-401d-b8b4-8cd3cc84a18a@github.com>
 <mLWA4LyCRIfu9SZ5Nts-MY_5ck86e_9VbHPrIfeSVvM=.821020c4-a3df-4f41-93b5-2d9ba706cdcf@github.com>
Message-ID: <u5gHqRAU6ulLMiROlboPannyD2rfFjB5BKpGNlT7pL0=.879ab01c-4ef2-42ac-bd9b-b7dbffc27806@github.com>

On Wed, 3 Dec 2025 22:17:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> No, we have a break at line #606 for this.
>
> But at this point we have created a KeyShare, why continue further through the loop?

NM, missed the `break` on line 605.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2593241177

From hchao at openjdk.org  Fri Dec  5 16:37:04 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 5 Dec 2025 16:37:04 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

 - Updates with Weijun's comments
 - Comments added for possession creation per handshake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/9c362c3e..0c938073

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=12-13

  Stats: 50 lines in 5 files changed: 29 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From hchao at openjdk.org  Fri Dec  5 16:37:09 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 5 Dec 2025 16:37:09 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v11]
In-Reply-To: <0mcEyqh5bZ_RKhpaahdPDlrCx1AkXIAfNuAInnzdWLI=.55b615b2-50a8-484f-a459-c175c2fc90e9@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>
 <0mcEyqh5bZ_RKhpaahdPDlrCx1AkXIAfNuAInnzdWLI=.55b615b2-50a8-484f-a459-c175c2fc90e9@github.com>
Message-ID: <BPZE2nv3Dt2mK4cO19n-96Z8-IWhJ6AJ2T_4FfavXjY=.f260ca87-576d-47f2-919d-a917d2d47085@github.com>

On Thu, 4 Dec 2025 14:50:32 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:
>> 
>>   Remove null check to not assume key is returned
>
> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 459:
> 
>> 457: 
>> 458:         static boolean isXDH(String name) {
>> 459:             return name != null && name.equals("X25519");
> 
> Can `name` in the two methods above be null? This might be hiding a bug.
> 
> Also, I think it's not worth putting them into a separate class `APS`.

Removed class `APS` (and checking null name).

> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 184:
> 
>> 182:                     KEM.getInstance(algorithmName, provider) :
>> 183:                     KEM.getInstance(algorithmName);
>> 184:             KEM.Encapsulator e = kem.newEncapsulator(pk);
> 
> `newEncapsulator` is called without an `SecureRandom` argument. Is this intended? Otherwise, we had a chance to pass in a user-provided random when `KEMSenderPossession` is created and it can be passed here.

Fixed. Creating a `KEMSenderPossession` should have started with a `SecureRandom`.

> src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java line 116:
> 
>> 114:         private final PublicKey publicKey;
>> 115: 
>> 116:         KEMReceiverPossession(NamedGroup namedGroup, SecureRandom random) {
> 
> `random` is ignored. Is this intended?

Fixed. `random` should be used in `kpg.initialize()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2593270703
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2593271507
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2593271045

From duke at openjdk.org  Fri Dec  5 16:49:51 2025
From: duke at openjdk.org (Neha Joshi)
Date: Fri, 5 Dec 2025 16:49:51 GMT
Subject: Integrated: 8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate
 jvm flags
In-Reply-To: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
References: <5IYGSWmVj8Z-HvDNc4TIZJb4_asQYK9wG_FzEPIqemQ=.b9b70998-67fe-4780-9245-459637995096@github.com>
Message-ID: <uG6wKWU8OL9p2nsPschpWHKVuPppH6ypbS-v9qFwhjY=.b533538d-e655-4440-9e5f-c8e6a1660537@github.com>

On Thu, 20 Nov 2025 13:05:44 GMT, Neha Joshi <duke at openjdk.org> wrote:

> In this PR we have updated the code to remove the duplicate call and ensure JVM flags are added only once.
> 
> ### ISSUE :- 
> In the test case --> ProcessTools.createTestJavaProcessBuilder(Utils.addTestJavaOpts("SSLEngineKeyLimit", "p", args[1], args[2]));
>     
> -> Before executing ProcessTools.createTestJavaProcessBuilder() we are calling  ---> Utils.addTestJavaOpts() which internally call prependTestJavaOpts();
> 
>>   public static String[] addTestJavaOpts(String... userArgs) {
>>         return prependTestJavaOpts(userArgs);
>>     }
> 
> -> Then again inside ProcessTools.createTestJavaProcessBuilder() method we are calling Utils.prependTestJavaOpts()
> 
>> public static ProcessBuilder createTestJavaProcessBuilder(String... command) {
>>         return createJavaProcessBuilder(Utils.prependTestJavaOpts(command));
>>     }
> 
> 
> Calling Utils.prependTestJavaOpts() twice leads to duplicate JVM flags (This method call-> getTestJavaOpts() the main reason for duplication and below is the implementation for the same. )
> 
>> public static String[] getTestJavaOpts() {
>>         List<String> opts = new ArrayList<String>();
>>         Collections.addAll(opts, safeSplitString(VM_OPTIONS));
>>         Collections.addAll(opts, safeSplitString(JAVA_OPTIONS));
>>         return opts.toArray(new String[0]);
>>     }
> 
> Contributed-by: @Korov 
> https://github.com/openjdk/jdk/pull/26404
> 
> https://bugs.openjdk.org/browse/JDK-8362658

This pull request has now been integrated.

Changeset: 520c092a
Author:    Neha Joshi <neha.j.joshi at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/520c092a658559a5d65f06a51061db3aae09931e
Stats:     36 lines in 8 files changed: 0 ins; 29 del; 7 mod

8362658: sun/security/ssl/SSLEngineImpl/* tests duplicate jvm flags

Co-authored-by: Lei Zhu <korov9.c at gmail.com>
Reviewed-by: myankelevich, rhalade

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

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

From rhalade at openjdk.org  Fri Dec  5 16:51:41 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 5 Dec 2025 16:51:41 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap [v4]
In-Reply-To: <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
 <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
Message-ID: <H06l7Rj0HIi-7ga-k_9BynKTimm6DGy9DX89EVHq6-M=.6c882b0c-67a4-4820-8183-8b46cda0d1d4@github.com>

On Fri, 5 Dec 2025 12:24:37 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases. 
>> 
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Formatting issue resolved.

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27847#pullrequestreview-3545563837

From abarashev at openjdk.org  Fri Dec  5 17:00:18 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 5 Dec 2025 17:00:18 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v4]
In-Reply-To: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
Message-ID: <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>

> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.

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

  Only the last few sentences of javadoc are outdated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28275/files
  - new: https://git.openjdk.org/jdk/pull/28275/files/0cabd3c4..f9233a75

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

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

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

From abarashev at openjdk.org  Fri Dec  5 17:00:20 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 5 Dec 2025 17:00:20 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v4]
In-Reply-To: <jp-V1LMyBXVcsIdkKula43BZOuoEzcT7Gnv0k61InpM=.cf9aa76a-48fe-400d-9926-1b90b0e63245@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <gts4SYkcbfDLFF3hTv449tZTu7pmjdI0hrhYcVNhS8I=.32c3ee5d-f4fd-4e69-ac53-b54af7fb2764@github.com>
 <jp-V1LMyBXVcsIdkKula43BZOuoEzcT7Gnv0k61InpM=.cf9aa76a-48fe-400d-9926-1b90b0e63245@github.com>
Message-ID: <8f6-Eh0viJNzGUEhhX4-kVelv3YFSpdsYFuVVl3hCac=.9bbea9d3-d0c7-4113-9ab3-8ac48f8b93df@github.com>

On Thu, 4 Dec 2025 21:20:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only the last few sentences of javadoc are outdated
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 41:
> 
>> 39: import sun.security.validator.*;
>> 40: 
>> 41: /**
> 
> It seems only the last few sentences are outdated. Also, although we don't use `@author` labels anymore, we typically leave existing ones in place.

Indeed, I made the changes, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2593331502

From weijun at openjdk.org  Fri Dec  5 18:22:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 Dec 2025 18:22:06 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
Message-ID: <tk62MY9VmZukmCi8oECEZLNnEsfhy03-e_ujHAFrdvw=.a12bb169-fa90-4e4e-8d0a-bf75e327f3c5@github.com>

On Fri, 5 Dec 2025 16:37:04 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates with Weijun's comments
>  - Comments added for possession creation per handshake

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 143:

> 141: 
> 142:         @Override
> 143:         public void initialize(AlgorithmParameterSpec params,

Since you initialize here, is it still necessary to init inside the constructor?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2593546269

From fferrari at openjdk.org  Fri Dec  5 20:12:00 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 5 Dec 2025 20:12:00 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
Message-ID: <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>

On Thu, 4 Dec 2025 17:32:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hi @wangweij, indeed is a fair and interesting point of view!
>> 
>> I like the idea of not doing any resolution at all to get rid of the possible problems. But let me do a similar test with some other programs supporting include directives in their configuration files (such as [OpenSSL](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Other%20files%20can,ignore%20the%20include%2e), [OpenSSH](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=it%2e-,Include,inclusion%2e), [Git](https://git-scm.com/docs/git-config#_includes) and [Apache HTTP Server](https://httpd.apache.org/docs/2.4/mod/core.html#include)), to collect more real world examples (beyond C includes which you already tested).
>> 
>> Regarding the backward compatibility, this is not the main use case, and if we could back-port that to 25 in the future, we would get the same behavior in all the supported JDKs shipping [JDK-8319332](https://bugs.openjdk.org/browse/JDK-8319332 "Security properties files inclusion") (as 24 reached end of support).
>> 
>> Would you think that such a change requires a CSR? If that's the case I would support the change but in a separate enhancement, so we can get this bug fixed in 26.
>
> Yes, it's good to see how this behaves on other programs, especially in configuration files. I know `krb5.conf` also supports it but it requires the included file having an absolute path.
> 
>> Would you think that such a change requires a CSR?
> 
> Maybe not. I see nowhere in its description in `java.security` talking about relative path resolution, so you have no specification to update.
> 
> A release note is enough, IMO.

Git behaves as C, it doesn't resolve symlinks:


# Backup user's config and prepare git config files
mv ~/.gitconfig{,.bak}

cat >/tmp/main.config <<'EOF'
[include]
	path = included.config
EOF

cat >/tmp/included.config <<'EOF'
[section]
	key = "/tmp/included.config was included"
EOF

cat >~/included.config <<'EOF'
[section]
	key = "~/included.config was included"
EOF

# Link ~/.gitconfig -> /tmp/main.config
ln -s /tmp/main.config ~/.gitconfig

# Check which file is included (ensure CWD is anything else)
git -C / config section.key

# Cleanup and restore user's config
rm ~/.gitconfig ~/included.config /tmp/included.config /tmp/main.config
mv ~/.gitconfig{.bak,}


Output:

~/included.config was included

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2593849381

From fferrari at openjdk.org  Fri Dec  5 20:17:00 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 5 Dec 2025 20:17:00 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
Message-ID: <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>

On Fri, 5 Dec 2025 20:09:22 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Yes, it's good to see how this behaves on other programs, especially in configuration files. I know `krb5.conf` also supports it but it requires the included file having an absolute path.
>> 
>>> Would you think that such a change requires a CSR?
>> 
>> Maybe not. I see nowhere in its description in `java.security` talking about relative path resolution, so you have no specification to update.
>> 
>> A release note is enough, IMO.
>
> Git behaves as C, it doesn't resolve symlinks:
> 
> 
> # Backup user's config and prepare git config files
> mv ~/.gitconfig{,.bak}
> 
> cat >/tmp/main.config <<'EOF'
> [include]
> 	path = included.config
> EOF
> 
> cat >/tmp/included.config <<'EOF'
> [section]
> 	key = "/tmp/included.config was included"
> EOF
> 
> cat >~/included.config <<'EOF'
> [section]
> 	key = "~/included.config was included"
> EOF
> 
> # Link ~/.gitconfig -> /tmp/main.config
> ln -s /tmp/main.config ~/.gitconfig
> 
> # Check which file is included (ensure CWD is anything else)
> git -C / config section.key
> 
> # Cleanup and restore user's config
> rm ~/.gitconfig ~/included.config /tmp/included.config /tmp/main.config
> mv ~/.gitconfig{.bak,}
> 
> 
> Output:
> 
> ~/included.config was included

OpenSSL deals with relative paths differently, [they resolve against the application's CWD](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Relative%20paths,as%20expected%2e):
> Relative paths are evaluated based on the application current working directory so unless the configuration file containing the `.include` directive is application specific the inclusion will not work as expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2593860774

From fferrari at openjdk.org  Fri Dec  5 20:33:08 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 5 Dec 2025 20:33:08 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
Message-ID: <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>

On Fri, 5 Dec 2025 20:14:25 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Git behaves as C, it doesn't resolve symlinks:
>> 
>> 
>> # Backup user's config and prepare git config files
>> mv ~/.gitconfig{,.bak}
>> 
>> cat >/tmp/main.config <<'EOF'
>> [include]
>> 	path = included.config
>> EOF
>> 
>> cat >/tmp/included.config <<'EOF'
>> [section]
>> 	key = "/tmp/included.config was included"
>> EOF
>> 
>> cat >~/included.config <<'EOF'
>> [section]
>> 	key = "~/included.config was included"
>> EOF
>> 
>> # Link ~/.gitconfig -> /tmp/main.config
>> ln -s /tmp/main.config ~/.gitconfig
>> 
>> # Check which file is included (ensure CWD is anything else)
>> git -C / config section.key
>> 
>> # Cleanup and restore user's config
>> rm ~/.gitconfig ~/included.config /tmp/included.config /tmp/main.config
>> mv ~/.gitconfig{.bak,}
>> 
>> 
>> Output:
>> 
>> ~/included.config was included
>
> OpenSSL deals with relative paths differently, [they resolve against the application's CWD](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Relative%20paths,as%20expected%2e):
>> Relative paths are evaluated based on the application current working directory so unless the configuration file containing the `.include` directive is application specific the inclusion will not work as expected.

OpenSSH [defines to possible base paths for relative `Include` keywords](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=Files%20without%20absolute%20paths,system%20configuration%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20file%2e):
> Files without absolute paths are assumed to be in `~/.ssh` if included in a user configuration file or `/etc/ssh` if included from the system configuration file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2593913876

From fferrari at openjdk.org  Fri Dec  5 20:40:05 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 5 Dec 2025 20:40:05 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
Message-ID: <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>

On Fri, 5 Dec 2025 20:30:36 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> OpenSSL deals with relative paths differently, [they resolve against the application's CWD](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Relative%20paths,as%20expected%2e):
>>> Relative paths are evaluated based on the application current working directory so unless the configuration file containing the `.include` directive is application specific the inclusion will not work as expected.
>
> OpenSSH [defines to possible base paths for relative `Include` keywords](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=Files%20without%20absolute%20paths,system%20configuration%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20file%2e):
>> Files without absolute paths are assumed to be in `~/.ssh` if included in a user configuration file or `/etc/ssh` if included from the system configuration file.

Apache HTTP Server [resolves against the defined `ServerRoot` directory](https://httpd.apache.org/docs/current/mod/core.html#include:~:text=Or%2C%20providing%20paths,conf/vhosts/*.conf):
> Or, providing paths relative to your [`ServerRoot`](https://httpd.apache.org/docs/current/mod/core.html#serverroot) directory:
>
>     Include conf/ssl.conf
>     Include conf/vhosts/*.conf

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2593927994

From duke at openjdk.org  Fri Dec  5 22:07:18 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 5 Dec 2025 22:07:18 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v4]
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <wsn7q-tq53R35mHUvRC9imJ6ZuF-u3KMX_vi2POxnpc=.8c2a4b1c-4547-43c3-94a8-be88b0f6d195@github.com>

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8370688: Addressed review comments-removed this method in the return label

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28615/files
  - new: https://git.openjdk.org/jdk/pull/28615/files/d53fe8ff..cc77e339

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

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

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

From mcimadamore at openjdk.org  Fri Dec  5 22:25:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Dec 2025 22:25:56 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <Uagao4pRdbSEELHfvD4OyFwyhG8dVcCSqk3lkAbCeaQ=.c9c9aaa1-d740-4a59-aa90-49078d6051d6@github.com>
Message-ID: <tcRe3vpWOR3SEBw7JnShHNNiNVE8Bcc2r4tMlJGDpUo=.081671ae-b992-433f-9adf-09a8b0cac6d6@github.com>

On Thu, 4 Dec 2025 16:22:08 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3618818702

From fferrari at openjdk.org  Fri Dec  5 22:26:53 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 5 Dec 2025 22:26:53 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v15]
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: <nOIh2iPCBHRJZolAI5icNCItWy67nBnR2yxu584bZiI=.dfbe24a6-f770-4ee0-921d-3bd5479d8c4a@github.com>

> Hi, this is a proposal to fix [JDK-8352728](https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions").
> 
> Path resolution with `Path::toRealPath` fails under the following conditions:
> 
> * When there is a restricted [_ACL_](https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) in a parent directory (_Windows_)
> * When dealing with an anonymous file only accesible through the _procfs_, such as `/proc/<pid>/fd/<fd>` (_Linux_)
>     * Such a file can be created by a pipe, deleting an opened file, or with the [`memfd_create` _Linux_ API](https://man7.org/linux/man-pages/man2/memfd_create.2.html)
> 
> Original code from [JDK-8319332: Security properties files inclusion](https://bugs.openjdk.org/browse/JDK-8319332) unconditionally resolves with `Path::toRealPath` all the processed properties files. This PR avoids resolving the paths unless strictly necessary: when determining the base path to compute a relative `include` directive. Cyclic includes detection is now performed with the unresolved paths and `Files::isSameFile`, so `activePaths` no longer needs to be a `Set`.
> 
> #### Still unsupported use-case
> 
> In _Linux_, a relative `include` from an anonymous file referenced as `/proc/<pid>/fd/<fd>` makes little sense.
> 
> However, in _Windows_, a relative `include` from a file where any of the parent directories has a restricted _ACL_ will be expected to work. It's important to note that such a restricted directory permissions scenario occurs to every [_UWP_](https://learn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) app (see [JDK-8369741](https://bugs.openjdk.org/browse/JDK-8369741 "cannot use java.security inside of UWP apps")).
> 
> When computing a relative `include`, we perform symlinks resolution of the parent file under the rationale that the person writing the original properties file is the one who decides where the relative includes should resolve. In the absence of a recommended way or API to deal with resolution under this restricted directory permissions scenario, this use-case is left unsupported. This compromise-solution is better than the current status of _UWP_ apps, where simply loading the `java.security.Security` class breaks the JVM initialization by a failed attempt to resolve the `java.security` path (not from an `include` statement, nor a relative path).
> 
> <details>
> <summary>Previous approach and <code>File::getCanonicalPath</code> vs ...

Francisco Ferrari Bihurriet has updated the pull request incrementally with four additional commits since the last revision:

 - 3/3) Adjust ConfigFileTest for unresolved paths
 - 2/3) Refactor ConfigFileTest ExtraMode enum
   
   Move ExtraMode as an ExtraPropsFile field, so we have this information
   as soon as the ExtraPropsFile is created. This will be useful for the
   next change.
 - 1/3) Revert ConfigFileTest adjustment
   
   This reverts commit 7c80874c25bc99783ad24fb22d2c080d33c5503a only for
   ConfigFileTest.
 - Do not resolve symlinks for relative includes
   
   As @wangweij pointed out:
   > The person writing the original properties file may have expected
   > includes to resolve relative to its own location, but whoever created
   > the symlink may have intended a different resolution path. If they
   > wanted the original location, they could have just used the real file
   > directly instead of introducing a symlink.
   
   Since path resolution is causing trouble under certain conditions, let's
   avoid doing it. Other programs with include directives support in their
   configuration files are doing the same.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24465/files
  - new: https://git.openjdk.org/jdk/pull/24465/files/51a3ce86..c33bf62c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=13-14

  Stats: 105 lines in 2 files changed: 28 ins; 31 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/24465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24465/head:pull/24465

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

From fferrari at openjdk.org  Fri Dec  5 22:37:00 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Fri, 5 Dec 2025 22:37:00 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
 <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
Message-ID: <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>

On Fri, 5 Dec 2025 20:37:14 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> OpenSSH [defines to possible base paths for relative `Include` keywords](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=Files%20without%20absolute%20paths,system%20configuration%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20file%2e):
>>> Files without absolute paths are assumed to be in `~/.ssh` if included in a user configuration file or `/etc/ssh` if included from the system configuration file.
>
> Apache HTTP Server [resolves against the defined `ServerRoot` directory](https://httpd.apache.org/docs/current/mod/core.html#include:~:text=Or%2C%20providing%20paths,conf/vhosts/*.conf):
>> Or, providing paths relative to your [`ServerRoot`](https://httpd.apache.org/docs/current/mod/core.html#serverroot) directory:
>>
>>     Include conf/ssl.conf
>>     Include conf/vhosts/*.conf

I have pushed the changes to proceed without resolution (9f298af59431507a66e3141c54abb59fcf3666f6, 2a012397baf0599e7dbe209975b3b353c3de5617, 1178544bda12bb4a6cd4d4400dad618292f29151, c33bf62c2831acefd90ec476fcfb6d853be873ee).

Since we are no longer resolving paths, we can incur in some relative paths complexity, which is perhaps not very friendly in debug message logs. Each relative include can potentially introduce some `../`, which will accumulate if paths are not resolved.

So we can end with paths like the following one:

/basedir/jdk/conf/security/../../../properties/dir1/../../jdk/conf/security/other.properties


Which could be simply logged as:

/basedir/jdk/conf/security/other.properties


So even when I already adjusted the test case, is perhaps better to undo the test changes and try to beautify the paths in debugging messages (but with `LinkOption.NOFOLLOW_LINKS`, to avoid confusion):

diff --git a/src/java.base/share/classes/java/security/Security.java b/src/java.base/share/classes/java/security/Security.java
index 36021f42862..533072b0d08 100644
--- a/src/java.base/share/classes/java/security/Security.java
+++ b/src/java.base/share/classes/java/security/Security.java
@@ -311,8 +311,13 @@ private static void loadFromUrl(URL url, LoadingMode mode)
         private static void debugLoad(boolean start, Object source) {
             if (sdebug != null) {
+                if (source instanceof Path path) {
+                    try {
+                        source = path.toRealPath(LinkOption.NOFOLLOW_LINKS);
+                    } catch (IOException ignore) {}
+                }
                 int level = activePaths.isEmpty() ? 1 : activePaths.size();
                 sdebug.println((start ?
                         ">".repeat(level) + " starting to process " :
                         "<".repeat(level) + " finished processing ") + source);
             }
         }



NOTE: even with `LinkOption.NOFOLLOW_LINKS`, `path.toRealPath()` fails for the problematic cases, so it would be just a best effort to make the paths clearer for the user.

What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2594151432

From hchao at openjdk.org  Sat Dec  6 06:12:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 6 Dec 2025 06:12:57 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v15]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <puUkLM3iebFI1XUgk6JD-_vBkLrepNl-f9zBLlf1p-8=.87a8b2d5-6ea9-4977-9c9b-0372988c241b@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

 - Updates with Brad's and Sean's comments for new HybridProvider class
 - Updates with Weijun's comments for 3rd-party provider

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/0c938073..a6f56d75

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=13-14

  Stats: 196 lines in 4 files changed: 105 ins; 83 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From hchao at openjdk.org  Sat Dec  6 06:12:59 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 6 Dec 2025 06:12:59 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <hQGeRqaqA6UlG-iKFwrTX6vecKUzTXxVDBGs8CBazCI=.52986351-e8e3-4dab-a8cd-008e54b2a640@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <Y7azUkWEoruKxpinhEeiOQ8MH8u9Dz-AyCy_JvgbwkI=.49efad6e-1d35-4721-b5dc-d73ff240dc1d@github.com>
 <hQGeRqaqA6UlG-iKFwrTX6vecKUzTXxVDBGs8CBazCI=.52986351-e8e3-4dab-a8cd-008e54b2a640@github.com>
Message-ID: <bMoZe4TykxOmRHgPTuY1UF_wWz_4zsXsN56Z2JLn_bk=.abace6bd-dfaf-4736-9d61-6bc7fdbe5c6f@github.com>

On Mon, 1 Dec 2025 21:47:29 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 66:
>> 
>>> 64:  * KEMs.
>>> 65:  */
>>> 66: public class DH implements KEMSpi {
>> 
>> This class includes more than a DH KEM wrapper implementation. The provider is registering all the hybrid algorithms, including the ML-KEM parts. It feels odd to be hiding the provider inside this class. I suggest creating a separate `HybridProvider` class that is in `sun.security.ssl` package and either encapsulating the DH impl inside that, or better yet, create a separate class for it.
>
> Agreed.

Created a new `HybridProvider` class as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594591729

From hchao at openjdk.org  Sat Dec  6 06:13:02 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 6 Dec 2025 06:13:02 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v11]
In-Reply-To: <0HIiMXsclfM97MKJLcj4IyzzUaRBKuG5yTfu7OEcu0g=.5dc9d357-f4ae-4859-8bfe-990c8f94e0b7@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>
 <0HIiMXsclfM97MKJLcj4IyzzUaRBKuG5yTfu7OEcu0g=.5dc9d357-f4ae-4859-8bfe-990c8f94e0b7@github.com>
Message-ID: <xFTRNb0xApwTs-3CtS07FSvr8oKrxGQHFncqUyy2jWw=.69eb3274-9200-41ea-9420-9e14b206a758@github.com>

On Thu, 4 Dec 2025 14:00:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove null check to not assume key is returned
>
> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 79:
> 
>> 77:     // It registers Hybrid KeyPairGenerator, KeyFactory, and KEM
>> 78:     // implementations for hybrid named groups as Provider services.
>> 79:     private static class ProviderImpl extends Provider {
> 
> This provider is not DH specific so doesn't fit right with being in this class. Move this `Provider` out into a separate class and call it `HybridProvider`, or alternatively put it inside the `Hybrid` class (so it would be `Hybrid.ProviderImpl`.) I know it also contains DHasKEM, which is not hybrid, but that is the only case, so I still think Hybrid is a suitable name, with a comment explaining there is one exception.

Done.

> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 83:
> 
>> 81:         private static final long serialVersionUID = 0L;
>> 82:         private ProviderImpl() {
>> 83:             super("InternalJCEDHasKEM", PROVIDER_VER,
> 
> This provider supports more than DH, so suggest calling this "HybridAndDHAsKEM" or something like that.

Changed as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594591920
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594592030

From hchao at openjdk.org  Sat Dec  6 07:24:10 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 6 Dec 2025 07:24:10 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <tk62MY9VmZukmCi8oECEZLNnEsfhy03-e_ujHAFrdvw=.a12bb169-fa90-4e4e-8d0a-bf75e327f3c5@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <tk62MY9VmZukmCi8oECEZLNnEsfhy03-e_ujHAFrdvw=.a12bb169-fa90-4e4e-8d0a-bf75e327f3c5@github.com>
Message-ID: <bC9QypOs53ezV2qmLSFfQ9ODNdaKBuArbcx5Js2cJUQ=.8f631d95-aea6-4ad4-b189-b045e75b5357@github.com>

On Fri, 5 Dec 2025 18:19:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updates with Weijun's comments
>>  - Comments added for possession creation per handshake
>
> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 143:
> 
>> 141: 
>> 142:         @Override
>> 143:         public void initialize(AlgorithmParameterSpec params,
> 
> Since you initialize here, is it still necessary to init inside the constructor?

No, so removed init from the constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594592250

From hchao at openjdk.org  Sat Dec  6 07:24:15 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 6 Dec 2025 07:24:15 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v13]
In-Reply-To: <I9-6-_eX9_sSPELp6Clt1tiwkr2-NJ7fgdO-Su4xs4Q=.d45d5a0a-1434-4745-b511-0cf93e5118af@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <BVcSY03gYWzvnGa1dun-Z30NwjZE4xQajljY0PRBHHs=.8d3f3dfc-1da5-456a-a357-f95f8ff22cb3@github.com>
 <I9-6-_eX9_sSPELp6Clt1tiwkr2-NJ7fgdO-Su4xs4Q=.d45d5a0a-1434-4745-b511-0cf93e5118af@github.com>
Message-ID: <ZWyMExoj3Icz2VK_7ghBZMDQm4UJS8vgryhPox8eauo=.cae28ca7-a81c-4464-a30a-ed9709859666@github.com>

On Fri, 5 Dec 2025 16:10:08 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 pull request now contains 27 commits:
>> 
>>  - reapply changes after merge
>>  - Merge
>>  - backout conflict change in KeyShareExtension.java
>>  - Updates with Weijun's comments
>>  - Remove null check to not assume key is returned
>>  - Updates with Brad's and Sean's comments
>>  - Move Hybrid.java to sun.security.ssl
>>  - Move DH.java to sun.security.ssl as DHasKEM.java
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/7e91d34f...9c362c3e
>
> src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 731:
> 
>> 729:                         nps.getName() : null;
>> 730:                 return algName != null && constraints.permits(
>> 731:                         EnumSet.of(CryptoPrimitive.KEY_AGREEMENT),
> 
> Should this be `KEY_ENCAPSULATION`? How did we test this?

`KEY_ENCAPSULATION` is defined for the X.509 keyUsage extension for `keyEncipherment` (not for TLS key exchange). To test disabling a specific algorithm in JSSE, we can use the `jdk.tls.disabledAlgorithms` security property. We have a test `RestrictNamedGroup.java` that uses this property to verify algorithm constraints for TLS. We updated this test to include coverage for hybrid algorithms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594592105

From wetmore at openjdk.org  Sat Dec  6 07:39:08 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 6 Dec 2025 07:39:08 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v15]
In-Reply-To: <puUkLM3iebFI1XUgk6JD-_vBkLrepNl-f9zBLlf1p-8=.87a8b2d5-6ea9-4977-9c9b-0372988c241b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <puUkLM3iebFI1XUgk6JD-_vBkLrepNl-f9zBLlf1p-8=.87a8b2d5-6ea9-4977-9c9b-0372988c241b@github.com>
Message-ID: <DzPuLjfV5H8a4rQnBA6gEWfGBLHwq2PUWWKX8Y_Ow_E=.c6d96b64-af3a-49ae-aaba-0eb9ea13b247@github.com>

On Sat, 6 Dec 2025 06:12:57 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates with Brad's and Sean's comments for new HybridProvider class
>  - Updates with Weijun's comments for 3rd-party provider

I know we haven't been consistent in the visibility of the internal JSSE classes (and members therein), but many (all?) of the new classes (including nested classes:  e.g. Hybrid.*) could be package-private/final (or even private) instead of public.

I'm not suggesting going through and doing an overhaul of the `sun.security.ssl` package, just the new ones.  

Also, you changed the files while I was reviewing, so some of my comments may have been lost.  I can't seem to find them in the "pending" state.  Hopefully they will show up in the comments here.

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

PR Review: https://git.openjdk.org/jdk/pull/27614#pullrequestreview-3547078547

From wetmore at openjdk.org  Sat Dec  6 07:39:10 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 6 Dec 2025 07:39:10 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v11]
In-Reply-To: <0HIiMXsclfM97MKJLcj4IyzzUaRBKuG5yTfu7OEcu0g=.5dc9d357-f4ae-4859-8bfe-990c8f94e0b7@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <nMbeND7z1U1NlOWbws03eoEuI9vKSMugVOlxOy7WnbY=.9875f160-1f61-4238-b89b-50670099772a@github.com>
 <0HIiMXsclfM97MKJLcj4IyzzUaRBKuG5yTfu7OEcu0g=.5dc9d357-f4ae-4859-8bfe-990c8f94e0b7@github.com>
Message-ID: <eizEdsaPmsFfD9Dq9d2644tjSsboNrUMTZ4LYWTJGok=.6855fd2e-843b-4571-9450-116ce87ae410@github.com>

On Thu, 4 Dec 2025 14:00:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove null check to not assume key is returned
>
> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 79:
> 
>> 77:     // It registers Hybrid KeyPairGenerator, KeyFactory, and KEM
>> 78:     // implementations for hybrid named groups as Provider services.
>> 79:     private static class ProviderImpl extends Provider {
> 
> This provider is not DH specific so doesn't fit right with being in this class. Move this `Provider` out into a separate class and call it `HybridProvider`, or alternatively put it inside the `Hybrid` class (so it would be `Hybrid.ProviderImpl`.) I know it also contains DHasKEM, which is not hybrid, but that is the only case, so I still think Hybrid is a suitable name, with a comment explaining there is one exception.

Ditto.

> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 83:
> 
>> 81:         private static final long serialVersionUID = 0L;
>> 82:         private ProviderImpl() {
>> 83:             super("InternalJCEDHasKEM", PROVIDER_VER,
> 
> This provider supports more than DH, so suggest calling this "HybridAndDHAsKEM" or something like that.

I like this name suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594528909
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594529563

From wetmore at openjdk.org  Sat Dec  6 07:39:19 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 6 Dec 2025 07:39:19 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
Message-ID: <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>

On Fri, 5 Dec 2025 16:37:04 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates with Weijun's comments
>  - Comments added for possession creation per handshake

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 91:

> 89:             // The order of shares in the concatenation for group name
> 90:             // X25519MLKEM768 has been reversed. This is due to IETF
> 91:             // historical reasons.

Can we just change this to something like "as per the current draft RFC?"  

"historical reasons" is too vague.  The draft is the real reason.

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 152:

> 150:     }
> 151: 
> 152:     static final class Handler

private?

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 261:

> 259: 
> 260:         X448(56, 56,
> 261:                 "XDH", "XDH", NamedParameterSpec.X448),

unneeded comma, move the semicolon below to the end of this "XDH" line (currently line 261).

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 268:

> 266:         private final String keyAlgorithm;
> 267:         private final AlgorithmParameterSpec spec;
> 268: 

nit:  extra line?

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 331:

> 329:     }
> 330: 
> 331:     private static class HybridService extends Provider.Service {

Reminder: this would also be moved to the new Provider file....

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 61:

> 59:  * in a single TLS hybrid named group.
> 60:  * It implements:
> 61:  *  - Hybrid KeyPair generation

This seems to be a mix of javadoc and markdown.  If anyone ever does generate javadocs for these internal classes, this will not render well.

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 319:

> 317:     }
> 318: 
> 319:     private static byte[] concat(byte[]... inputs) {

@wangweij did the following in `com.sun.crypto.provider.DHKEM.java` and `c.s.c.p.HPKE.java`:

    private static byte[] concat(byte[]... inputs) {
        ByteArrayOutputStream o = new ByteArrayOutputStream(); 
        Arrays.stream(inputs).forEach(o::writeBytes);
        return o.toByteArray();
    }

Since this is the third usage in the last couple years, maybe put this in a utility class instead and adjust the other instances?

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 314:

> 312:             try {
> 313:                 // Skip AlgorithmParameters for KEMs (not supported)
> 314:                 if (namedGroupSpec == NamedGroupSpec.NAMED_GROUP_KEM) {

Can you also put in a comment here as to why you're doing these `getInstances`.  

It looks like you're checking for the existence of the `KeyFactory`, but the exception logger only talks about `AlgorithmParameters`.

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 572:

> 570:             // model, depending on what key exchange group is used.
> 571:             //
> 572:             // In JSSE for KA flow, the server usually generates its key

Minor doc nit here.  For KA flows, the server first receives the client's share, THEN generates its key share.   Then we finally come here.   Just reverse the order and you should be good.

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 581:

> 579:             // Traditional Key Agreement (KA):
> 580:             //   - Both peers generate a key share and exchange it.
> 581:             //   - Each peer computes a shared secret upon receiving the

We currently do the share generation in the KeyShare extension, and calculate the shared secret here in ServerHello.  It's not immediate, but this suggests it is.  Maybe change:

upon receiving
->
sometime after receiving

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 585:

> 583:             //
> 584:             // Key Encapsulation Mechanism (KEM):
> 585:             //  The decapsulator (the client) publishes a public key, and

I would suggest rewording this to be something like:

   // Key Encapsulation Mechanism (KEM):
   //  The client push a public key via a KeyShareExtension, which 
   //  the server uses to:
   //
   //  - generate the shared secret
   //  - encapsulate the message which is sent to the client in another
   //     KeyShareExtension
   //
   // The derived shared secret must be stored in a KEMSenderPossession 
   // so it can be retrieved for handshake traffic secret derivation later.

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 635:

> 633: 
> 634:             if (handshakeSecret == null) {
> 635:                 SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);

Since we only end up with one possession, can we move this up into the for loop?  Each of the various possession types goes through the `for` loop, so seems this would be a tiny bit clearer.

    for () {
        if (pos instanceof ...) {
            handshakeSecret =...
        } else {
            SSLKeyDerivation handshakeKD = ...
        }
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594536917
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594576033
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594584547
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594584936
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594585786
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594587476
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594622712
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594471547
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594491151
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594492123
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594495875
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594508194

From wetmore at openjdk.org  Sat Dec  6 07:39:20 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 6 Dec 2025 07:39:20 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <bC9QypOs53ezV2qmLSFfQ9ODNdaKBuArbcx5Js2cJUQ=.8f631d95-aea6-4ad4-b189-b045e75b5357@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <tk62MY9VmZukmCi8oECEZLNnEsfhy03-e_ujHAFrdvw=.a12bb169-fa90-4e4e-8d0a-bf75e327f3c5@github.com>
 <bC9QypOs53ezV2qmLSFfQ9ODNdaKBuArbcx5Js2cJUQ=.8f631d95-aea6-4ad4-b189-b045e75b5357@github.com>
Message-ID: <7cOZuZUHk7Z8Hf8scDV5J-H_9RrMjFL13jld6QiiZW4=.20514d78-5bb1-4f73-af21-473fcb16f8e5@github.com>

On Sat, 6 Dec 2025 06:09:34 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 143:
>> 
>>> 141: 
>>> 142:         @Override
>>> 143:         public void initialize(AlgorithmParameterSpec params,
>> 
>> Since you initialize here, is it still necessary to init inside the constructor?
>
> No, so removed init from the constructor.

I was wondering the same thing.

I don't think it hurts anything, other than calling the initialization twice, but likely could be removed.  

The first call uses the `JCAUtil.getDefSecureRandom()` instead, but that is replaced with the real context `SecureRandom` when this method is called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594596953

From wetmore at openjdk.org  Sat Dec  6 07:54:12 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 6 Dec 2025 07:54:12 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v15]
In-Reply-To: <puUkLM3iebFI1XUgk6JD-_vBkLrepNl-f9zBLlf1p-8=.87a8b2d5-6ea9-4977-9c9b-0372988c241b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <puUkLM3iebFI1XUgk6JD-_vBkLrepNl-f9zBLlf1p-8=.87a8b2d5-6ea9-4977-9c9b-0372988c241b@github.com>
Message-ID: <Bmjb6rRcu2soPR1JFoj184avKihc0SwIpDed1Us5pMw=.715ba21d-8390-422b-928c-2f82bed3bbed@github.com>

On Sat, 6 Dec 2025 06:12:57 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates with Brad's and Sean's comments for new HybridProvider class
>  - Updates with Weijun's comments for 3rd-party provider

Comments on the change to HybridProvider.java

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 259:

> 257:     }
> 258: 
> 259:     public static class HybridService extends Provider.Service {

Shouldn't this be moved to `HybridProvider.java`?

src/java.base/share/classes/sun/security/ssl/HybridProvider.java line 57:

> 55:             // The order of shares in the concatenation for group name
> 56:             // X25519MLKEM768 has been reversed. This is due to IETF
> 57:             // historical reasons.

Can we change this to something like "as per the current draft RFC?"

"historical reasons" is too vague. The draft/RFC is the real reason.

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

PR Review: https://git.openjdk.org/jdk/pull/27614#pullrequestreview-3547269198
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594634717
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2594632217

From duke at openjdk.org  Sat Dec  6 13:02:56 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 6 Dec 2025 13:02:56 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <bRv8yWeVDg2jzpODllmKdUyYNv0gOncJMafGKRwAPk0=.06fdbd85-742c-4034-99cc-facc3ec753b6@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 89:

> 87:     @ForceInline
> 88:     private int getCounter() {
> 89:         return Thread.currentThread().hashCode() & mask;

Maybe use?[`System?::identityHashCode`] here?instead, as?the?`hashCode()`?method of?a?`Thread` can?be?overridden by?subclasses.
Suggestion:

        return System.identityHashCode(Thread.currentThread()) & mask;


[`System?::identityHashCode`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#identityHashCode%28java.lang.Object%29

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2594828923

From hchao at openjdk.org  Sat Dec  6 17:24:55 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 6 Dec 2025 17:24:55 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v16]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <CpGyh7gXRU6Cffym6qCN-xcGkHj9ldDvDBkgD1uWRfE=.900189be-02c3-41fb-a7d3-7e0c50440bfb@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  Updates with Brad's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/a6f56d75..7ef391be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=14-15

  Stats: 95 lines in 5 files changed: 30 ins; 28 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From hchao at openjdk.org  Sat Dec  6 17:24:59 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 6 Dec 2025 17:24:59 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v15]
In-Reply-To: <DzPuLjfV5H8a4rQnBA6gEWfGBLHwq2PUWWKX8Y_Ow_E=.c6d96b64-af3a-49ae-aaba-0eb9ea13b247@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <puUkLM3iebFI1XUgk6JD-_vBkLrepNl-f9zBLlf1p-8=.87a8b2d5-6ea9-4977-9c9b-0372988c241b@github.com>
 <DzPuLjfV5H8a4rQnBA6gEWfGBLHwq2PUWWKX8Y_Ow_E=.c6d96b64-af3a-49ae-aaba-0eb9ea13b247@github.com>
Message-ID: <AnKM8Fr3MVVQatgu5PfMkc4AQVjZ6TtZ9XUa_IPISLI=.79050298-55e6-4c86-abba-6b1d728716dc@github.com>

On Sat, 6 Dec 2025 07:36:16 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> I know we haven't been consistent in the visibility of the internal JSSE classes (and members therein), but many (all?) of the new classes (including nested classes: e.g. Hybrid.*) could be package-private/final (or even private) instead of public.
> 
> I'm not suggesting going through and doing an overhaul of the `sun.security.ssl` package, just the new ones.
> 
> Also, you changed the files while I was reviewing, so several of my comments are considered outdated. One still applies in the new location, so I'll readd it.

Went through the new files. Sorry for changing the files.

> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 259:
> 
>> 257:     }
>> 258: 
>> 259:     public static class HybridService extends Provider.Service {
> 
> Shouldn't this be moved to `HybridProvider.java`?

Yes, moved.

> src/java.base/share/classes/sun/security/ssl/HybridProvider.java line 57:
> 
>> 55:             // The order of shares in the concatenation for group name
>> 56:             // X25519MLKEM768 has been reversed. This is due to IETF
>> 57:             // historical reasons.
> 
> Can we change this to something like "as per the current draft RFC?"
> 
> "historical reasons" is too vague. The draft/RFC is the real reason.

Changed the comment as suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/27614#issuecomment-3620719989
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595151301
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595151228

From hchao at openjdk.org  Sat Dec  6 17:25:09 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 6 Dec 2025 17:25:09 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
Message-ID: <-pvm0ju7vE2PT7QUD5e3TdzTPe2IfbuPLOdTxEuVrcg=.6b803aa5-a54f-430f-814a-7a188f9e6a54@github.com>

On Sat, 6 Dec 2025 05:27:03 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updates with Weijun's comments
>>  - Comments added for possession creation per handshake
>
> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 91:
> 
>> 89:             // The order of shares in the concatenation for group name
>> 90:             // X25519MLKEM768 has been reversed. This is due to IETF
>> 91:             // historical reasons.
> 
> Can we just change this to something like "as per the current draft RFC?"  
> 
> "historical reasons" is too vague.  The draft is the real reason.

Updated comment as suggested (comment is in HybridProvider class now).

> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 152:
> 
>> 150:     }
>> 151: 
>> 152:     static final class Handler
> 
> private?

Yes, fixed.

> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 261:
> 
>> 259: 
>> 260:         X448(56, 56,
>> 261:                 "XDH", "XDH", NamedParameterSpec.X448),
> 
> unneeded comma, move the semicolon below to the end of this "XDH" line (currently line 261).

Removed.

> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 268:
> 
>> 266:         private final String keyAlgorithm;
>> 267:         private final AlgorithmParameterSpec spec;
>> 268: 
> 
> nit:  extra line?

Removed extra line.

> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 331:
> 
>> 329:     }
>> 330: 
>> 331:     private static class HybridService extends Provider.Service {
> 
> Reminder: this would also be moved to the new Provider file....

Moved to new HybridProvider file.

> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 61:
> 
>> 59:  * in a single TLS hybrid named group.
>> 60:  * It implements:
>> 61:  *  - Hybrid KeyPair generation
> 
> This seems to be a mix of javadoc and markdown.  If anyone ever does generate javadocs for these internal classes, this will not render well.

Fixed the comments.

> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 314:
> 
>> 312:             try {
>> 313:                 // Skip AlgorithmParameters for KEMs (not supported)
>> 314:                 if (namedGroupSpec == NamedGroupSpec.NAMED_GROUP_KEM) {
> 
> Can you also put in a comment here as to why you're doing these `getInstances`.  
> 
> It looks like you're checking for the existence of the `KeyFactory`, but the exception logger only talks about `AlgorithmParameters`.

Comment added.

> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 572:
> 
>> 570:             // model, depending on what key exchange group is used.
>> 571:             //
>> 572:             // In JSSE for KA flow, the server usually generates its key
> 
> Minor doc nit here.  For KA flows, the server first receives the client's share, THEN generates its key share.   Then we finally come here.   Just reverse the order and you should be good.

Updated the comment as suggested.

> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 581:
> 
>> 579:             // Traditional Key Agreement (KA):
>> 580:             //   - Both peers generate a key share and exchange it.
>> 581:             //   - Each peer computes a shared secret upon receiving the
> 
> We currently do the share generation in the KeyShare extension, and calculate the shared secret here in ServerHello.  It's not immediate, but this suggests it is.  Maybe change:
> 
> upon receiving
> ->
> sometime after receiving

Updated the comment as suggested..

> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 585:
> 
>> 583:             //
>> 584:             // Key Encapsulation Mechanism (KEM):
>> 585:             //  The decapsulator (the client) publishes a public key, and
> 
> I would suggest rewording this to be something like:
> 
>    // Key Encapsulation Mechanism (KEM):
>    //  The client push a public key via a KeyShareExtension, which 
>    //  the server uses to:
>    //
>    //  - generate the shared secret
>    //  - encapsulate the message which is sent to the client in another
>    //     KeyShareExtension
>    //
>    // The derived shared secret must be stored in a KEMSenderPossession 
>    // so it can be retrieved for handshake traffic secret derivation later.

Updated the comments as suggested.

> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 635:
> 
>> 633: 
>> 634:             if (handshakeSecret == null) {
>> 635:                 SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);
> 
> Since we only end up with one possession, can we move this up into the for loop?  Each of the various possession types goes through the `for` loop, so seems this would be a tiny bit clearer.
> 
>     for () {
>         if (pos instanceof ...) {
>             handshakeSecret =...
>         } else {
>             SSLKeyDerivation handshakeKD = ...
>         }
>     }

Keep the code as it is. This is because if we move the KA derivation code to the for loop as the else branch, we make it appear to be associated with a possession. KA does not store the shared secret in a possession like KEM, so keep its logic separate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150752
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150801
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150830
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150910
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595151002
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595151129
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150325
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150512
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150564
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150597
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595150633

From weijun at openjdk.org  Sat Dec  6 18:10:15 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 6 Dec 2025 18:10:15 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v16]
In-Reply-To: <CpGyh7gXRU6Cffym6qCN-xcGkHj9ldDvDBkgD1uWRfE=.900189be-02c3-41fb-a7d3-7e0c50440bfb@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <CpGyh7gXRU6Cffym6qCN-xcGkHj9ldDvDBkgD1uWRfE=.900189be-02c3-41fb-a7d3-7e0c50440bfb@github.com>
Message-ID: <25JbEkt3soa1Oz3gL86-DJd3M-cThSP0ti1FLIMi8zc=.be119be8-a314-459a-9ba0-98f0c13f2b80@github.com>

On Sat, 6 Dec 2025 17:24:55 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates with Brad's comments

src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 38:

> 36: import javax.crypto.KeyAgreement;
> 37: import javax.crypto.SecretKey;
> 38: import javax.crypto.spec.SecretKeySpec;

Useless import.

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 41:

> 39: import java.security.InvalidAlgorithmParameterException;
> 40: import java.security.InvalidKeyException;
> 41: import java.security.InvalidParameterException;

Useless import.

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 144:

> 142:                 throw new ProviderException("Failed to initialize hybrid " +
> 143:                         "keypair generator", e);
> 144:             }

No need to catch either of the exceptions.

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 363:

> 361:         @Override
> 362:         public SecretKey engineDecapsulate(byte[] encapsulation, int from,
> 363:                 int to, String algorithm) throws DecapsulateException {

You might want to check the length of `encapsulation`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595183964
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595195602
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595182671
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595203845

From hchao at openjdk.org  Sun Dec  7 00:23:34 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sun, 7 Dec 2025 00:23:34 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v17]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <28WmeoCnKTQ4muf-HeAIIXYQjB70cFb3JwDBp2YqVbw=.2c38b518-bd2d-4790-b4d9-afdb374abc42@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  Fix internal JSSE benchmarks to reflect new class location.  Address comments, adjust line lengths

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/7ef391be..30da7e01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=15-16

  Stats: 34 lines in 2 files changed: 14 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From jnimeh at openjdk.org  Sun Dec  7 00:28:11 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Sun, 7 Dec 2025 00:28:11 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <MnG7AzyQAl8GoAA9LJrb6cUPWQNd8G_A65_1p4xEyJc=.556f45c0-dc78-4bf9-a80b-6ae9d9c3470c@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <MnG7AzyQAl8GoAA9LJrb6cUPWQNd8G_A65_1p4xEyJc=.556f45c0-dc78-4bf9-a80b-6ae9d9c3470c@github.com>
Message-ID: <AbhkAIgl9zlpS-9_K9uvtacFoqjQqwDFI9KpkqwXI20=.524c395b-e367-45cc-a3e8-c7f40ae98737@github.com>

On Wed, 26 Nov 2025 15:59:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - Change default named group list to have only X25519MLKEM768
>
> test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java line 94:
> 
>> 92:     }
>> 93: 
>> 94:     protected static Provider getInternalJce() {
> 
> Can this just be private?

It sure can!  Done.

> test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java line 97:
> 
>> 95:         try {
>> 96:             Class<?> dhClazz = Class.forName("com.sun.crypto.provider.DH");
>> 97:             return (Provider) (dhClazz.getField("PROVIDER").get(null));
> 
> Nit: params around `dhClazz.getField("PROVIDER").get(null)` not necessary.

I assume you meant "parenthesis"?  If so I've removed the extra set.

> test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java line 120:
> 
>> 118: 
>> 119:     public static class MLKEM extends KEMBench {
>> 120:         @Param({"ML-KEM-512", "ML-KEM-768", "ML-KEM-1024" })
> 
> Not a JMH expert, but what is the difference between these parameters and the ones on line 48? It looks like a duplicate test to me.

It turns out this is a mistake.  By having both this line and 48 with the same algorithm names, the benchmark runs them twice.  Our benchmarks tend to be organized either with the main class as a baseline benchmark with subclasses for all other types, or an abstract base class with an empty @param tag and subclasses for each actual benchmark.  `KeyAgreementBench.java` is done that way, and I personally like that approach better and changed this class to follow that model.  Either way is just fine though.  The important thing is that if you have parameters in the parent class, it should not match any parameter sets in the child classes or you just end up running the same benchmark twice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595703134
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595703039
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595702480

From hchao at openjdk.org  Sun Dec  7 01:55:14 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sun, 7 Dec 2025 01:55:14 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v16]
In-Reply-To: <25JbEkt3soa1Oz3gL86-DJd3M-cThSP0ti1FLIMi8zc=.be119be8-a314-459a-9ba0-98f0c13f2b80@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <CpGyh7gXRU6Cffym6qCN-xcGkHj9ldDvDBkgD1uWRfE=.900189be-02c3-41fb-a7d3-7e0c50440bfb@github.com>
 <25JbEkt3soa1Oz3gL86-DJd3M-cThSP0ti1FLIMi8zc=.be119be8-a314-459a-9ba0-98f0c13f2b80@github.com>
Message-ID: <fQyjDFEE5uRZkdt1Wm_qFPrXeg49-k3SFJjRF9DiBB4=.02b36cb5-e80f-465a-8c83-204f4f8b5c81@github.com>

On Sat, 6 Dec 2025 17:39:06 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:
>> 
>>   Updates with Brad's comments
>
> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 38:
> 
>> 36: import javax.crypto.KeyAgreement;
>> 37: import javax.crypto.SecretKey;
>> 38: import javax.crypto.spec.SecretKeySpec;
> 
> Useless import.

Removed.

> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 41:
> 
>> 39: import java.security.InvalidAlgorithmParameterException;
>> 40: import java.security.InvalidKeyException;
>> 41: import java.security.InvalidParameterException;
> 
> Useless import.

Removed.

> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 144:
> 
>> 142:                 throw new ProviderException("Failed to initialize hybrid " +
>> 143:                         "keypair generator", e);
>> 144:             }
> 
> No need to catch either of the exceptions.

Removed.

> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 363:
> 
>> 361:         @Override
>> 362:         public SecretKey engineDecapsulate(byte[] encapsulation, int from,
>> 363:                 int to, String algorithm) throws DecapsulateException {
> 
> You might want to check the length of `encapsulation`.

Checkings added to decapsulate and encapsulate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595801566
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595801594
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595801547
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595801747

From hchao at openjdk.org  Sun Dec  7 02:26:54 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sun, 7 Dec 2025 02:26:54 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v18]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <X-pfGl80OppKgnJtfH2xmS2uIAWkAUHzVFu4F5UE-gI=.1f210bce-09a7-47cb-b59f-c9199e98cee2@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  Updates with Weijun's comments(encapsulate/decapsulate len checks)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/30da7e01..787f0042

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=16-17

  Stats: 64 lines in 2 files changed: 35 ins; 16 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From weijun at openjdk.org  Sun Dec  7 02:51:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 7 Dec 2025 02:51:06 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v18]
In-Reply-To: <X-pfGl80OppKgnJtfH2xmS2uIAWkAUHzVFu4F5UE-gI=.1f210bce-09a7-47cb-b59f-c9199e98cee2@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <X-pfGl80OppKgnJtfH2xmS2uIAWkAUHzVFu4F5UE-gI=.1f210bce-09a7-47cb-b59f-c9199e98cee2@github.com>
Message-ID: <kskw6GGiV1_scNLv26BaaSH5MV-HSVjJCH9NbYr90jc=.4efc916e-d67b-4c75-bba7-9938ec08a547@github.com>

On Sun, 7 Dec 2025 02:26:54 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates with Weijun's comments(encapsulate/decapsulate len checks)

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 336:

> 334:             int actualEncSize = leftEnc.length + rightEnc.length;
> 335: 
> 336:             if (actualEncSize != expectedEncSize) {

We probably don't need this check. `left` and `right` are generated inside this method and there is no need to worry about they have the wrong lengths.

This is not like in `engineDecapsulate` where `encapsulation` is provided by the caller and we need to validate it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595845791

From weijun at openjdk.org  Sun Dec  7 02:56:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 7 Dec 2025 02:56:59 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
 <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
 <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>
Message-ID: <Xa0UFpj69YfwXXjOawdLc4mNWk42KLsnzrasqhiDlwI=.95293fc0-efcd-4178-8c55-8b264679e402@github.com>

On Fri, 5 Dec 2025 22:34:26 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Apache HTTP Server [resolves against the defined `ServerRoot` directory](https://httpd.apache.org/docs/current/mod/core.html#include:~:text=Or%2C%20providing%20paths,conf/vhosts/*.conf):
>>> Or, providing paths relative to your [`ServerRoot`](https://httpd.apache.org/docs/current/mod/core.html#serverroot) directory:
>>>
>>>     Include conf/ssl.conf
>>>     Include conf/vhosts/*.conf
>
> I have pushed the changes to proceed without resolution (9f298af59431507a66e3141c54abb59fcf3666f6, 2a012397baf0599e7dbe209975b3b353c3de5617, 1178544bda12bb4a6cd4d4400dad618292f29151, c33bf62c2831acefd90ec476fcfb6d853be873ee).
> 
> Since we are no longer resolving paths, we can incur in some relative paths complexity, which is perhaps not very friendly in debug message logs. Each relative include can potentially introduce some `../`, which will accumulate if paths are not resolved.
> 
> So we can end with paths like the following one:
> 
> /basedir/jdk/conf/security/../../../properties/dir1/../../jdk/conf/security/other.properties
> 
> 
> Which could be simply logged as:
> 
> /basedir/jdk/conf/security/other.properties
> 
> 
> So even when I already adjusted the test case, is perhaps better to undo the test changes and try to beautify the paths in debugging messages (but with `LinkOption.NOFOLLOW_LINKS`, to avoid confusion):
> 
> diff --git a/src/java.base/share/classes/java/security/Security.java b/src/java.base/share/classes/java/security/Security.java
> index 36021f42862..533072b0d08 100644
> --- a/src/java.base/share/classes/java/security/Security.java
> +++ b/src/java.base/share/classes/java/security/Security.java
> @@ -311,8 +311,13 @@ private static void loadFromUrl(URL url, LoadingMode mode)
>          private static void debugLoad(boolean start, Object source) {
>              if (sdebug != null) {
> +                if (source instanceof Path path) {
> +                    try {
> +                        source = path.toRealPath(LinkOption.NOFOLLOW_LINKS);
> +                    } catch (IOException ignore) {}
> +                }
>                  int level = activePaths.isEmpty() ? 1 : activePaths.size();
>                  sdebug.println((start ?
>                          ">".repeat(level) + " starting to process " :
>                          "<".repeat(level) + " finished processing ") + source);
>              }
>          }
> 
> 
> 
> NOTE: even with `LinkOption.NOFOLLOW_LINKS`, `path.toRealPath()` fails for the problematic cases, so it would be just a best effort to make the paths clearer for the user.
> 
> What do you think?

I thought `normalize` will remove those `..` inside?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2595863996

From hchao at openjdk.org  Sun Dec  7 03:36:45 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sun, 7 Dec 2025 03:36:45 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v19]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <Ly3BEpMhflCZWaHAT31t9KnxeSaOU4bmxqA4bMJzBrk=.77383dc9-1614-4f5b-aad5-5406e705e40f@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  Remove len check from encapsulate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/787f0042..02eab2f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=17-18

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

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

From hchao at openjdk.org  Sun Dec  7 03:36:48 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sun, 7 Dec 2025 03:36:48 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v18]
In-Reply-To: <kskw6GGiV1_scNLv26BaaSH5MV-HSVjJCH9NbYr90jc=.4efc916e-d67b-4c75-bba7-9938ec08a547@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <X-pfGl80OppKgnJtfH2xmS2uIAWkAUHzVFu4F5UE-gI=.1f210bce-09a7-47cb-b59f-c9199e98cee2@github.com>
 <kskw6GGiV1_scNLv26BaaSH5MV-HSVjJCH9NbYr90jc=.4efc916e-d67b-4c75-bba7-9938ec08a547@github.com>
Message-ID: <khJpDBLmhTk5vIkqNtnhbLm9ujyE6fWsIY0c13SJKx4=.6b4be519-bb56-48b0-b9cc-7f44a356b89a@github.com>

On Sun, 7 Dec 2025 02:48:13 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:
>> 
>>   Updates with Weijun's comments(encapsulate/decapsulate len checks)
>
> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 336:
> 
>> 334:             int actualEncSize = leftEnc.length + rightEnc.length;
>> 335: 
>> 336:             if (actualEncSize != expectedEncSize) {
> 
> We probably don't need this check. `left` and `right` are generated inside this method and there is no need to worry about they have the wrong lengths.
> 
> This is not like in `engineDecapsulate` where `encapsulation` is provided by the caller and we need to validate it.

Removed the extra len check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2595895032

From jjiang at openjdk.org  Mon Dec  8 03:02:42 2025
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 8 Dec 2025 03:02:42 GMT
Subject: RFR: 8373231: ECDSAOperations::toAffinePoint is redundant
Message-ID: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>

`ECDSAOperations::toAffinePoint` should be removed, and `AffinePoint::fromECPoint` should be used instead.

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

Commit messages:
 - 8373231: ECDSAOperations::toAffinePoint is redundant

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

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

From duke at openjdk.org  Mon Dec  8 08:59:05 2025
From: duke at openjdk.org (duke)
Date: Mon, 8 Dec 2025 08:59:05 GMT
Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due
 to IllegalArgumentException [v7]
In-Reply-To: <6GTacCykz6WSOZCbU4CIJvHf4_dCG_j8FlsupgiC0uA=.83dbb600-11c8-48e8-8894-97c40c7d0c51@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
 <6GTacCykz6WSOZCbU4CIJvHf4_dCG_j8FlsupgiC0uA=.83dbb600-11c8-48e8-8894-97c40c7d0c51@github.com>
Message-ID: <1Oip5LrpmmUvTsF5yI4lmafLChzYR-hr_GHizRvwoB8=.8cc35b0c-8475-4be9-84f2-ce2ec99c4f80@github.com>

On Thu, 4 Dec 2025 14:00:32 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> Let me propose a fix and a test case for JDK-8369950.
>> 
>> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
>> 
>> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
>> 
>> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
>> 
>> SNIHostName, as defined in
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
>> 
>> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
>> 
>> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
>> 
>> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
>> 
>> Testing:
>> - standard jtreg tests goups showed no regressions
>> - the new test passes with the fix and fails otherwise
>> - passes also with BCJSSE in FIPS and standard mode 
>> 
>> <details><summary> BCJSSE standard</summary>
>> 
>> 
>> STDOUT:
>> STDERR:
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
>> INFORMATION: Found boolean security property [keystore.type.compat]: true
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
>> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
>> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>> WARNUNG: Ignoring unsupported entry in 'jdk.tl...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - addressed more review comments

@sercher 
Your change (at version 36c08741cc1f4100f62517cd91505565712bbec8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3625753105

From schernyshev at openjdk.org  Mon Dec  8 09:09:29 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 8 Dec 2025 09:09:29 GMT
Subject: Integrated: 8369950: TLS connection to IPv6 address fails with BCJSSE
 due to IllegalArgumentException
In-Reply-To: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
References: <SMoO6E3_oNfEqUTljjfqO-OhsRRODm36Jkpp7nz774Q=.299fa39b-4c4a-4c3f-948d-715f1e55a1f8@github.com>
Message-ID: <IL0l2K3Z-EG0so6lWLzMh-ScPd2INNG5hs50merhcow=.0e1729b7-6afe-4139-b109-00631ed4bd41@github.com>

On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> Let me propose a fix and a test case for JDK-8369950.
> 
> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl.
> 
> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name).
> 
> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception.
> 
> SNIHostName, as defined in
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66
> 
> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`.
> 
> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see
> 
> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116
> 
> Testing:
> - standard jtreg tests goups showed no regressions
> - the new test passes with the fix and fails otherwise
> - passes also with BCJSSE in FIPS and standard mode 
> 
> <details><summary> BCJSSE standard</summary>
> 
> 
> STDOUT:
> STDERR:
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
> INFORMATION: Found boolean security property [keystore.type.compat]: true
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature
> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature
> Dez. 01, 2025 2...

This pull request has now been integrated.

Changeset: 7da91533
Author:    Sergey Chernyshev <schernyshev at openjdk.org>
Committer: Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7da91533aaf2033cedee6e2a56fb693f26909df5
Stats:     388 lines in 2 files changed: 386 ins; 0 del; 2 mod

8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException

Co-authored-by: Mikhail Yankelevich <myankelevich at openjdk.org>
Reviewed-by: djelinski, vyazici, dfuchs, myankelevich

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

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

From duke at openjdk.org  Mon Dec  8 10:32:59 2025
From: duke at openjdk.org (duke)
Date: Mon, 8 Dec 2025 10:32:59 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap [v4]
In-Reply-To: <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
 <m_DOkWOrOzJDuL9apNPnybvkms3qPqpNIFTwXcHkOYA=.5e736241-ff1b-47c8-bb18-463a4cc227c4@github.com>
Message-ID: <_ELON8hXTIbtqkG616W4SOfuvSjrWRh10ebgaH7lHwM=.4fa420d4-0fe4-4bd1-9fb6-03452b5edc29@github.com>

On Fri, 5 Dec 2025 12:24:37 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases. 
>> 
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java
>
> Neha Joshi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368524 : Formatting issue resolved.

@nehajoshinj 
Your change (at version afcffbdbedb095b172c00d52e49ca4843099d0fa) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27847#issuecomment-3626179954

From duke at openjdk.org  Mon Dec  8 10:39:26 2025
From: duke at openjdk.org (Nick Hall)
Date: Mon, 8 Dec 2025 10:39:26 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v14]
In-Reply-To: <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
Message-ID: <E6XS5EGA55R5pHxNpnKSX9_Af9n4x7BtRVoGvLublTQ=.22ed5c33-f229-4753-adc2-843c341d7aca@github.com>

On Thu, 4 Dec 2025 11:31:46 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the devkit build scripts to allow the devkit to include the
>   required packages for KRB5 (libkrb and libcom_err).
>   
>   This was run on RHEL8, building for OL6, which required adding isl to
>   allow the latest gcc to build (this has been required for some time I
>   think).
>   
>   It also fixes one missing `--prefix` option which was causing things to
>   not be correctly installed in the sysroot.

> A new enhancement is filed at [bugs.openjdk.org/browse/JDK-8373137](https://bugs.openjdk.org/browse/JDK-8373137).

Thanks - would you mind also creating one for the devkit fixes?  I'll separate them out from here.

Would you like me to put the FFM changes on this PR or abandon and create two new PRs (one for FFM, one for devkit fixes that are orthogonal)?  Or would you like to merge the Linux support on this PR (minus devkit changes, optional krb5 dependency) then branch the FFM changes off after that?

I've had a go at the FFM changes, and by using jextract a lot of the work can just be generated which is good, the rest doesn't look too bad as you said.  I've got something early working, although need to do some work on the tests to make it avoid JNI too.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3626221840

From weijun at openjdk.org  Mon Dec  8 13:01:35 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 Dec 2025 13:01:35 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v14]
In-Reply-To: <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <zuoXvQ7E1po8AV-G-ODgnwD7HHVzhG-gtr-Bqdwqkmw=.cf72bbcc-992b-4d99-9390-8d6edc3b8655@github.com>
Message-ID: <gq2DeN5xSBS93Xg9sUVypkmwKh9pm5sG3_UiO0ECCeE=.0fe99604-9a0a-4f9d-9981-e24775a60c78@github.com>

On Thu, 4 Dec 2025 11:31:46 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the devkit build scripts to allow the devkit to include the
>   required packages for KRB5 (libkrb and libcom_err).
>   
>   This was run on RHEL8, building for OL6, which required adding isl to
>   allow the latest gcc to build (this has been required for some time I
>   think).
>   
>   It also fixes one missing `--prefix` option which was causing things to
>   not be correctly installed in the sysroot.

The FFM change should go with [JDK-8373137](https://bugs.openjdk.org/browse/JDK-8373137). For this PR, my personal suggestion is that there is no need to integrate it, at least not to the main line repository. You might want to check with one of the update releases to see if they are interested in the feature. You can also ask them whether the devkit update should be included or in a different PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3626839659

From mullan at openjdk.org  Mon Dec  8 15:49:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 Dec 2025 15:49:54 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <AbhkAIgl9zlpS-9_K9uvtacFoqjQqwDFI9KpkqwXI20=.524c395b-e367-45cc-a3e8-c7f40ae98737@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <MnG7AzyQAl8GoAA9LJrb6cUPWQNd8G_A65_1p4xEyJc=.556f45c0-dc78-4bf9-a80b-6ae9d9c3470c@github.com>
 <AbhkAIgl9zlpS-9_K9uvtacFoqjQqwDFI9KpkqwXI20=.524c395b-e367-45cc-a3e8-c7f40ae98737@github.com>
Message-ID: <dLn_5MdKx_QS8rxuvIVgTcQvWq-Yl91r0D37V84prGo=.aa9570e8-1320-4ac3-ad00-df67d08eb935@github.com>

On Sun, 7 Dec 2025 00:22:14 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java line 120:
>> 
>>> 118: 
>>> 119:     public static class MLKEM extends KEMBench {
>>> 120:         @Param({"ML-KEM-512", "ML-KEM-768", "ML-KEM-1024" })
>> 
>> Not a JMH expert, but what is the difference between these parameters and the ones on line 48? It looks like a duplicate test to me.
>
> It turns out this is a mistake.  By having both this line and 48 with the same algorithm names, the benchmark runs them twice.  Our benchmarks tend to be organized either with the main class as a baseline benchmark with subclasses for all other types, or an abstract base class with an empty @param tag and subclasses for each actual benchmark.  `KeyAgreementBench.java` is done that way, and I personally like that approach better and changed this class to follow that model.  Either way is just fine though.  The important thing is that if you have parameters in the parent class, it should not match any parameter sets in the child classes or you just end up running the same benchmark twice.

Thanks for fixing these comments on KEMBench. @haimaychao you can resolve this and the other 2 KEMBench related conversations now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2599129398

From hchao at openjdk.org  Mon Dec  8 16:04:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 8 Dec 2025 16:04:20 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <dLn_5MdKx_QS8rxuvIVgTcQvWq-Yl91r0D37V84prGo=.aa9570e8-1320-4ac3-ad00-df67d08eb935@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <MnG7AzyQAl8GoAA9LJrb6cUPWQNd8G_A65_1p4xEyJc=.556f45c0-dc78-4bf9-a80b-6ae9d9c3470c@github.com>
 <AbhkAIgl9zlpS-9_K9uvtacFoqjQqwDFI9KpkqwXI20=.524c395b-e367-45cc-a3e8-c7f40ae98737@github.com>
 <dLn_5MdKx_QS8rxuvIVgTcQvWq-Yl91r0D37V84prGo=.aa9570e8-1320-4ac3-ad00-df67d08eb935@github.com>
Message-ID: <Crt2f95bjfWCGL7sZLQWRLCinYNGgSKcH1IAlwNky10=.49a3b1b4-443a-4bc9-a34c-2f413e9073be@github.com>

On Mon, 8 Dec 2025 15:46:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> It turns out this is a mistake.  By having both this line and 48 with the same algorithm names, the benchmark runs them twice.  Our benchmarks tend to be organized either with the main class as a baseline benchmark with subclasses for all other types, or an abstract base class with an empty @param tag and subclasses for each actual benchmark.  `KeyAgreementBench.java` is done that way, and I personally like that approach better and changed this class to follow that model.  Either way is just fine though.  The important thing is that if you have parameters in the parent class, it should not match any parameter sets in the child classes or you just end up running the same benchmark twice.
>
> Thanks for fixing these comments on KEMBench. @haimaychao you can resolve this and the other 2 KEMBench related conversations now.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2599190737

From mullan at openjdk.org  Mon Dec  8 16:22:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 Dec 2025 16:22:47 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v19]
In-Reply-To: <Ly3BEpMhflCZWaHAT31t9KnxeSaOU4bmxqA4bMJzBrk=.77383dc9-1614-4f5b-aad5-5406e705e40f@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <Ly3BEpMhflCZWaHAT31t9KnxeSaOU4bmxqA4bMJzBrk=.77383dc9-1614-4f5b-aad5-5406e705e40f@github.com>
Message-ID: <naKK66JeFtMxOBsmdsDwSP7S6fndNiSi7UWX_nwTGbo=.d73033f4-9e7b-46f3-a7a9-87b56f3b8576@github.com>

On Sun, 7 Dec 2025 03:36:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove len check from encapsulate

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27614#pullrequestreview-3552900711

From fguallini at openjdk.org  Mon Dec  8 17:07:51 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Mon, 8 Dec 2025 17:07:51 GMT
Subject: RFR: 8372950: Pem.pemEncoded should cache the Pattern
Message-ID: <5mYwWMub4PCyu7L6pfrilL_7HeX4fFeRhzCke4mSH5Q=.0d8fc616-661a-4e55-905e-fc33563a301e@github.com>

PEM is using the String.replaceAll() method that creates a Pattern internally every time. This looks like a minor inefficiency and since it is caching Patterns for other cases, it should do the same here.

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

Commit messages:
 - renamed
 - regex cached

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

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

From wetmore at openjdk.org  Mon Dec  8 21:53:22 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 8 Dec 2025 21:53:22 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <-pvm0ju7vE2PT7QUD5e3TdzTPe2IfbuPLOdTxEuVrcg=.6b803aa5-a54f-430f-814a-7a188f9e6a54@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
 <-pvm0ju7vE2PT7QUD5e3TdzTPe2IfbuPLOdTxEuVrcg=.6b803aa5-a54f-430f-814a-7a188f9e6a54@github.com>
Message-ID: <yBjU1lOcLLsIY3jTI-g1xSk6x1ZEiNw7nY-bsl_GGSI=.48ab2320-44c9-4ea0-9a88-76fcb89a99d9@github.com>

On Sat, 6 Dec 2025 17:20:16 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 91:
>> 
>>> 89:             // The order of shares in the concatenation for group name
>>> 90:             // X25519MLKEM768 has been reversed. This is due to IETF
>>> 91:             // historical reasons.
>> 
>> Can we just change this to something like "as per the current draft RFC?"  
>> 
>> "historical reasons" is too vague.  The draft is the real reason.
>
> Updated comment as suggested (comment is in HybridProvider class now).

Be sure to open a bug to update the mentions of the draft to RFC when they go final.

>> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 635:
>> 
>>> 633: 
>>> 634:             if (handshakeSecret == null) {
>>> 635:                 SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);
>> 
>> Since we only end up with one possession, can we move this up into the for loop?  Each of the various possession types goes through the `for` loop, so seems this would be a tiny bit clearer.
>> 
>>     for () {
>>         if (pos instanceof ...) {
>>             handshakeSecret =...
>>         } else {
>>             SSLKeyDerivation handshakeKD = ...
>>         }
>>     }
>
> Keep the code as it is. This is because if we move the KA derivation code to the for loop as the else branch, we make it appear to be associated with a possession. KA does not store the shared secret in a possession like KEM, so keep its logic separate.

Ok, I can see that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600265118
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600262204

From wetmore at openjdk.org  Mon Dec  8 21:58:17 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 8 Dec 2025 21:58:17 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <-pvm0ju7vE2PT7QUD5e3TdzTPe2IfbuPLOdTxEuVrcg=.6b803aa5-a54f-430f-814a-7a188f9e6a54@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
 <-pvm0ju7vE2PT7QUD5e3TdzTPe2IfbuPLOdTxEuVrcg=.6b803aa5-a54f-430f-814a-7a188f9e6a54@github.com>
Message-ID: <lLw-5fEbBY2zbAd4e9VcXyASxVMn0zsDX_U40Zp2Iy0=.4ca17360-9b69-4900-9f90-0bd4ed238640@github.com>

On Sat, 6 Dec 2025 17:21:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 61:
>> 
>>> 59:  * in a single TLS hybrid named group.
>>> 60:  * It implements:
>>> 61:  *  - Hybrid KeyPair generation
>> 
>> This seems to be a mix of javadoc and markdown.  If anyone ever does generate javadocs for these internal classes, this will not render well.
>
> Fixed the comments.

I was thinking of just removing the markdown bits, but this is ok too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600272443

From wetmore at openjdk.org  Mon Dec  8 21:58:20 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 8 Dec 2025 21:58:20 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
Message-ID: <QFbu_DTje-fcGKzAnjqwW4CRV27GDGtn5TZ2EI6WBkI=.72123f4a-7aaa-48e0-978f-f7a5863fb9bd@github.com>

On Sat, 6 Dec 2025 07:22:44 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updates with Weijun's comments
>>  - Comments added for possession creation per handshake
>
> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 319:
> 
>> 317:     }
>> 318: 
>> 319:     private static byte[] concat(byte[]... inputs) {
> 
> @wangweij did the following in `com.sun.crypto.provider.DHKEM.java` and `c.s.c.p.HPKE.java`:
> 
>     private static byte[] concat(byte[]... inputs) {
>         ByteArrayOutputStream o = new ByteArrayOutputStream(); 
>         Arrays.stream(inputs).forEach(o::writeBytes);
>         return o.toByteArray();
>     }
> 
> Since this is the third usage in the last couple years, maybe put this in a utility class instead and adjust the other instances?

Were you going to update this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600274684

From hchao at openjdk.org  Mon Dec  8 22:10:07 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 8 Dec 2025 22:10:07 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <yBjU1lOcLLsIY3jTI-g1xSk6x1ZEiNw7nY-bsl_GGSI=.48ab2320-44c9-4ea0-9a88-76fcb89a99d9@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
 <-pvm0ju7vE2PT7QUD5e3TdzTPe2IfbuPLOdTxEuVrcg=.6b803aa5-a54f-430f-814a-7a188f9e6a54@github.com>
 <yBjU1lOcLLsIY3jTI-g1xSk6x1ZEiNw7nY-bsl_GGSI=.48ab2320-44c9-4ea0-9a88-76fcb89a99d9@github.com>
Message-ID: <7sDN9ZV-Esonxkx5tNH-JFC3YcHuue73tt0WqkTsS8c=.f680a3a4-b21a-4c81-b08f-cdb1867bcd47@github.com>

On Mon, 8 Dec 2025 21:51:05 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Updated comment as suggested (comment is in HybridProvider class now).
>
> Be sure to open a bug to update the mentions of the draft to RFC when they go final.

sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600304006

From hchao at openjdk.org  Mon Dec  8 22:10:09 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 8 Dec 2025 22:10:09 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <QFbu_DTje-fcGKzAnjqwW4CRV27GDGtn5TZ2EI6WBkI=.72123f4a-7aaa-48e0-978f-f7a5863fb9bd@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
 <QFbu_DTje-fcGKzAnjqwW4CRV27GDGtn5TZ2EI6WBkI=.72123f4a-7aaa-48e0-978f-f7a5863fb9bd@github.com>
Message-ID: <9-YYxkFdF7_aFH6JtYLMWzHbhuPbMIVswoPuDKWYxpc=.01a761cc-6372-42e6-93fc-5048a3d14796@github.com>

On Mon, 8 Dec 2025 21:55:28 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 319:
>> 
>>> 317:     }
>>> 318: 
>>> 319:     private static byte[] concat(byte[]... inputs) {
>> 
>> @wangweij did the following in `com.sun.crypto.provider.DHKEM.java` and `c.s.c.p.HPKE.java`:
>> 
>>     private static byte[] concat(byte[]... inputs) {
>>         ByteArrayOutputStream o = new ByteArrayOutputStream(); 
>>         Arrays.stream(inputs).forEach(o::writeBytes);
>>         return o.toByteArray();
>>     }
>> 
>> Since this is the third usage in the last couple years, maybe put this in a utility class instead and adjust the other instances?
>
> Were you going to update this?

This would be updated in a differnet PR along with adjusting the other instances.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600304232

From wetmore at openjdk.org  Tue Dec  9 00:25:12 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 9 Dec 2025 00:25:12 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v14]
In-Reply-To: <9-YYxkFdF7_aFH6JtYLMWzHbhuPbMIVswoPuDKWYxpc=.01a761cc-6372-42e6-93fc-5048a3d14796@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <dc1XdZADm1sb8e07Mszq51VGeMDmIyXC8RB3YyFRjuk=.097f8493-0b2a-4f4d-89fa-14ed472cf282@github.com>
 <P2Vm52HSgGBoLLNIb1EF3QXxxA8qBYcn7vIsomj3R7c=.b0e95384-d33d-47cc-b911-32363d36e361@github.com>
 <QFbu_DTje-fcGKzAnjqwW4CRV27GDGtn5TZ2EI6WBkI=.72123f4a-7aaa-48e0-978f-f7a5863fb9bd@github.com>
 <9-YYxkFdF7_aFH6JtYLMWzHbhuPbMIVswoPuDKWYxpc=.01a761cc-6372-42e6-93fc-5048a3d14796@github.com>
Message-ID: <dg7Qfyle4rlSKct75jEk8kHM7AUZJFNLeUDWqs8NwEY=.9f25e2d7-c0a4-4da6-8b2c-f2bed5668362@github.com>

On Mon, 8 Dec 2025 22:07:35 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Were you going to update this?
>
> This would be updated in a differnet PR along with adjusting the other instances.

Please be sure to open this bug.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600607651

From liach at openjdk.org  Tue Dec  9 01:31:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 Dec 2025 01:31:46 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v5]
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <2QctOO9M2yu2_4OimyQAAcqcgK9MEfR-K99SsLl5Hno=.af6a8636-020e-4a7a-8cf2-263b966164cd@github.com>

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
> 
> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`.

Chen Liang 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 18 additional commits since the last revision:

 - Update, review
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Update NPE per roger review
 - Use c++ enum classes per jdksjolen
 - Merge branch 'exp/requireNonNull-message-hacks' of github.com:liachmodded/jdk into exp/requireNonNull-message-hacks
 - Web review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Years
 - Roll back Objects.rNN for now
 - ... and 8 more: https://git.openjdk.org/jdk/compare/5fccdccb...2dafe83a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26600/files
  - new: https://git.openjdk.org/jdk/pull/26600/files/4ba1f17c..2dafe83a

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

  Stats: 636041 lines in 7152 files changed: 435596 ins; 128248 del; 72197 mod
  Patch: https://git.openjdk.org/jdk/pull/26600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600

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

From wetmore at openjdk.org  Tue Dec  9 05:05:10 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 9 Dec 2025 05:05:10 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v19]
In-Reply-To: <Ly3BEpMhflCZWaHAT31t9KnxeSaOU4bmxqA4bMJzBrk=.77383dc9-1614-4f5b-aad5-5406e705e40f@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <Ly3BEpMhflCZWaHAT31t9KnxeSaOU4bmxqA4bMJzBrk=.77383dc9-1614-4f5b-aad5-5406e705e40f@github.com>
Message-ID: <U8YZsAgJvYWV_CWy-1Ya79BBcgG_5NAbupJ_HN5tEHA=.b5f54767-51e5-4847-b146-7b42de48104d@github.com>

On Sun, 7 Dec 2025 03:36:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove len check from encapsulate

Couple of minor issues.

I'll approve the next round.

src/java.base/share/classes/sun/security/ssl/Hybrid.java line 385:

> 383:     }
> 384: 
> 385:     public record SecretKeyImpl(SecretKey k1, SecretKey k2)

I mentioned this earlier as part of a general comment.  Several got addressed, but these got missed.  I think the `PublicKeys`/`PrivateKey`/`SecretKey` here could all be package private (can't be private, as they are used in a couple other classes).

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

PR Review: https://git.openjdk.org/jdk/pull/27614#pullrequestreview-3554942157
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600796373

From wetmore at openjdk.org  Tue Dec  9 05:05:13 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 9 Dec 2025 05:05:13 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <z5SettA-n1WzZTYESbgpz2MCCeyWapvJH0ob-Jafkmw=.9cac41b0-e709-451a-939c-19d3358007a6@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <z5SettA-n1WzZTYESbgpz2MCCeyWapvJH0ob-Jafkmw=.9cac41b0-e709-451a-939c-19d3358007a6@github.com>
Message-ID: <yAiQ6yzdvbEsShIXuppqbnlP54yxHrM34thjcfsIsgc=.eb7bbab0-3be8-4861-b9d5-20f0bfb2f64f@github.com>

On Tue, 25 Nov 2025 20:33:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - Change default named group list to have only X25519MLKEM768
>
> test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java line 38:
> 
>> 36:  * @comment SunPKCS11 does not support (TLS1.2) SunTlsExtendedMasterSecret yet.
>> 37:  *   Stateless resumption doesn't currently work with NSS-FIPS, see JDK-8368669
>> 38:  * @run main/othervm/timeout=120 -Djdk.tls.client.protocols=TLSv1.3 -Djdk.tls.namedGroups=x25519,secp256r1,secp384r1,secp521r1,x448,ffdhe2048,ffdhe3072,ffdhe4096,ffdhe6144,ffdhe8192 FipsModeTLS
> 
> Long line, break up into more than one line. 
> 
> Also instead of setting the system property, suggest using the `SSLParameters.getNamedGroups()` API to read the default list of named groups, remove X25519MLKEM768 and then set the list back. This way if the other defaults change in the future (like removing some of the ffdhe groups) the code will still be ok and reflect the default list.
> 
> It looks like the code already does that for other groups in `createSSLEngine`.

Looks like this long line comment got missed.  (or alternatively use the API.)_

Could you also add a comment about why you're forcing the namedGroups here? Guessing that FIPS doesn't support MLKEM?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2600982537

From hchao at openjdk.org  Tue Dec  9 06:22:27 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 9 Dec 2025 06:22:27 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v20]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <9co2eRdyrQafFTJmdle7YaYTEJ5j0hAPJ1RfUZreYpo=.b3b2fdde-16f4-459d-8dcd-79ffca197d95@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  Updates with Brad's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/02eab2f2..cf47f821

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=18-19

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

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

From hchao at openjdk.org  Tue Dec  9 06:22:28 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 9 Dec 2025 06:22:28 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v19]
In-Reply-To: <Ly3BEpMhflCZWaHAT31t9KnxeSaOU4bmxqA4bMJzBrk=.77383dc9-1614-4f5b-aad5-5406e705e40f@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <Ly3BEpMhflCZWaHAT31t9KnxeSaOU4bmxqA4bMJzBrk=.77383dc9-1614-4f5b-aad5-5406e705e40f@github.com>
Message-ID: <hC_N0QAoDQjNp0N7iubmGMw6Z66caARCyU-7xv47BEk=.d24fbf88-0051-4592-8e54-81817deaac2a@github.com>

On Sun, 7 Dec 2025 03:36:45 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove len check from encapsulate

Added comment and split up the long line in FipsModeTLS test.

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

PR Comment: https://git.openjdk.org/jdk/pull/27614#issuecomment-3630535387

From hchao at openjdk.org  Tue Dec  9 06:22:30 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 9 Dec 2025 06:22:30 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v19]
In-Reply-To: <U8YZsAgJvYWV_CWy-1Ya79BBcgG_5NAbupJ_HN5tEHA=.b5f54767-51e5-4847-b146-7b42de48104d@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <Ly3BEpMhflCZWaHAT31t9KnxeSaOU4bmxqA4bMJzBrk=.77383dc9-1614-4f5b-aad5-5406e705e40f@github.com>
 <U8YZsAgJvYWV_CWy-1Ya79BBcgG_5NAbupJ_HN5tEHA=.b5f54767-51e5-4847-b146-7b42de48104d@github.com>
Message-ID: <ekbSrJoRctPoFl1ZkgMdKtGMLRC4GKfjV2cjUGWHY_g=.39b9d28d-ba47-450b-8b15-2ded37455c38@github.com>

On Tue, 9 Dec 2025 02:07:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove len check from encapsulate
>
> src/java.base/share/classes/sun/security/ssl/Hybrid.java line 385:
> 
>> 383:     }
>> 384: 
>> 385:     public record SecretKeyImpl(SecretKey k1, SecretKey k2)
> 
> I mentioned this earlier as part of a general comment.  Several got addressed, but these got missed.  I think the `PublicKeys`/`PrivateKey`/`SecretKey` here could all be package private (can't be private, as they are used in a couple other classes).

Fixed. SecreyKeyImpl and PublicKeyImpl: package-private, and PrivateKeyImpl: private.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2601248138

From hchao at openjdk.org  Tue Dec  9 06:27:09 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 9 Dec 2025 06:27:09 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <yAiQ6yzdvbEsShIXuppqbnlP54yxHrM34thjcfsIsgc=.eb7bbab0-3be8-4861-b9d5-20f0bfb2f64f@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <z5SettA-n1WzZTYESbgpz2MCCeyWapvJH0ob-Jafkmw=.9cac41b0-e709-451a-939c-19d3358007a6@github.com>
 <yAiQ6yzdvbEsShIXuppqbnlP54yxHrM34thjcfsIsgc=.eb7bbab0-3be8-4861-b9d5-20f0bfb2f64f@github.com>
Message-ID: <25kUxaTzJsjtpflrLOtkiTyd5nDubGzkkfZOOT6nQCY=.8431917c-bd09-48f5-a272-ef5d0fa3b054@github.com>

On Tue, 9 Dec 2025 03:48:13 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java line 38:
>> 
>>> 36:  * @comment SunPKCS11 does not support (TLS1.2) SunTlsExtendedMasterSecret yet.
>>> 37:  *   Stateless resumption doesn't currently work with NSS-FIPS, see JDK-8368669
>>> 38:  * @run main/othervm/timeout=120 -Djdk.tls.client.protocols=TLSv1.3 -Djdk.tls.namedGroups=x25519,secp256r1,secp384r1,secp521r1,x448,ffdhe2048,ffdhe3072,ffdhe4096,ffdhe6144,ffdhe8192 FipsModeTLS
>> 
>> Long line, break up into more than one line. 
>> 
>> Also instead of setting the system property, suggest using the `SSLParameters.getNamedGroups()` API to read the default list of named groups, remove X25519MLKEM768 and then set the list back. This way if the other defaults change in the future (like removing some of the ffdhe groups) the code will still be ok and reflect the default list.
>> 
>> It looks like the code already does that for other groups in `createSSLEngine`.
>
> Looks like this long line comment got missed.  (or alternatively use the API.)_
> 
> Could you also add a comment about why you're forcing the namedGroups here? Guessing that FIPS doesn't support MLKEM?

Split up the long line. Yes, because of NSS-FIPS not support it, and added a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2601262949

From hchao at openjdk.org  Tue Dec  9 06:41:08 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 9 Dec 2025 06:41:08 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
In-Reply-To: <WT1vobmotZbk8scOCG0nds5IsyIpdAbSP2ly_wqPI-Y=.db079ed6-cc47-4448-99fc-f79d3e3fa216@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5pQFj-J1s-55ofZS8TzFlKSz8pV0MZath0Uct_SKjVY=.9e812f6d-5a00-461a-b388-e200c239403b@github.com>
 <WT1vobmotZbk8scOCG0nds5IsyIpdAbSP2ly_wqPI-Y=.db079ed6-cc47-4448-99fc-f79d3e3fa216@github.com>
Message-ID: <Ryjbf2ibSVJOx1FiHCKYgc358K7fl-IkRV-ahqPAJlo=.a3d833f0-773c-435e-9870-ca6f641e722e@github.com>

On Tue, 2 Dec 2025 16:58:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update names to uppercase
>>  - Remove fallback in engineGeneratePublic
>>  - Change default named group list to have only X25519MLKEM768
>
> test/jdk/sun/security/ssl/CipherSuite/DisabledCurve.java line 43:
> 
>> 41:         DisabledCurve DISABLE_NONE PASS
>> 42:  * @run main/othervm -Djdk.tls.namedGroups="SecP384r1MLKEM1024"
>> 43:         DisabledCurve SecP384r1MLKEM1024 FAIL
> 
> A different way to enhance this test so that the hybrids are only tested with TLS 1.3 would be to add additional optional command-line arguments that take the client and server protocols you want to _only_ test with, respectively, ex:
> 
> 
> @run main/othervm -Djdk.tls.namedGroups="SecP384r1MLKEM1024"
>         DisabledCurve DISABLE_NONE PASS TLSv1.3 TLSv1.3
> 
>         
> Just for your consideration, if you have time.

Keep the code as is for now (which follows the current model).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2601296558

From duke at openjdk.org  Tue Dec  9 14:47:36 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 9 Dec 2025 14:47:36 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
Message-ID: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>

?hould pass on Aarch64

The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
Other then fixing that, I did some formatting and corrected a comment.

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

Commit messages:
 - 8373059: Test sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64

Changes: https://git.openjdk.org/jdk/pull/28722/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28722&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373059
  Stats: 60 lines in 2 files changed: 31 ins; 4 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28722/head:pull/28722

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

From myankelevich at openjdk.org  Tue Dec  9 15:22:24 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 9 Dec 2025 15:22:24 GMT
Subject: RFR: 8373101: JdkClient and JdkServer test classes ignore
 namedGroups field
In-Reply-To: <xclTtN9JD3D4bQQOi5nV69exU7HzNllXXmTv_f6-Z3M=.eb524c86-50ad-4e1d-8763-a4856f05b856@github.com>
References: <xclTtN9JD3D4bQQOi5nV69exU7HzNllXXmTv_f6-Z3M=.eb524c86-50ad-4e1d-8763-a4856f05b856@github.com>
Message-ID: <VPZ4F3O6rgRZIoUTUJI7UqbWwqzaYgyvK76J9xPhl9Q=.d601805b-64f1-4b29-aecb-f7b85a93c9da@github.com>

On Thu, 4 Dec 2025 18:50:19 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates a couple test utility classes, JdkClient and JdkServer. Theseclasses extend AbstractPeer which contains a `namedGroup` field however, when creating/configuring the objects, the field is ignored. This PR just makes sure to include named groups if they are specified.

test/jdk/javax/net/ssl/TLSCommon/interop/JdkClient.java line 92:

> 90:         if (builder.getNamedGroups() != null
> 91:                 && builder.getNamedGroups().length > 0) {
> 92:             NamedGroup[] namedGroups = builder.getNamedGroups();

Minor: Do you think moving it outside of the if statement and making the if statement call `namedGroups` directly might be a bit easier to read?  Otherwise you're calling the same action 3 times in a row

test/jdk/javax/net/ssl/TLSCommon/interop/JdkClient.java line 96:

> 94:             for (int i = 0 ; i < namedGroups.length ; ++i) {
> 95:                 namedGroupStrs[i] = namedGroups[i].name;
> 96:             }

nit:  what do you think? 
```suggestion 
String[] namedGroupStrs = Arrays.stream(namedGroups)
                         .map(NamedGroup::name)
                         .toArray(String[]::new);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28664#discussion_r2603085845
PR Review Comment: https://git.openjdk.org/jdk/pull/28664#discussion_r2603111718

From myankelevich at openjdk.org  Tue Dec  9 15:32:28 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 9 Dec 2025 15:32:28 GMT
Subject: RFR: 8373231: ECDSAOperations::toAffinePoint is redundant
In-Reply-To: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
References: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
Message-ID: <L9D4AN28beu8Sq1EBiJ3vrrbb7CJoqos5ofR_VUmVQo=.f274cb90-7418-431b-a22a-fb10662b35a0@github.com>

On Mon, 8 Dec 2025 02:55:31 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `ECDSAOperations::toAffinePoint` should be removed, and `AffinePoint::fromECPoint` should be used instead.

Correct me if I'm wrong, this seems to be changing public API, shouldn't it have a csr then?

test/jdk/sun/security/ec/ECDSAPrimitive.java line 39:

> 37: /*
> 38:  * @test
> 39:  * @bug 8189189 8147502 8295010

Could you please update the bug id?

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

PR Review: https://git.openjdk.org/jdk/pull/28691#pullrequestreview-3558071282
PR Review Comment: https://git.openjdk.org/jdk/pull/28691#discussion_r2603147925

From mdonovan at openjdk.org  Tue Dec  9 15:53:17 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 9 Dec 2025 15:53:17 GMT
Subject: RFR: 8373101: JdkClient and JdkServer test classes ignore
 namedGroups field [v2]
In-Reply-To: <xclTtN9JD3D4bQQOi5nV69exU7HzNllXXmTv_f6-Z3M=.eb524c86-50ad-4e1d-8763-a4856f05b856@github.com>
References: <xclTtN9JD3D4bQQOi5nV69exU7HzNllXXmTv_f6-Z3M=.eb524c86-50ad-4e1d-8763-a4856f05b856@github.com>
Message-ID: <QiTFvmEvXqOER7IA31i9SuVUzMYNzpNYHPeUK8Dl5BA=.2fd9bb95-2e49-4c3b-9686-74fcf754688f@github.com>

> This PR updates a couple test utility classes, JdkClient and JdkServer. Theseclasses extend AbstractPeer which contains a `namedGroup` field however, when creating/configuring the objects, the field is ignored. This PR just makes sure to include named groups if they are specified.

Matthew Donovan 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:

 - refactored based on PR comments
 - Merge branch 'master' into abstractpeer
 - 8373101: JdkClient and JdkServer test classes ignore namedGroups field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28664/files
  - new: https://git.openjdk.org/jdk/pull/28664/files/17d447f7..a26ab92d

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

  Stats: 24712 lines in 480 files changed: 17252 ins; 5795 del; 1665 mod
  Patch: https://git.openjdk.org/jdk/pull/28664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28664/head:pull/28664

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

From hchao at openjdk.org  Tue Dec  9 17:53:23 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 9 Dec 2025 17:53:23 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v21]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <CZdKeIuTYyvircL7DAt9x-wIpDjl8Zpzo1yQitqC3lc=.2c168252-a783-45f4-b80a-f61d006a3467@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  small tweak to long line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/cf47f821..909faa51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=19-20

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

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

From wetmore at openjdk.org  Tue Dec  9 18:05:21 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 9 Dec 2025 18:05:21 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v21]
In-Reply-To: <CZdKeIuTYyvircL7DAt9x-wIpDjl8Zpzo1yQitqC3lc=.2c168252-a783-45f4-b80a-f61d006a3467@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <CZdKeIuTYyvircL7DAt9x-wIpDjl8Zpzo1yQitqC3lc=.2c168252-a783-45f4-b80a-f61d006a3467@github.com>
Message-ID: <qiiRuPgZ18u7AdVxoeTNdvVeGdcIOaU1AWGO0TI5xUY=.d1ecdd6b-6929-45a7-90c6-c321ab0c3d04@github.com>

On Tue, 9 Dec 2025 17:53:23 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small tweak to long line

Thanks for addressing all the comments.  I have nothing further.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27614#pullrequestreview-3558857835

From duke at openjdk.org  Tue Dec  9 18:09:50 2025
From: duke at openjdk.org (Neha Joshi)
Date: Tue, 9 Dec 2025 18:09:50 GMT
Subject: Integrated: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap
In-Reply-To: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
Message-ID: <oWKKBLHaJiLMXPcb6WwhBxg05Ue_Ca1VJemme8W8VLI=.5fb80055-49b8-4474-8801-c6a7fbfe8d57@github.com>

On Thu, 16 Oct 2025 13:52:58 GMT, Neha Joshi <duke at openjdk.org> wrote:

> This PR contain changes to handle skipped exception for below test cases. 
> 
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java

This pull request has now been integrated.

Changeset: b99be505
Author:    Neha Joshi <neha.j.joshi at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b99be505a5e3c8304be62a8b373d746fc52e8f0e
Stats:     11 lines in 2 files changed: 3 ins; 0 del; 8 mod

8368524: Tests are skipped and shown as passed in test/jdk/sun/security/pkcs11/Cipher/KeyWrap

Reviewed-by: myankelevich, rhalade

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

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

From rhalade at openjdk.org  Tue Dec  9 18:13:26 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 9 Dec 2025 18:13:26 GMT
Subject: RFR: 8373101: JdkClient and JdkServer test classes ignore
 namedGroups field [v2]
In-Reply-To: <QiTFvmEvXqOER7IA31i9SuVUzMYNzpNYHPeUK8Dl5BA=.2fd9bb95-2e49-4c3b-9686-74fcf754688f@github.com>
References: <xclTtN9JD3D4bQQOi5nV69exU7HzNllXXmTv_f6-Z3M=.eb524c86-50ad-4e1d-8763-a4856f05b856@github.com>
 <QiTFvmEvXqOER7IA31i9SuVUzMYNzpNYHPeUK8Dl5BA=.2fd9bb95-2e49-4c3b-9686-74fcf754688f@github.com>
Message-ID: <7mNaU_5MI1UfTDbw4yiZ9blP3iOZ6zAUhyM9J2M_S00=.77a8de46-e4c6-4914-81df-6b1ce6dabafd@github.com>

On Tue, 9 Dec 2025 15:53:17 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates a couple test utility classes, JdkClient and JdkServer. Theseclasses extend AbstractPeer which contains a `namedGroup` field however, when creating/configuring the objects, the field is ignored. This PR just makes sure to include named groups if they are specified.
>
> Matthew Donovan 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:
> 
>  - refactored based on PR comments
>  - Merge branch 'master' into abstractpeer
>  - 8373101: JdkClient and JdkServer test classes ignore namedGroups field

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28664#pullrequestreview-3558899791

From vpaprotski at openjdk.org  Tue Dec  9 18:41:18 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 9 Dec 2025 18:41:18 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
In-Reply-To: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
References: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
Message-ID: <bpeXR5mf9YC2k09cx-Uyo_PAQIoasVmg6P74XUBTqeY=.a20d72f3-9a60-4775-8126-241bcfbd0934@github.com>

On Tue, 9 Dec 2025 14:41:02 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> ?hould pass on Aarch64
> 
> The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
> Other then fixing that, I did some formatting and corrected a comment.

Claims: 
- "while the java version of `implDilithiumNttMult` can accept full signed INT32 on both `coeffs1` and `coeffs2`, in the actual implementation of ML_DSA, calls never exceed `-Q`-to-`+Q` on either inputs"
  - (I believe, it allows aarch64 to rearrange some multiplications, perhaps to relieve some register-alloc pressure? Multiplications are commutative, so this is valid, except range would be exceeded)
- "congruence is sufficient in modular arithmetic for test to pass"

The second claim is self-evident (which allows to relax the `Arrays.equals` test). 
The first.. I was able to convince myself by going through the code:
- All calls to `implDilithiumNttMult` originate from `nttConstMultiply` and `matrixVectorPointwiseMultiply`.
- All inputs to `nttConstMultiply` and `matrixVectorPointwiseMultiply` are 'cleansed' by `mlDsaVectorNtt`, `mlDsaNtt` and `generateA`
  - `mlDsaVectorNtt` itself is 'cleansed' by `mlDsaNtt`
  - `generateA` masks its outputs to 23-bits (fits within the 2Q in this PR)
  - `mlDsaNtt` 'cleansed' by `montMul`
  - `montMul` returns range `(-Q,Q)` per paper in the comments.



<img width="2080" height="852" alt="image" src="https://github.com/user-attachments/assets/17ce45a0-97ce-41a1-b7c1-a56bad9b9038" />

test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 147:

> 145: 
> 146:         if (!Arrays.equals(prod1, prod2)) {
> 147:             boolean modQequal = true;

I would probably had moved this to its own helper `arraysCongruent` and replaces the `if (!Arrays.equals(prod1, prod2))` with `!arraysCongruent(prod1, prod2)`. But not a deal-breaker..

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

Marked as reviewed by vpaprotski (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28722#pullrequestreview-3558941134
PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2603792002

From mdonovan at openjdk.org  Tue Dec  9 18:51:15 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 9 Dec 2025 18:51:15 GMT
Subject: Integrated: 8373101: JdkClient and JdkServer test classes ignore
 namedGroups field
In-Reply-To: <xclTtN9JD3D4bQQOi5nV69exU7HzNllXXmTv_f6-Z3M=.eb524c86-50ad-4e1d-8763-a4856f05b856@github.com>
References: <xclTtN9JD3D4bQQOi5nV69exU7HzNllXXmTv_f6-Z3M=.eb524c86-50ad-4e1d-8763-a4856f05b856@github.com>
Message-ID: <r8PovLxpwR-7RpcIjpWvLVkBcWOwupkB-4f_bDjMF0w=.3addcb86-ea9b-4086-a249-8494ed39c1e5@github.com>

On Thu, 4 Dec 2025 18:50:19 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates a couple test utility classes, JdkClient and JdkServer. Theseclasses extend AbstractPeer which contains a `namedGroup` field however, when creating/configuring the objects, the field is ignored. This PR just makes sure to include named groups if they are specified.

This pull request has now been integrated.

Changeset: 1ae4a6c4
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ae4a6c43ea21d4b147bcfcfaf1484c6e618dce5
Stats:     25 lines in 2 files changed: 22 ins; 1 del; 2 mod

8373101: JdkClient and JdkServer test classes ignore namedGroups field

Reviewed-by: rhalade

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

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

From smonteith at openjdk.org  Wed Dec 10 09:06:32 2025
From: smonteith at openjdk.org (Stuart Monteith)
Date: Wed, 10 Dec 2025 09:06:32 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <bRv8yWeVDg2jzpODllmKdUyYNv0gOncJMafGKRwAPk0=.06fdbd85-742c-4034-99cc-facc3ec753b6@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <bRv8yWeVDg2jzpODllmKdUyYNv0gOncJMafGKRwAPk0=.06fdbd85-742c-4034-99cc-facc3ec753b6@github.com>
Message-ID: <i-nY8MpYuxQW-rkgNhCLg7APYW3VS3L35SBpcp0dcbo=.39cdbdb4-0eed-4b1e-9ac3-a6e3ec7efbde@github.com>

On Sat, 6 Dec 2025 12:55:37 GMT, ExE Boss <duke at openjdk.org> wrote:

>> MemorySegments allocated from shared Arena from
>> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
>> 
>> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
>> 
>> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
>> 
>> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
>> |---------|-------|-------|-------|-------|-------|-------|
>> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
>> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
>> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
>> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
>> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
>> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
>> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
>> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
>> 
>> After:
>> 
>> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
>> |---------|-------|-------|-------|-------|-------|-------|
>> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
>> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
>> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
>> |    8  |    58...
>
> src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 89:
> 
>> 87:     @ForceInline
>> 88:     private int getCounter() {
>> 89:         return Thread.currentThread().hashCode() & mask;
> 
> Maybe use?[`System?::identityHashCode`] here?instead, as?the?`hashCode()`?method of?a?`Thread` can?be?overridden by?subclasses.
> Suggestion:
> 
>         return System.identityHashCode(Thread.currentThread()) & mask;
> 
> 
> [`System?::identityHashCode`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#identityHashCode%28java.lang.Object%29

Thanks - that's a good suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2605783455

From iklam at openjdk.org  Wed Dec 10 09:39:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 09:39:58 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
Message-ID: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>

In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"

https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171

Examples of subgraphs:

- `java.lang.Integer$IntegerCache::cache`
- `jdk.internal.module.ArchivedBootLayer::bootLayer`

The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.

To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.

Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

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

Commit messages:
 - 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer

Changes: https://git.openjdk.org/jdk/pull/28736/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373392
  Stats: 602 lines in 29 files changed: 368 ins; 186 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/28736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28736/head:pull/28736

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

From liach at openjdk.org  Wed Dec 10 15:27:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 15:27:56 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

Is IntegerCache.cache the only field that need to be adjusted according to system properties after loading from AOT archive?

src/java.base/share/classes/java/util/ImmutableCollections.java line 80:

> 78:     @AOTRuntimeSetup
> 79:     private static void runtimeSetup() {
> 80:          // to generate a reasonably random and well-mixed SALT, use an arbitrary

Suggestion:

        // to generate a reasonably random and well-mixed SALT, use an arbitrary

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

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3563043067
PR Review Comment: https://git.openjdk.org/jdk/pull/28736#discussion_r2607052565

From fferrari at openjdk.org  Wed Dec 10 16:02:01 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 10 Dec 2025 16:02:01 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <Xa0UFpj69YfwXXjOawdLc4mNWk42KLsnzrasqhiDlwI=.95293fc0-efcd-4178-8c55-8b264679e402@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
 <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
 <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>
 <Xa0UFpj69YfwXXjOawdLc4mNWk42KLsnzra
 sqhiDlwI=.95293fc0-efcd-4178-8c55-8b264679e402@github.com>
Message-ID: <igQgPfAuhi-1K8l3zV94zlARpv2wdYJx7E3lJNweScU=.231f0b6f-28ab-4734-8b02-7c1ebe4d86e7@github.com>

On Sun, 7 Dec 2025 02:53:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I have pushed the changes to proceed without resolution (9f298af59431507a66e3141c54abb59fcf3666f6, 2a012397baf0599e7dbe209975b3b353c3de5617, 1178544bda12bb4a6cd4d4400dad618292f29151, c33bf62c2831acefd90ec476fcfb6d853be873ee).
>> 
>> Since we are no longer resolving paths, we can incur in some relative paths complexity, which is perhaps not very friendly in debug message logs. Each relative include can potentially introduce some `../`, which will accumulate if paths are not resolved.
>> 
>> So we can end with paths like the following one:
>> 
>> /basedir/jdk/conf/security/../../../properties/dir1/../../jdk/conf/security/other.properties
>> 
>> 
>> Which could be simply logged as:
>> 
>> /basedir/jdk/conf/security/other.properties
>> 
>> 
>> So even when I already adjusted the test case, is perhaps better to undo the test changes and try to beautify the paths in debugging messages (but with `LinkOption.NOFOLLOW_LINKS`, to avoid confusion):
>> 
>> diff --git a/src/java.base/share/classes/java/security/Security.java b/src/java.base/share/classes/java/security/Security.java
>> index 36021f42862..533072b0d08 100644
>> --- a/src/java.base/share/classes/java/security/Security.java
>> +++ b/src/java.base/share/classes/java/security/Security.java
>> @@ -311,8 +311,13 @@ private static void loadFromUrl(URL url, LoadingMode mode)
>>          private static void debugLoad(boolean start, Object source) {
>>              if (sdebug != null) {
>> +                if (source instanceof Path path) {
>> +                    try {
>> +                        source = path.toRealPath(LinkOption.NOFOLLOW_LINKS);
>> +                    } catch (IOException ignore) {}
>> +                }
>>                  int level = activePaths.isEmpty() ? 1 : activePaths.size();
>>                  sdebug.println((start ?
>>                          ">".repeat(level) + " starting to process " :
>>                          "<".repeat(level) + " finished processing ") + source);
>>              }
>>          }
>> 
>> 
>> 
>> NOTE: even with `LinkOption.NOFOLLOW_LINKS`, `path.toRealPath()` fails for the problematic cases, so it would be just a best effort to make the paths clearer for the user.
>> 
>> What do you think?
>
> I thought `normalize` will remove those `..` inside?

The problem with [`Path::normalize`](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/file/Path.html#normalize()) is the following one:
> Eliminating ".." and a preceding name from a path may result in the path that locates a different file than the original path. This can arise when the preceding name is a symbolic link.

This can be demonstrated with the following files structure:


/tmp/a
??? /tmp/a/b -> /tmp/x/y
/tmp/x
??? /tmp/x/f2        (name=value)
??? /tmp/x/y
    ??? /tmp/x/y/f1  (include ../f2)


Which can be created with:


mkdir -p /tmp/x/y /tmp/a
echo 'include ../f2' >/tmp/x/y/f1
echo 'name=value' >/tmp/x/f2
ln -s /tmp/x/y /tmp/a/b


Now let's assume we are processing `/tmp/a/b/f1`, `include ../f2` is computed as `included`:


jshell -<<'EOF'
Path current = Path.of("/tmp/a/b/f1");
Path included = current.resolveSibling("../f2");
System.out.println("                                      included: " +
        included);
System.out.println("                         included.toRealPath(): " +
        included.toRealPath());
System.out.println("included.toRealPath(LinkOption.NOFOLLOW_LINKS): " +
        included.toRealPath(LinkOption.NOFOLLOW_LINKS));
System.out.println("                          included.normalize(): " +
        included.normalize());
EOF


Output:


                                      included: /tmp/a/b/../f2
                         included.toRealPath(): /tmp/x/f2
included.toRealPath(LinkOption.NOFOLLOW_LINKS): /tmp/a/b/../f2
                          included.normalize(): /tmp/a/f2


But `/tmp/a/f2` doesn't exist:


user at host:~$ cat /tmp/a/f2
cat: /tmp/a/f2: No such file or directory


To destroy the created directories and files use:


rm -rf /tmp/x /tmp/a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2607247993

From fferrari at openjdk.org  Wed Dec 10 16:02:02 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 10 Dec 2025 16:02:02 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <igQgPfAuhi-1K8l3zV94zlARpv2wdYJx7E3lJNweScU=.231f0b6f-28ab-4734-8b02-7c1ebe4d86e7@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
 <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
 <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>
 <Xa0UFpj69YfwXXjOawdLc4mNWk42KLsnzra
 sqhiDlwI=.95293fc0-efcd-4178-8c55-8b264679e402@github.com>
 <igQgPfAuhi-1K8l3zV94zlARpv2wdYJx7E3lJNweScU=.231f0b6f-28ab-4734-8b02-7c1ebe4d86e7@github.com>
Message-ID: <vkDToMl7k_tKoMbtBVgCrWw69MGl_wr9YEVNujc-cHg=.28c53f9d-0bc0-4c4c-a732-4ce590a1c8e3@github.com>

On Wed, 10 Dec 2025 15:58:34 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> I thought `normalize` will remove those `..` inside?
>
> The problem with [`Path::normalize`](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/file/Path.html#normalize()) is the following one:
>> Eliminating ".." and a preceding name from a path may result in the path that locates a different file than the original path. This can arise when the preceding name is a symbolic link.
> 
> This can be demonstrated with the following files structure:
> 
> 
> /tmp/a
> ??? /tmp/a/b -> /tmp/x/y
> /tmp/x
> ??? /tmp/x/f2        (name=value)
> ??? /tmp/x/y
>     ??? /tmp/x/y/f1  (include ../f2)
> 
> 
> Which can be created with:
> 
> 
> mkdir -p /tmp/x/y /tmp/a
> echo 'include ../f2' >/tmp/x/y/f1
> echo 'name=value' >/tmp/x/f2
> ln -s /tmp/x/y /tmp/a/b
> 
> 
> Now let's assume we are processing `/tmp/a/b/f1`, `include ../f2` is computed as `included`:
> 
> 
> jshell -<<'EOF'
> Path current = Path.of("/tmp/a/b/f1");
> Path included = current.resolveSibling("../f2");
> System.out.println("                                      included: " +
>         included);
> System.out.println("                         included.toRealPath(): " +
>         included.toRealPath());
> System.out.println("included.toRealPath(LinkOption.NOFOLLOW_LINKS): " +
>         included.toRealPath(LinkOption.NOFOLLOW_LINKS));
> System.out.println("                          included.normalize(): " +
>         included.normalize());
> EOF
> 
> 
> Output:
> 
> 
>                                       included: /tmp/a/b/../f2
>                          included.toRealPath(): /tmp/x/f2
> included.toRealPath(LinkOption.NOFOLLOW_LINKS): /tmp/a/b/../f2
>                           included.normalize(): /tmp/a/f2
> 
> 
> But `/tmp/a/f2` doesn't exist:
> 
> 
> user at host:~$ cat /tmp/a/f2
> cat: /tmp/a/f2: No such file or directory
> 
> 
> To destroy the created directories and files use:
> 
> 
> rm -rf /tmp/x /tmp/a

If you prefer, I can leave the code as it is now, without applying the [suggested change](#discussion_r2594151432).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2607254651

From iklam at openjdk.org  Wed Dec 10 17:32:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 17:32:38 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>
Message-ID: <BDaPZ6gkZ_1Bgj73wiO8ZwatxNyt5nxSzu_yXeEYHWk=.40e6594a-018e-4778-8a7b-4b2a50d806f1@github.com>

On Wed, 10 Dec 2025 15:25:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is IntegerCache.cache the only field that need to be adjusted according to system properties after loading from AOT archive?

I think so. The cache size for all other Number types are fixed and cannot be modified by the command-line.

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

PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3638192576

From liach at openjdk.org  Wed Dec 10 17:39:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 17:39:46 GMT
Subject: RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <SnsvxbACMDrUxVQHu5xUkSSGQPVJae2pOYtCCIykhfU=.ab0888de-9108-453c-b552-f94bc04bc8d9@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

The Java code changes look reasonable.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3563746741

From weijun at openjdk.org  Wed Dec 10 17:54:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 10 Dec 2025 17:54:04 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <vkDToMl7k_tKoMbtBVgCrWw69MGl_wr9YEVNujc-cHg=.28c53f9d-0bc0-4c4c-a732-4ce590a1c8e3@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
 <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
 <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>
 <Xa0UFpj69YfwXXjOawdLc4mNWk42KLsnzra
 sqhiDlwI=.95293fc0-efcd-4178-8c55-8b264679e402@github.com>
 <igQgPfAuhi-1K8l3zV94zlARpv2wdYJx7E3lJNweScU=.231f0b6f-28ab-4734-8b02-7c1ebe4d86e7@github.com>
 <vkDToMl7k_tKoMbtBVgCrWw69MGl_wr9YEVNujc-cHg=.28c53f9d-0bc0-4c4c-a732-4ce590a1c8e3@github.com>
Message-ID: <orjopaRf9KCnNKMHw0FbaQQ3s00WDzK576L-WlARlK0=.25eb9a94-18f9-4f26-b972-9b6022004a11@github.com>

On Wed, 10 Dec 2025 15:59:57 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> The problem with [`Path::normalize`](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/file/Path.html#normalize()) is the following one:
>>> Eliminating ".." and a preceding name from a path may result in the path that locates a different file than the original path. This can arise when the preceding name is a symbolic link.
>> 
>> This can be demonstrated with the following files structure:
>> 
>> 
>> /tmp/a
>> ??? /tmp/a/b -> /tmp/x/y
>> /tmp/x
>> ??? /tmp/x/f2        (name=value)
>> ??? /tmp/x/y
>>     ??? /tmp/x/y/f1  (include ../f2)
>> 
>> 
>> Which can be created with:
>> 
>> 
>> mkdir -p /tmp/x/y /tmp/a
>> echo 'include ../f2' >/tmp/x/y/f1
>> echo 'name=value' >/tmp/x/f2
>> ln -s /tmp/x/y /tmp/a/b
>> 
>> 
>> Now let's assume we are processing `/tmp/a/b/f1`, `include ../f2` is computed as `included`:
>> 
>> 
>> jshell -<<'EOF'
>> Path current = Path.of("/tmp/a/b/f1");
>> Path included = current.resolveSibling("../f2");
>> System.out.println("                                      included: " +
>>         included);
>> System.out.println("                         included.toRealPath(): " +
>>         included.toRealPath());
>> System.out.println("included.toRealPath(LinkOption.NOFOLLOW_LINKS): " +
>>         included.toRealPath(LinkOption.NOFOLLOW_LINKS));
>> System.out.println("                          included.normalize(): " +
>>         included.normalize());
>> EOF
>> 
>> 
>> Output:
>> 
>> 
>>                                       included: /tmp/a/b/../f2
>>                          included.toRealPath(): /tmp/x/f2
>> included.toRealPath(LinkOption.NOFOLLOW_LINKS): /tmp/a/b/../f2
>>                           included.normalize(): /tmp/a/f2
>> 
>> 
>> But `/tmp/a/f2` doesn't exist:
>> 
>> 
>> user at host:~$ cat /tmp/a/f2
>> cat: /tmp/a/f2: No such file or directory
>> 
>> 
>> To destroy the created directories and files use:
>> 
>> 
>> rm -rf /tmp/x /tmp/a
>
> If you prefer, I can leave the code as it is now, without applying the [suggested change](#discussion_r2594151432).

I'm a little confused. Now that we have agreed to no longer revolving symlinks, `/tmp/a/b/../f2` should indeed be `/tmp/a/f2`. Since it does not exist, we simply fail. Why is this a problem? Did I miss anything?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2607641780

From jnimeh at openjdk.org  Wed Dec 10 20:31:43 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 10 Dec 2025 20:31:43 GMT
Subject: RFR: 8368493: Disable most test JSSE debug output by default,
 and increase the test default maximum output log size [v2]
In-Reply-To: <5hwoLpZ68DndKJfKLXqzv0rgmt2qHg9dVtIRA3ksJqo=.94bc5bf3-e52d-457b-954c-4ff7eda8f20d@github.com>
References: <zcd0Bt3gLzyvL1N9Ky4xhh2FgvneDHW0qBIQYZNkG5o=.a37e1689-6d92-4dd8-8153-44788c605f62@github.com>
 <5hwoLpZ68DndKJfKLXqzv0rgmt2qHg9dVtIRA3ksJqo=.94bc5bf3-e52d-457b-954c-4ff7eda8f20d@github.com>
Message-ID: <KJVKAm_hevLDcg9-Mylx-IfyI4kWpHIe1Oou0ELVfNw=.53116137-8f34-478a-818f-c164e9602fe4@github.com>

On Wed, 15 Oct 2025 17:19:42 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> See the bug for more info.  This will allow for:
>> 
>> 1. extra/unneeded JSSE debug output will not be added to each test run, saving space and noise.
>> 2. make it easier to get the full JSSE debug output when enabled.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusted sizes to be more reasonable

I went through the tests and it looks like you've caught everything.  There are other tests that do debugging, but they sit outside the SSL family of tests that this issue is meant to cover.  Looks good to me overall.

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27455#pullrequestreview-3564360312

From coffeys at openjdk.org  Wed Dec 10 20:46:40 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 10 Dec 2025 20:46:40 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v4]
In-Reply-To: <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>
Message-ID: <F6FeOol89lIEmpzGZSO5QPikUXdIdeV9J2F2b3U99uc=.f1c1f13c-e018-4404-8577-7bf7a0f6bb13@github.com>

On Fri, 5 Dec 2025 17:00:18 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only the last few sentences of javadoc are outdated

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 210:

> 208: 
> 209:         if (socket instanceof SSLSocket sslSocket && sslSocket.isConnected()) {
> 210:             session = sslSocket.getHandshakeSession();

subtle change in the refactoring now that the session non-null check is delayed until the new `findTrustedCertificate` call. 
The `SSLAlgorithmConstraints.forEngine/forSocket/forQUIC` methods also reference the session before the `findTrustedCertificate` call . Have you ensured that a null session can't cause issue there ?

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 261:

> 259:     }
> 260: 
> 261:     private void findTrustedCertificate(X509Certificate[] chain,

good to see the refactoring take place. However the `findTrustedCertificate` method name suggests a return value (for me at least)

wondering is something like `ensureTrustedCertificate` or similar might be better for a method returning void ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2608145437
PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2608151422

From abarashev at openjdk.org  Wed Dec 10 20:57:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 10 Dec 2025 20:57:05 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v4]
In-Reply-To: <F6FeOol89lIEmpzGZSO5QPikUXdIdeV9J2F2b3U99uc=.f1c1f13c-e018-4404-8577-7bf7a0f6bb13@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>
 <F6FeOol89lIEmpzGZSO5QPikUXdIdeV9J2F2b3U99uc=.f1c1f13c-e018-4404-8577-7bf7a0f6bb13@github.com>
Message-ID: <n05DyL-r4guQa2qqJ8kJtszvNPn0ZePkpWX5e4DSDB8=.35c66a66-4199-464e-a671-c1fbdfd7e4bb@github.com>

On Wed, 10 Dec 2025 20:41:01 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only the last few sentences of javadoc are outdated
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 210:
> 
>> 208: 
>> 209:         if (socket instanceof SSLSocket sslSocket && sslSocket.isConnected()) {
>> 210:             session = sslSocket.getHandshakeSession();
> 
> subtle change in the refactoring now that the session non-null check is delayed until the new `findTrustedCertificate` call. 
> The `SSLAlgorithmConstraints.forEngine/forSocket/forQUIC` methods also reference the session before the `findTrustedCertificate` call . Have you ensured that a null session can't cause issue there ?

Yes, we have a check for session not being null there: `session instanceof ExtendedSSLSession`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2608177687

From abarashev at openjdk.org  Wed Dec 10 21:02:43 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 10 Dec 2025 21:02:43 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v4]
In-Reply-To: <F6FeOol89lIEmpzGZSO5QPikUXdIdeV9J2F2b3U99uc=.f1c1f13c-e018-4404-8577-7bf7a0f6bb13@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>
 <F6FeOol89lIEmpzGZSO5QPikUXdIdeV9J2F2b3U99uc=.f1c1f13c-e018-4404-8577-7bf7a0f6bb13@github.com>
Message-ID: <1GGjmUG9-1OqdD2YMcjUHEjicYuunCPhskgCF4Mjd84=.a8ed9497-c227-4a89-a370-0251a15e644a@github.com>

On Wed, 10 Dec 2025 20:43:25 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only the last few sentences of javadoc are outdated
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 261:
> 
>> 259:     }
>> 260: 
>> 261:     private void findTrustedCertificate(X509Certificate[] chain,
> 
> good to see the refactoring take place. However the `findTrustedCertificate` method name suggests a return value (for me at least)
> 
> wondering is something like `ensureTrustedCertificate` or similar might be better for a method returning void ?

Usually methods returning value start with `get`, `ensureTrustedCertificate` sounds somewhat vague to me actually.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2608196088

From mullan at openjdk.org  Wed Dec 10 21:09:32 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 10 Dec 2025 21:09:32 GMT
Subject: RFR: 8373231: ECDSAOperations::toAffinePoint is redundant
In-Reply-To: <L9D4AN28beu8Sq1EBiJ3vrrbb7CJoqos5ofR_VUmVQo=.f274cb90-7418-431b-a22a-fb10662b35a0@github.com>
References: <t4rc4iW6XhuqdU0gZ3A2WHu_uVVjJXQ05HgF7jOdV1A=.04dfb8fa-9815-453b-a13e-a02894d43063@github.com>
 <L9D4AN28beu8Sq1EBiJ3vrrbb7CJoqos5ofR_VUmVQo=.f274cb90-7418-431b-a22a-fb10662b35a0@github.com>
Message-ID: <iRelnkZvSkX2ywvEmjF0ztMmGvnT00VFDCoKU-AV8xw=.b5a158c5-5080-48c7-9cd7-f750814f7da8@github.com>

On Tue, 9 Dec 2025 15:29:59 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Correct me if I'm wrong, this seems to be changing public API, shouldn't it have a csr then?

It's a class in an internal package (`sun.security.ec`), so should not need a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28691#issuecomment-3638961259

From hchao at openjdk.org  Wed Dec 10 21:12:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 10 Dec 2025 21:12:20 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v22]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <xXc8ZoZfwWR19Sf0sfEbeaH5omp3V2CdaRiFUxseVDA=.733b7c31-3f76-4111-a289-60791e8e8b79@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

  Use engineEncapsulationSize() and engineSecretSize()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/909faa51..d59602b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=20-21

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

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

From mullan at openjdk.org  Wed Dec 10 21:40:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 10 Dec 2025 21:40:54 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v22]
In-Reply-To: <xXc8ZoZfwWR19Sf0sfEbeaH5omp3V2CdaRiFUxseVDA=.733b7c31-3f76-4111-a289-60791e8e8b79@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <xXc8ZoZfwWR19Sf0sfEbeaH5omp3V2CdaRiFUxseVDA=.733b7c31-3f76-4111-a289-60791e8e8b79@github.com>
Message-ID: <-BHn7e2Xg8oBWHWMgsI0BBzGJwFspg2phtUEahM9qcA=.707c0636-4215-4554-9e21-7b87d5f26009@github.com>

On Wed, 10 Dec 2025 21:12:20 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use engineEncapsulationSize() and engineSecretSize()

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27614#pullrequestreview-3564591114

From fferrari at openjdk.org  Wed Dec 10 23:03:04 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 10 Dec 2025 23:03:04 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <orjopaRf9KCnNKMHw0FbaQQ3s00WDzK576L-WlARlK0=.25eb9a94-18f9-4f26-b972-9b6022004a11@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
 <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
 <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>
 <Xa0UFpj69YfwXXjOawdLc4mNWk42KLsnzra
 sqhiDlwI=.95293fc0-efcd-4178-8c55-8b264679e402@github.com>
 <igQgPfAuhi-1K8l3zV94zlARpv2wdYJx7E3lJNweScU=.231f0b6f-28ab-4734-8b02-7c1ebe4d86e7@github.com>
 <vkDToMl7k_tKoMbtBVgCrWw69MGl_wr9YEVNujc-cHg=.28c53f9d-0bc0-4c4c-a732-4ce590a1c8e3@github.com>
 <orjopaRf9KCnNKMHw0FbaQQ3s00WDzK576L-WlARlK0=.25eb9a94-18f9-4f26-b972-9b6022004a11@github.com>
Message-ID: <c5ghVMszkomaBgFiC1Y_D8BvUZtqmkiZKoS0lwKQJNU=.c829c7a0-6963-4f67-a451-2e9c72d5e339@github.com>

On Wed, 10 Dec 2025 17:46:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> If you prefer, I can leave the code as it is now, without applying the [suggested change](#discussion_r2594151432).
>
> I'm a little confused. Now that we have agreed to no longer revolve symlinks, `/tmp/a/b/../f2` should indeed be `/tmp/a/f2`. Since it does not exist, we simply fail. Why is this a problem? Did I miss anything?

Hmm, I also got confused for a moment, it seems important to make a distinction between file links and directory links, and how each platform handles each of them.

We are no longer resolving any type of link, here:

https://github.com/openjdk/jdk/blob/c33bf62c2831acefd90ec476fcfb6d853be873ee/src/java.base/share/classes/java/security/Security.java#L250-L258

`currentPath.resolveSibling(path)` is equivalent to `currentPath.getParent().resolve(path)` when `currentPath` has a parent.

If `currentPath` is `/tmp/a/b/f1` and `path` is `../f2`, after line 257, path will be `/tmp/a/b/../f2`.

In the [previous _Linux_ example](#discussion_r2607247993), `/tmp/a/b` is a **directory** symbolic link to `/tmp/x/y`, so `/tmp/a/b/../f2` still reads `/tmp/x/f2` (at the OS level) when opening the file.

<details>
<summary>Extension of that <em>Linux</em> example's <code>jshell</code> snippet showing how <code>/tmp/a/b/../f2</code> can be opened</summary>


jshell -<<'EOF'
Path current = Path.of("/tmp/a/b/f1");
Path included = current.resolveSibling("../f2");

Map<String, Path> opts = new LinkedHashMap<String, Path>();
opts.put("included", included);
opts.put("included.toRealPath()", included.toRealPath());
opts.put("included.toRealPath(LinkOption.NOFOLLOW_LINKS)",
        included.toRealPath(LinkOption.NOFOLLOW_LINKS));
opts.put("included.normalize()", included.normalize());

for (Map.Entry<String, Path> opt : opts.entrySet()) {
    System.out.println();
    System.out.println(opt.getKey() + " -> " + opt.getValue());
    Files.newInputStream(opt.getValue());
    System.out.println("succesfully opened");
}
EOF


Output:


included -> /tmp/a/b/../f2
succesfully opened

included.toRealPath() -> /tmp/x/f2
succesfully opened

included.toRealPath(LinkOption.NOFOLLOW_LINKS) -> /tmp/a/b/../f2
succesfully opened

included.normalize() -> /tmp/a/f2
Exception java.nio.file.NoSuchFileException: /tmp/a/f2
      at UnixException.translateToIOException (UnixException.java:92)
      at UnixException.rethrowAsIOException (UnixException.java:106)
      at UnixException.rethrowAsIOException (UnixException.java:111)
      at UnixFileSystemProvider.newByteChannel (UnixFileSystemProvider.java:261)
      at Files.newByteChannel (Files.java:380)
      at Files.newByteChannel (Files.java:432)
      at FileSystemProvider.newInputStream (FileSystemProvider.java:420)
      at Files.newInputStream (Files.java:160)
      at (#8:4)


</details>

With that observation, I tried to re-introduce 7abb62c069ad35f4ec34f6cd9b9f6d05febceecc, which is similar to this case, but in _Windows_ and with a **directory** junction ([not quite the same as a symbolic link](https://ss64.com/nt/mklink.html)). However, it's failing with:


Caused by: java.nio.file.NoSuchFileException: C:\Users\test\AppData\Local\Temp\JDK-8352728-tmp-3508915478448537696\jdk-parent-dir\jdk\conf\security\link-to-other-dir..\relatively.included.properties


Thus, the meaning of `parent-dir/link-to-other-dir/../file` is platform dependent.

What we stopped doing is the resolution of `currentPath` before line 257, so if `/tmp/a/b/f1` was a **file** symbolic link pointing somewhere else, it wouldn't be resolved before getting its parent to compute the relative `include`. **File** symbolic links is [what I previously tested with Git includes](#discussion_r2593849381).

For everyone's sanity, here is the same _Linux_ **directory** symbolic links example with Git includes, showing how Git behaves the same as the current `java.security.Security` code:


mkdir -p /tmp/x/y /tmp/a
echo -e '[include]\n	path = ../f2' >/tmp/x/y/f1
echo -e '[section]\n	key = "/tmp/x/f2 was included"' >/tmp/x/f2
ln -s /tmp/x/y /tmp/a/b

# Backup user's config and rewrite it including /tmp/a/b/f1 (-> /tmp/x/y/f1)
mv ~/.gitconfig{,.bak}
echo -e '[include]\n	path = /tmp/a/b/f1' >~/.gitconfig

# Check if file is included (ensure CWD is anything else)
git -C / config section.key

# Cleanup and restore user's config
rm -rf /tmp/x /tmp/a
mv ~/.gitconfig{.bak,}


Output:


/tmp/x/f2 was included


----

I like this behavior because it leaves the interpretation of the paths to the underlying platform, with the simplest API (just open the file).

Regarding how to display the paths in debugging logs, I'm ok with:

* Attempting `path.toRealPath(LinkOption.NOFOLLOW_LINKS)` (for this example, it would log `/tmp/a/b/../f2`)
* Attempting `path.toRealPath()` (for this example, it would log `/tmp/x/f2`)
    * Originally, I mistakenly thought this would be confusing, but it wouldn't, it's the ultimate path of the file being processed (I was thinking that logging something equivalent to `currentPath.toRealPath().resolveSibling(path)` would be confusing, but this would be equivalent to `currentPath.resolveSibling(path).toRealPath()` instead)
* Leaving the paths as they are (for this example, it would log `/tmp/a/b/../f2`)

But `path.normalize()` would produce inaccurate debugging output in _Linux_ (for this example, it would log `/tmp/a/f2` which doesn't exist).

I hope everything is clearer now, there are many subtle details.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2608505651

From wetmore at openjdk.org  Wed Dec 10 23:41:05 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 10 Dec 2025 23:41:05 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v22]
In-Reply-To: <xXc8ZoZfwWR19Sf0sfEbeaH5omp3V2CdaRiFUxseVDA=.733b7c31-3f76-4111-a289-60791e8e8b79@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <xXc8ZoZfwWR19Sf0sfEbeaH5omp3V2CdaRiFUxseVDA=.733b7c31-3f76-4111-a289-60791e8e8b79@github.com>
Message-ID: <2EwvsSu36rVTieOD-sbXf6bDbysHb_w_6rQQNaLR9fE=.c4ee74b6-ac8d-4d77-93d6-39d7a0c94d75@github.com>

On Wed, 10 Dec 2025 21:12:20 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use engineEncapsulationSize() and engineSecretSize()

New changes look good.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27614#pullrequestreview-3564931774

From weijun at openjdk.org  Thu Dec 11 01:13:26 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 Dec 2025 01:13:26 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <c5ghVMszkomaBgFiC1Y_D8BvUZtqmkiZKoS0lwKQJNU=.c829c7a0-6963-4f67-a451-2e9c72d5e339@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
 <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
 <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>
 <Xa0UFpj69YfwXXjOawdLc4mNWk42KLsnzra
 sqhiDlwI=.95293fc0-efcd-4178-8c55-8b264679e402@github.com>
 <igQgPfAuhi-1K8l3zV94zlARpv2wdYJx7E3lJNweScU=.231f0b6f-28ab-4734-8b02-7c1ebe4d86e7@github.com>
 <vkDToMl7k_tKoMbtBVgCrWw69MGl_wr9YEVNujc-cHg=.28c53f9d-0bc0-4c4c-a732-4ce590a1c8e3@github.com>
 <orjopaRf9KCnNKMHw0FbaQQ3s00WDzK576L-WlARlK0=.25eb9a94-18f9-4f26-b972-9b6022004a11@github.com>
 <c5ghVMszkomaBgFiC1Y_D8BvUZtqmkiZKoS0lwKQJNU=.c829c7a0-6963-4f67-a451-2e9c72d5e339@github.com>
Message-ID: <rRS3rLb4LmfLVlmtH82PooOxKyGkjKDkgSRBEApybEc=.b30fa29f-a06f-4d58-9932-fd00a2fcddd9@github.com>

On Wed, 10 Dec 2025 23:00:11 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> I'm a little confused. Now that we have agreed to no longer revolve symlinks, `/tmp/a/b/../f2` should indeed be `/tmp/a/f2`. Since it does not exist, we simply fail. Why is this a problem? Did I miss anything?
>
> Hmm, I also got confused for a moment, it seems important to make a distinction between file links and directory links, and how each platform handles each of them.
> 
> We are no longer resolving any type of link, here:
> 
> https://github.com/openjdk/jdk/blob/c33bf62c2831acefd90ec476fcfb6d853be873ee/src/java.base/share/classes/java/security/Security.java#L250-L258
> 
> `currentPath.resolveSibling(path)` is equivalent to `currentPath.getParent().resolve(path)` when `currentPath` has a parent.
> 
> If `currentPath` is `/tmp/a/b/f1` and `path` is `../f2`, after line 257, path will be `/tmp/a/b/../f2`.
> 
> In the [previous _Linux_ example](#discussion_r2607247993), `/tmp/a/b` is a **directory** symbolic link to `/tmp/x/y`, so `/tmp/a/b/../f2` still reads `/tmp/x/f2` (at the OS level) when opening the file.
> 
> <details>
> <summary>Extension of that <em>Linux</em> example's <code>jshell</code> snippet showing how <code>/tmp/a/b/../f2</code> can be opened</summary>
> 
> 
> jshell -<<'EOF'
> Path current = Path.of("/tmp/a/b/f1");
> Path included = current.resolveSibling("../f2");
> 
> Map<String, Path> opts = new LinkedHashMap<String, Path>();
> opts.put("included", included);
> opts.put("included.toRealPath()", included.toRealPath());
> opts.put("included.toRealPath(LinkOption.NOFOLLOW_LINKS)",
>         included.toRealPath(LinkOption.NOFOLLOW_LINKS));
> opts.put("included.normalize()", included.normalize());
> 
> for (Map.Entry<String, Path> opt : opts.entrySet()) {
>     System.out.println();
>     System.out.println(opt.getKey() + " -> " + opt.getValue());
>     Files.newInputStream(opt.getValue());
>     System.out.println("succesfully opened");
> }
> EOF
> 
> 
> Output:
> 
> 
> included -> /tmp/a/b/../f2
> succesfully opened
> 
> included.toRealPath() -> /tmp/x/f2
> succesfully opened
> 
> included.toRealPath(LinkOption.NOFOLLOW_LINKS) -> /tmp/a/b/../f2
> succesfully opened
> 
> included.normalize() -> /tmp/a/f2
> Exception java.nio.file.NoSuchFileException: /tmp/a/f2
>       at UnixException.translateToIOException (UnixException.java:92)
>       at UnixException.rethrowAsIOException (UnixException.java:106)
>       at UnixException.rethrowAsIOException (UnixException.java:111)
>       at UnixFileSystemProvider.newByteChannel (UnixFileSystemProvider.java:261)
>       at Files.newByteChannel (Files.java:380)
>       at Files.newByteChannel (Files.java:432)
>       at FileSystemProvider.newInputStream (FileSystemProvider.java:420)
>       at Files.newInputStream (Files.java:160)
>       at (#8:4)
> 
> 
> </details>
> 
> With that observation, I tried to re-introduce 7abb62c069ad3...

Thanks for the detailed explanation.

I like your attitude to leave the path resolution to the simplest API. 

For debugging output, I prefer the 3rd choice for the same reason that it's the simplest. Also, it preserves the original include form. I would assume the reader wants to see this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2608776622

From fferrari at openjdk.org  Thu Dec 11 12:11:41 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 11 Dec 2025 12:11:41 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v14]
In-Reply-To: <rRS3rLb4LmfLVlmtH82PooOxKyGkjKDkgSRBEApybEc=.b30fa29f-a06f-4d58-9932-fd00a2fcddd9@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <SEr6-azuGBgkwU2apktQQzQkMXjpZ9J5xowoOMyWqw0=.d6b594e1-b0b8-47d4-91ce-597bd03a70ec@github.com>
 <xk1S9lGPS5DohG1PNQdyDbYg3ql6GAmiYgOidS5NqM4=.5ff469ac-a232-46bb-9876-e0394c3778aa@github.com>
 <Ce8ErIOWgDa-JnXM1zDclM0xd8HjHbzn8mPYOfxETss=.1c8621db-a2f4-4a31-8d42-25661d839b6f@github.com>
 <FkI-CgmScEcPMPgM7HMWDxh7HCXWVaR_Mq2oDR_F53c=.f6f05493-a018-43db-8cb5-3a0024bee15e@github.com>
 <ErljKBykJabH5NBdvMJmBsjUWTgW0TxIn4y4xgCxXxs=.4e691938-483b-415d-b73e-f7fc4cbb8de1@github.com>
 <BXw9158aGyzm_gQ5GrMRNsybFdrJzfYQ6xIz6Xk_8Js=.e169d48b-3b66-417b-9cdb-b2fd3d9a3f20@github.com>
 <PBxE-mlYU1cxQEFXZtstLUnLz2RlBoJ3R-SN4HCo3A8=.27952d0d-cd0d-41a3-9b49-f7fac778402b@github.com>
 <pgQEKx0-obdEhcRQNWe9P4DP1bk413yiqxHLHJC61Oo=.f1ff9a70-f738-44a5-9ddf-afed2aa72792@github.com>
 <SYqL_u4HSrvVWvkA1YTYR-me7OYssz16UZX4bux5BCk=.aa01b43f-d7af-4692-bda0-cacd2a0bcde6@github.com>
 <Xa0UFpj69YfwXXjOawdLc4mNWk42KLsnzra
 sqhiDlwI=.95293fc0-efcd-4178-8c55-8b264679e402@github.com>
 <igQgPfAuhi-1K8l3zV94zlARpv2wdYJx7E3lJNweScU=.231f0b6f-28ab-4734-8b02-7c1ebe4d86e7@github.com>
 <vkDToMl7k_tKoMbtBVgCrWw69MGl_wr9YEVNujc-cHg=.28c53f9d-0bc0-4c4c-a732-4ce590a1c8e3@github.com>
 <orjopaRf9KCnNKMHw0FbaQQ3s00WDzK576L-WlARlK0=.25eb9a94-18f9-4f26-b972-9b6022004a11@github.com>
 <c5ghVMszkomaBgFiC1Y_D8BvUZtqmkiZKoS0lwKQJNU=.c829c7a0-6963-4f67-a451-2e9c72d5e339@github.com>
 <rRS3rLb4LmfLVlmtH82PooOxKyGkjKDkgSRBEApybEc=.b30fa29f-a06f-4d58-9932-fd00a2fcddd9@github.com>
Message-ID: <CKjz6ni3cnkzJa6fdpDZNXj7-_lnkWeKmkMSSS9QEns=.c56b8579-61a2-42ab-b28d-283d7f505bce@github.com>

On Thu, 11 Dec 2025 01:09:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hmm, I also got confused for a moment, it seems important to make a distinction between file links and directory links, and how each platform handles each of them.
>> 
>> We are no longer resolving any type of link, here:
>> 
>> https://github.com/openjdk/jdk/blob/c33bf62c2831acefd90ec476fcfb6d853be873ee/src/java.base/share/classes/java/security/Security.java#L250-L258
>> 
>> `currentPath.resolveSibling(path)` is equivalent to `currentPath.getParent().resolve(path)` when `currentPath` has a parent.
>> 
>> If `currentPath` is `/tmp/a/b/f1` and `path` is `../f2`, after line 257, path will be `/tmp/a/b/../f2`.
>> 
>> In the [previous _Linux_ example](#discussion_r2607247993), `/tmp/a/b` is a **directory** symbolic link to `/tmp/x/y`, so `/tmp/a/b/../f2` still reads `/tmp/x/f2` (at the OS level) when opening the file.
>> 
>> <details>
>> <summary>Extension of that <em>Linux</em> example's <code>jshell</code> snippet showing how <code>/tmp/a/b/../f2</code> can be opened</summary>
>> 
>> 
>> jshell -<<'EOF'
>> Path current = Path.of("/tmp/a/b/f1");
>> Path included = current.resolveSibling("../f2");
>> 
>> Map<String, Path> opts = new LinkedHashMap<String, Path>();
>> opts.put("included", included);
>> opts.put("included.toRealPath()", included.toRealPath());
>> opts.put("included.toRealPath(LinkOption.NOFOLLOW_LINKS)",
>>         included.toRealPath(LinkOption.NOFOLLOW_LINKS));
>> opts.put("included.normalize()", included.normalize());
>> 
>> for (Map.Entry<String, Path> opt : opts.entrySet()) {
>>     System.out.println();
>>     System.out.println(opt.getKey() + " -> " + opt.getValue());
>>     Files.newInputStream(opt.getValue());
>>     System.out.println("succesfully opened");
>> }
>> EOF
>> 
>> 
>> Output:
>> 
>> 
>> included -> /tmp/a/b/../f2
>> succesfully opened
>> 
>> included.toRealPath() -> /tmp/x/f2
>> succesfully opened
>> 
>> included.toRealPath(LinkOption.NOFOLLOW_LINKS) -> /tmp/a/b/../f2
>> succesfully opened
>> 
>> included.normalize() -> /tmp/a/f2
>> Exception java.nio.file.NoSuchFileException: /tmp/a/f2
>>       at UnixException.translateToIOException (UnixException.java:92)
>>       at UnixException.rethrowAsIOException (UnixException.java:106)
>>       at UnixException.rethrowAsIOException (UnixException.java:111)
>>       at UnixFileSystemProvider.newByteChannel (UnixFileSystemProvider.java:261)
>>       at Files.newByteChannel (Files.java:380)
>>       at Files.newByteChannel (Files.java:432)
>>       at FileSystemProvider.newInputStream (FileSystemProvider.java:420)
>>       at Files.newInp...
>
> Thanks for the detailed explanation.
> 
> I like your attitude to leave the path resolution to the simplest API. 
> 
> For debugging output, I prefer the 3rd choice for the same reason that it's the simplest. Also, it preserves the original include form. I would assume the reader wants to see this.

Great, so I'll leave it as it currently is, and update the PR description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2610336040

From vyazici at openjdk.org  Thu Dec 11 12:25:21 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 11 Dec 2025 12:25:21 GMT
Subject: RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
Message-ID: <g2mxar0e70OCXO4yVUFxZxs4ncfn1mNAI8ls6FgdE1U=.7d6e209d-c989-47f4-b4e8-24d06f601204@github.com>

Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path.

### Tips for reviewers

1. Start from `SimpleSSLContext.java`
2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext`

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

Commit messages:
 - Overhaul `SimpleSSLContext` and its usages

Changes: https://git.openjdk.org/jdk/pull/28765/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28765&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372661
  Stats: 1131 lines in 205 files changed: 83 ins; 712 del; 336 mod
  Patch: https://git.openjdk.org/jdk/pull/28765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28765/head:pull/28765

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

From vyazici at openjdk.org  Thu Dec 11 12:25:22 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 11 Dec 2025 12:25:22 GMT
Subject: RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <g2mxar0e70OCXO4yVUFxZxs4ncfn1mNAI8ls6FgdE1U=.7d6e209d-c989-47f4-b4e8-24d06f601204@github.com>
References: <g2mxar0e70OCXO4yVUFxZxs4ncfn1mNAI8ls6FgdE1U=.7d6e209d-c989-47f4-b4e8-24d06f601204@github.com>
Message-ID: <-_8Armb1O6HfaLmE8DIlpWHLR1cxUpNvJr2uruKX8ho=.ebd3c950-5e39-4300-ae1c-2baadcaeaf98@github.com>

On Thu, 11 Dec 2025 09:45:54 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path.
> 
> ### Tips for reviewers
> 
> 1. Start from `SimpleSSLContext.java`
> 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext`

Tier1-2 is clear on 326fd60e352.

test/lib/jdk/test/lib/net/SimpleSSLContext.java line 1:

> 1: /*

[JDK-8372661] suggests `newSSLContext` as the method name, though I opted for `findSSLContext` and `loadSSLContext` method names, because

1. `newSSLContext` clashes with IDEs auto-completion when one types `ClassName.new`
2. `findSSLContext` makes the intent more clear, because we indeed search for a key store file, and then load it
3. `loadSSLContext` makes the intent more clear, because it only and only tries to load an `SSLContext` from the provided key store file; it doesn't do a search or anything else.

[JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661

test/lib/jdk/test/lib/net/SimpleSSLContext.java line 77:

> 75:      * one cannot be loaded
> 76:      */
> 77:     public static SSLContext findSSLContext(String keyStoreFileRelPath, String protocol) {

This is made public to enable loading a key store file from alternative locations, which is required by whitebox tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28765#issuecomment-3641655710
PR Review Comment: https://git.openjdk.org/jdk/pull/28765#discussion_r2609917169
PR Review Comment: https://git.openjdk.org/jdk/pull/28765#discussion_r2609927102

From dfuchs at openjdk.org  Thu Dec 11 13:06:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Dec 2025 13:06:36 GMT
Subject: RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <g2mxar0e70OCXO4yVUFxZxs4ncfn1mNAI8ls6FgdE1U=.7d6e209d-c989-47f4-b4e8-24d06f601204@github.com>
References: <g2mxar0e70OCXO4yVUFxZxs4ncfn1mNAI8ls6FgdE1U=.7d6e209d-c989-47f4-b4e8-24d06f601204@github.com>
Message-ID: <VChai_0l1bvp_1UcvuwG_u6CfenLU3Z6TpDmMugZ1GQ=.00298120-c6ce-4668-8eb5-cd155bf67c53@github.com>

On Thu, 11 Dec 2025 09:45:54 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path.
> 
> ### Tips for reviewers
> 
> 1. Start from `SimpleSSLContext.java`
> 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext`

I would prefer to split this PR into two fixes:

 - a first fix that simply adds the new API to SimpleSSLContext, without removing the old API.
 - a second fix that do all the rest: remove the old API and update the tests.
 
This would allow us to easily backport the first fix, and new tests would not need adaptation when they are later being backported provided that the first fix has been backported first.

You could enjoy using dependent PRs for this :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/28765#issuecomment-3641822078

From vyazici at openjdk.org  Thu Dec 11 18:13:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 11 Dec 2025 18:13:26 GMT
Subject: RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext" [v2]
In-Reply-To: <g2mxar0e70OCXO4yVUFxZxs4ncfn1mNAI8ls6FgdE1U=.7d6e209d-c989-47f4-b4e8-24d06f601204@github.com>
References: <g2mxar0e70OCXO4yVUFxZxs4ncfn1mNAI8ls6FgdE1U=.7d6e209d-c989-47f4-b4e8-24d06f601204@github.com>
Message-ID: <Gi8BJtIRBoL6dTwuB6ic-0PTBQU16TGkAxbiBY-4d0E=.b461ddca-afc7-4537-9a99-4afa34659f79@github.com>

> Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path.
> 
> ### Tips for reviewers
> 
> 1. Start from `SimpleSSLContext.java`
> 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext`

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

  Reverted all changes and only kept `SimpleSSLContext` enhancements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28765/files
  - new: https://git.openjdk.org/jdk/pull/28765/files/326fd60e..d4c9b312

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

  Stats: 1093 lines in 205 files changed: 734 ins; 54 del; 305 mod
  Patch: https://git.openjdk.org/jdk/pull/28765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28765/head:pull/28765

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

From vyazici at openjdk.org  Thu Dec 11 18:17:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 11 Dec 2025 18:17:49 GMT
Subject: RFR: 8372661: Add a null-safe static factory method to
 "jdk.test.lib.net.SimpleSSLContext"
In-Reply-To: <VChai_0l1bvp_1UcvuwG_u6CfenLU3Z6TpDmMugZ1GQ=.00298120-c6ce-4668-8eb5-cd155bf67c53@github.com>
References: <g2mxar0e70OCXO4yVUFxZxs4ncfn1mNAI8ls6FgdE1U=.7d6e209d-c989-47f4-b4e8-24d06f601204@github.com>
 <VChai_0l1bvp_1UcvuwG_u6CfenLU3Z6TpDmMugZ1GQ=.00298120-c6ce-4668-8eb5-cd155bf67c53@github.com>
Message-ID: <mnUZZcXr3Gyyl_tQ9D8DFjkMgMh7ukh-evmP57f3Q4I=.dc70519b-47bd-4183-b520-21c3739dcd1b@github.com>

On Thu, 11 Dec 2025 13:01:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Overhauls `SimpleSSLContext` to remove the need for null checks at the call site, and to accept a key store file search path, which removes the need to copy-paste `SimpleSSLContext` just to change the search path.
>> 
>> ### Tips for reviewers
>> 
>> 1. Start from `SimpleSSLContext.java`
>> 2. See how `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java` is renamed to `test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java` and how `@compile/module=java.net.http .../SimpleSSLContext.java` JTreg tag is used to inject `SimpleSSLContext`
>
> I would prefer to split this PR into two fixes:
> 
>  - a first fix that simply adds the new API to SimpleSSLContext, without removing the old API.
>  - a second fix that do all the rest: remove the old API and update the tests.
>  
> This would allow us to easily backport the first fix, and new tests would not need adaptation when they are later being backported provided that the first fix has been backported first.
> 
> You could enjoy using dependent PRs for this :-)

@dfuch, I've updated the ticket and this PR as follows:

1. Pushed d4c9b3129fc reverting all changes and only keeping `SimpleSSLContext` enhancements, and updated the parent ticket description (i.e., [JDK-8372661]) to reflect this.
2. Created [JDK-8373515] for migrating `test/jdk/java/net/httpclient/`
3. Created [JDK-8373537] for migrating `test/jdk/com/sun/net/httpserver/`
4. Created [JDK-8373538] for migrating the rest, and removing the unused `SimpleSSLContext` methods

[JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
[JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
[JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
[JDK-8373538]: https://bugs.openjdk.org/browse/JDK-8373538

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

PR Comment: https://git.openjdk.org/jdk/pull/28765#issuecomment-3643196386

From vyazici at openjdk.org  Thu Dec 11 18:57:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 11 Dec 2025 18:57:31 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods
Message-ID: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>

Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.

[JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661

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

Commit messages:
 - Restore `test/jdk/java/net/httpclient/` changes
 - Reverted all changes and only kept `SimpleSSLContext` enhancements
 - Overhaul `SimpleSSLContext` and its usages

Changes: https://git.openjdk.org/jdk/pull/28771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28771&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373515
  Stats: 1073 lines in 180 files changed: 108 ins; 667 del; 298 mod
  Patch: https://git.openjdk.org/jdk/pull/28771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28771/head:pull/28771

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

From vyazici at openjdk.org  Thu Dec 11 18:57:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 11 Dec 2025 18:57:33 GMT
Subject: RFR: 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe
 "SimpleSSLContext" methods
In-Reply-To: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
References: <jODBufbtCDhCiI4q08shMw_DYJQ0HNXkykQPNh4H9uE=.8172693a-46c4-4601-93ac-20fa7cda9842@github.com>
Message-ID: <tR7OvjyvB9JPDRt6Uq2uVyM9FMPtC4Dsowxgr7XTxno=.0bd79f39-764d-4781-a906-23d536e904a1@github.com>

On Thu, 11 Dec 2025 18:49:12 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Migrates `test/jdk/java/net/httpclient/` to null-safe `SimpleSSLContext` methods introduced in [JDK-8372661], which is a prerequisite for this change set.
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661

test/lib/jdk/test/lib/net/SimpleSSLContext.java line 1:

> 1: /*

This file will be provided by [JDK-8372661].

[JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28771#discussion_r2611701126

From coffeys at openjdk.org  Thu Dec 11 18:58:05 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 11 Dec 2025 18:58:05 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v4]
In-Reply-To: <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>
Message-ID: <gAziXKHbesPyd2zc5gYsoBvVQILqaX_BaXaYl-0yg9E=.d2ae1a19-f6c0-414e-a7df-1f83c16f114b@github.com>

On Fri, 5 Dec 2025 17:00:18 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only the last few sentences of javadoc are outdated

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28275#pullrequestreview-3568868919

From coffeys at openjdk.org  Thu Dec 11 18:58:08 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 11 Dec 2025 18:58:08 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v4]
In-Reply-To: <n05DyL-r4guQa2qqJ8kJtszvNPn0ZePkpWX5e4DSDB8=.35c66a66-4199-464e-a671-c1fbdfd7e4bb@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>
 <F6FeOol89lIEmpzGZSO5QPikUXdIdeV9J2F2b3U99uc=.f1c1f13c-e018-4404-8577-7bf7a0f6bb13@github.com>
 <n05DyL-r4guQa2qqJ8kJtszvNPn0ZePkpWX5e4DSDB8=.35c66a66-4199-464e-a671-c1fbdfd7e4bb@github.com>
Message-ID: <Rb2tQcEq3Sr80yZfbQw398yzePfCQuCOIKQW3uNQiVA=.cb5c3caa-1efe-4c1a-8990-e964c1731f32@github.com>

On Wed, 10 Dec 2025 20:54:09 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 210:
>> 
>>> 208: 
>>> 209:         if (socket instanceof SSLSocket sslSocket && sslSocket.isConnected()) {
>>> 210:             session = sslSocket.getHandshakeSession();
>> 
>> subtle change in the refactoring now that the session non-null check is delayed until the new `findTrustedCertificate` call. 
>> The `SSLAlgorithmConstraints.forEngine/forSocket/forQUIC` methods also reference the session before the `findTrustedCertificate` call . Have you ensured that a null session can't cause issue there ?
>
> Yes, we have a check for session not being null there: `session instanceof ExtendedSSLSession`

fair enough.  SupportedSignatureAlgorithmConstraints constructor caters for this scenario at moment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2611715401

From abarashev at openjdk.org  Thu Dec 11 19:11:19 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 11 Dec 2025 19:11:19 GMT
Subject: RFR: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl [v4]
In-Reply-To: <Rb2tQcEq3Sr80yZfbQw398yzePfCQuCOIKQW3uNQiVA=.cb5c3caa-1efe-4c1a-8990-e964c1731f32@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
 <DN-F8FPUemL0nTFc8sSzHSU6WgDQT0w9KeXa1Zz2qWQ=.033437b8-8646-419b-855f-a71572040100@github.com>
 <F6FeOol89lIEmpzGZSO5QPikUXdIdeV9J2F2b3U99uc=.f1c1f13c-e018-4404-8577-7bf7a0f6bb13@github.com>
 <n05DyL-r4guQa2qqJ8kJtszvNPn0ZePkpWX5e4DSDB8=.35c66a66-4199-464e-a671-c1fbdfd7e4bb@github.com>
 <Rb2tQcEq3Sr80yZfbQw398yzePfCQuCOIKQW3uNQiVA=.cb5c3caa-1efe-4c1a-8990-e964c1731f32@github.com>
Message-ID: <7WClHmMEDX3B6NAFpVmK5hXCJBeMMxfO-yqsJvVroq0=.019ec72b-344c-4b8f-9722-719c3e9d55d6@github.com>

On Thu, 11 Dec 2025 18:54:24 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Yes, we have a check for session not being null there: `session instanceof ExtendedSSLSession`
>
> fair enough.  SupportedSignatureAlgorithmConstraints constructor caters for this scenario at moment.

Yes, if session is `null` we would allocate the constraints and then fail, before the refactoring we failed before allocating constraints. In practice, session is never null when we reach that code though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2611753980

From mullan at openjdk.org  Thu Dec 11 20:47:46 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 Dec 2025 20:47:46 GMT
Subject: RFR: 8371975: Apply java.io.Serial annotations in
 java.security.sasl
In-Reply-To: <WyApeD2-_IVVqenZaQ7Jdrmfb87WKzLY24qwaLQn8fM=.39e1d2c0-cee0-4d45-bdb2-ea180f1b8dc8@github.com>
References: <WyApeD2-_IVVqenZaQ7Jdrmfb87WKzLY24qwaLQn8fM=.39e1d2c0-cee0-4d45-bdb2-ea180f1b8dc8@github.com>
Message-ID: <ctzyqISW_0k-PyUKxGVtQzGLO2soZGmofBtDC0-p9CQ=.aba97f35-4061-4569-bfb1-f2043e787292@github.com>

On Mon, 17 Nov 2025 06:11:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the `java.security.sasl` module to enable stricter compile-time checking of serialization-related declarations.
> 
> Example of a similar change https://github.com/openjdk/jdk/pull/27925.
> 
> Note: this annotation can be applied to these methods and fields:
>   * private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>   * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>   * private void readObjectNoData() throws ObjectStreamException 
>    * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>    * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>    * private static final ObjectStreamField[] serialPersistentFields
>    * private static final long serialVersionUID

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28345#pullrequestreview-3569232772

From serb at openjdk.org  Fri Dec 12 01:10:25 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Dec 2025 01:10:25 GMT
Subject: RFR: 8371975: Apply java.io.Serial annotations in
 java.security.sasl [v2]
In-Reply-To: <WyApeD2-_IVVqenZaQ7Jdrmfb87WKzLY24qwaLQn8fM=.39e1d2c0-cee0-4d45-bdb2-ea180f1b8dc8@github.com>
References: <WyApeD2-_IVVqenZaQ7Jdrmfb87WKzLY24qwaLQn8fM=.39e1d2c0-cee0-4d45-bdb2-ea180f1b8dc8@github.com>
Message-ID: <7Md4svQw-4WMghP2AVhmTAKtLdNMa-bMc_CRJkEizVQ=.12791b0a-9b95-4e52-9d66-8467e84799ac@github.com>

> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the `java.security.sasl` module to enable stricter compile-time checking of serialization-related declarations.
> 
> Example of a similar change https://github.com/openjdk/jdk/pull/27925.
> 
> Note: this annotation can be applied to these methods and fields:
>   * private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>   * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>   * private void readObjectNoData() throws ObjectStreamException 
>    * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>    * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>    * private static final ObjectStreamField[] serialPersistentFields
>    * private static final long serialVersionUID

Sergey Bylokhov 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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8371975
 - 8371975: Apply java.io.Serial annotations in java.security.sasl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28345/files
  - new: https://git.openjdk.org/jdk/pull/28345/files/f3d0639f..0ada029f

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

  Stats: 122104 lines in 1883 files changed: 80666 ins; 30374 del; 11064 mod
  Patch: https://git.openjdk.org/jdk/pull/28345.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28345/head:pull/28345

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

From azeller at openjdk.org  Fri Dec 12 09:37:12 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Fri, 12 Dec 2025 09:37:12 GMT
Subject: RFR: 8371559: Intermittent timeouts in test
 javax/net/ssl/Stapling/HttpsUrlConnClient.java
Message-ID: <8omahf9gRdCaAte7kxy0ZIo2digWri6D4aY6Y1HUBi4=.7483faa5-1e5f-487c-bf51-64c7bd843e99@github.com>

The test javax/net/ssl/Stapling/HttpsUrlConnClient.java sometimes hangs and run into timeouts. By adding some more tracing it showed that it can happen on machines with high load that the client thread throws a "Server not ready yet" RuntimeException because it only waits for 5 seconds for the server thread to come available.
I added some more output in case of errors to better see the issue and use the timeout factor to modify the maximum wait time.

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8371559
 - Use timeout factor when waiting for server ready

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

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

From weijun at openjdk.org  Fri Dec 12 12:36:56 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 12 Dec 2025 12:36:56 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
In-Reply-To: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
References: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
Message-ID: <O-ujXzpM4k-XDASfZ-Y-dg1gmvnFC-xwoURM1cV8A54=.1bc71f3f-107b-4954-ab61-066ef65fdb50@github.com>

On Tue, 9 Dec 2025 14:41:02 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> ?hould pass on Aarch64
> 
> The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
> Other then fixing that, I did some formatting and corrected a comment.

test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 49:

> 47: // To run manually:
> 48: // java --add-opens java.base/sun.security.provider=ALL-UNNAMED
> 49: // --add-exports java.base/sun.security.provider=ALL-UNNAMED

Please indent one space to align with lines below.

test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 51:

> 49: // --add-exports java.base/sun.security.provider=ALL-UNNAMED
> 50: //  -XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics
> 51: //  test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java

You've modified the test path above.

test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 140:

> 138:         for (int j = 0; j < ML_DSA_N; j++) {
> 139:             coeffs1[j] = rnd.nextInt(2 * ML_DSA_Q) - ML_DSA_Q;
> 140:             coeffs2[j] = rnd.nextInt(2 * ML_DSA_Q) - ML_DSA_Q;

Why are both so small? Maybe only one is enough?

test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 147:

> 145: 
> 146:         if (!Arrays.equals(prod1, prod2)) {
> 147:             boolean modQequal = true;

You can copy the "the result is greater than -MONT_Q and less than MONT_Q" comment here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614055156
PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614055825
PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614063686
PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614058951

From duke at openjdk.org  Fri Dec 12 12:49:10 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 12 Dec 2025 12:49:10 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
In-Reply-To: <bpeXR5mf9YC2k09cx-Uyo_PAQIoasVmg6P74XUBTqeY=.a20d72f3-9a60-4775-8126-241bcfbd0934@github.com>
References: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
 <bpeXR5mf9YC2k09cx-Uyo_PAQIoasVmg6P74XUBTqeY=.a20d72f3-9a60-4775-8126-241bcfbd0934@github.com>
Message-ID: <SAoMACwS3Z2PLM2rAAOac7Od5c6SDQ6Kx-o6dMQOOUU=.47831fa0-6c08-45ea-97bc-c4fa6c8be085@github.com>

On Tue, 9 Dec 2025 18:19:04 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> ?hould pass on Aarch64
>> 
>> The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
>> Other then fixing that, I did some formatting and corrected a comment.
>
> test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 147:
> 
>> 145: 
>> 146:         if (!Arrays.equals(prod1, prod2)) {
>> 147:             boolean modQequal = true;
> 
> I would probably had moved this to its own helper `arraysCongruent` and replaces the `if (!Arrays.equals(prod1, prod2))` with `!arraysCongruent(prod1, prod2)`. But not a deal-breaker..

Thanks for your thorough review and comments!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614097633

From duke at openjdk.org  Fri Dec 12 13:29:59 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 12 Dec 2025 13:29:59 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
In-Reply-To: <O-ujXzpM4k-XDASfZ-Y-dg1gmvnFC-xwoURM1cV8A54=.1bc71f3f-107b-4954-ab61-066ef65fdb50@github.com>
References: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
 <O-ujXzpM4k-XDASfZ-Y-dg1gmvnFC-xwoURM1cV8A54=.1bc71f3f-107b-4954-ab61-066ef65fdb50@github.com>
Message-ID: <vYxDkue7XJ659faouPHQdzWp4LQiiYXAx8R6tuSy2cg=.911dac19-a544-415e-8ab7-9f4800c15094@github.com>

On Fri, 12 Dec 2025 12:30:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> ?hould pass on Aarch64
>> 
>> The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
>> Other then fixing that, I did some formatting and corrected a comment.
>
> test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 49:
> 
>> 47: // To run manually:
>> 48: // java --add-opens java.base/sun.security.provider=ALL-UNNAMED
>> 49: // --add-exports java.base/sun.security.provider=ALL-UNNAMED
> 
> Please indent one space to align with lines below.

Done.

> test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 51:
> 
>> 49: // --add-exports java.base/sun.security.provider=ALL-UNNAMED
>> 50: //  -XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics
>> 51: //  test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java
> 
> You've modified the test path above.

You are right. I have changed it.

> test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 140:
> 
>> 138:         for (int j = 0; j < ML_DSA_N; j++) {
>> 139:             coeffs1[j] = rnd.nextInt(2 * ML_DSA_Q) - ML_DSA_Q;
>> 140:             coeffs2[j] = rnd.nextInt(2 * ML_DSA_Q) - ML_DSA_Q;
> 
> Why are both so small? Maybe only one is enough?

This is purely for performance reasons. The test works for any case that satisfies the montMul() preconditions, but since this particular method that is under test here, these stricter conditions are always satisfied. If we allow a bigger range, the probability that the whole vector fails the equality test is higher, so the for loop will be executed more frequently and that takes time. I added a comment to the code.

> test/jdk/sun/security/provider/pqc/ML_DSA_Intrinsic_Test.java line 147:
> 
>> 145: 
>> 146:         if (!Arrays.equals(prod1, prod2)) {
>> 147:             boolean modQequal = true;
> 
> You can copy the "the result is greater than -MONT_Q and less than MONT_Q" comment here.

I added some comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614213946
PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614214105
PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614214403
PR Review Comment: https://git.openjdk.org/jdk/pull/28722#discussion_r2614214261

From duke at openjdk.org  Fri Dec 12 14:15:56 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 12 Dec 2025 14:15:56 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
 [v2]
In-Reply-To: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
References: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
Message-ID: <xcAtDkcXZp4MgVDWu-tU120M9RjLVqe7veJKb4MZ1Uc=.92d5d601-a714-4666-b09e-e9ec6209b8fb@github.com>

> ?hould pass on Aarch64
> 
> The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
> Other then fixing that, I did some formatting and corrected a comment.

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

  Responding to review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28722/files
  - new: https://git.openjdk.org/jdk/pull/28722/files/49bead2a..917a5057

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

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

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

From abarashev at openjdk.org  Fri Dec 12 14:42:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 12 Dec 2025 14:42:34 GMT
Subject: Integrated: 8371721: Refactor checkTrusted methods in
 X509TrustManagerImpl
In-Reply-To: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
References: <njvwdpIE6150m3yYkuu_0mDz1ZQVeEaT8l1DeURf-n8=.c9d3ed83-6cdc-4554-a92a-19bd6e68a9a6@github.com>
Message-ID: <SB13hhrVOzJOHPtNtt9v05FqGgykAsUbGsB9sS3Iqno=.94d865aa-e7d6-4cff-aa30-a8de5575d5d9@github.com>

On Wed, 12 Nov 2025 21:32:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.

This pull request has now been integrated.

Changeset: a99f340e
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a99f340e1b9686431d944ab114918d2b849718fe
Stats:     109 lines in 1 file changed: 19 ins; 56 del; 34 mod

8371721: Refactor checkTrusted methods in X509TrustManagerImpl

Reviewed-by: coffeys, djelinski

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

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

From weijun at openjdk.org  Fri Dec 12 15:36:34 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 12 Dec 2025 15:36:34 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
 [v2]
In-Reply-To: <xcAtDkcXZp4MgVDWu-tU120M9RjLVqe7veJKb4MZ1Uc=.92d5d601-a714-4666-b09e-e9ec6209b8fb@github.com>
References: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
 <xcAtDkcXZp4MgVDWu-tU120M9RjLVqe7veJKb4MZ1Uc=.92d5d601-a714-4666-b09e-e9ec6209b8fb@github.com>
Message-ID: <-8xXevU3HuZuQccJmMnNER4BLA0J4-Og54KApVf5yNw=.0811dba2-786a-4e70-b4b2-7e127e7150e3@github.com>

On Fri, 12 Dec 2025 14:15:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> ?hould pass on Aarch64
>> 
>> The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
>> Other then fixing that, I did some formatting and corrected a comment.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Responding to review comments

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28722#pullrequestreview-3572361881

From duke at openjdk.org  Fri Dec 12 15:43:29 2025
From: duke at openjdk.org (duke)
Date: Fri, 12 Dec 2025 15:43:29 GMT
Subject: RFR: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
 [v2]
In-Reply-To: <xcAtDkcXZp4MgVDWu-tU120M9RjLVqe7veJKb4MZ1Uc=.92d5d601-a714-4666-b09e-e9ec6209b8fb@github.com>
References: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
 <xcAtDkcXZp4MgVDWu-tU120M9RjLVqe7veJKb4MZ1Uc=.92d5d601-a714-4666-b09e-e9ec6209b8fb@github.com>
Message-ID: <JVhjPPhgVGMw2xV4bTSkxKSD-1dY6MhcjeqdE4Gjds8=.02f5cd94-f9de-4e5c-85ec-d836c8a881d9@github.com>

On Fri, 12 Dec 2025 14:15:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> ?hould pass on Aarch64
>> 
>> The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
>> Other then fixing that, I did some formatting and corrected a comment.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Responding to review comments

@ferakocz 
Your change (at version 917a5057b27de272e6e19630577afdca383cdd5f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28722#issuecomment-3647066607

From duke at openjdk.org  Fri Dec 12 16:07:50 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 12 Dec 2025 16:07:50 GMT
Subject: Integrated: 8373059: Test
 sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64
In-Reply-To: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
References: <RbZpnJ5c2qnPF6WjaOzEzWeogJgjAwX6JlaWF3lJ2FE=.e24f4acf-48c8-4c67-9d1f-ab789885f863@github.com>
Message-ID: <1D3JkmgxF29tPTV0kHByBLQBOkDYVkhKvsgOQapPFKw=.f5cb5051-8ade-4a70-931f-5662ef1777f4@github.com>

On Tue, 9 Dec 2025 14:41:02 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> ?hould pass on Aarch64
> 
> The test used to fail because it had checked a stronger equivalence of the results of the Java method and its intrinsified version.
> Other then fixing that, I did some formatting and corrected a comment.

This pull request has now been integrated.

Changeset: 6ec36d34
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ec36d348b1eaeedb993a905e42650242fac0918
Stats:     67 lines in 2 files changed: 38 ins; 4 del; 25 mod

8373059: Test sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java should pass on Aarch64

Reviewed-by: weijun, vpaprotski

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

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