Integrated: 8356977: UTF-8 cleanups
On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie wrote: > I found a few other places in the code that can be cleaned up after the > conversion to UTF-8. This pull request has now been integrated. Changeset: edf92721 Author:Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/edf92721c2db4cfba091cf4901af603db8486951 Stats: 15 lines in 13 files changed: 0 ins; 0 del; 15 mod 8356977: UTF-8 cleanups Reviewed-by: naoto, prr - PR: https://git.openjdk.org/jdk/pull/25228
Integrated: 8350689: Turn on timestamp and thread metadata by default for java.security.debug
On Thu, 29 May 2025 19:06:15 GMT, Sean Coffey wrote: > Removal of the `+thread` and `+timestamp` options that were used to control > the logging behavior of output from the `java.security.debug` system property. > > > To enhance the security debug logs, the thread and timestamp data should > always be present. This brings it to a par with another important security > debug system property, the TLS debug property: javax.net.debug. Output from > the TLS `javax.net.debug` logs always contains thread and timestamp data. > > This patch remove the `+thread` and `+timestamp` support code and print > thread and timestamp data by default. This enancement is only proposed for > the JDK feature release. Update releases can continue to opt into such data. > > Debug output data from use of the `java.security.debug` property will now > resemble something like the following: > > > > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial > security property: package.definition=sun.misc.,sun.reflect. > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial > security property: krb5.kdc.bad.policy=tryLast > > > I've also trimmed back on some of the test case coverage since use of > `+thread` and `+timestamp` options is now redundant with this patch. This pull request has now been integrated. Changeset: 42f48a39 Author:Sean Coffey URL: https://git.openjdk.org/jdk/commit/42f48a39e867ae1683708dda3e158c24a6957180 Stats: 184 lines in 5 files changed: 15 ins; 130 del; 39 mod 8350689: Turn on timestamp and thread metadata by default for java.security.debug Reviewed-by: mullan - PR: https://git.openjdk.org/jdk/pull/25528
Re: RFR: 8358159: Empty mode/padding in cipher transformations [v2]
> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" > throws NoSuchAlgorithmException. > This patch restores the behavior by ensuring that empty mode or padding > strings are interpreted as null. > > Testing done for : tier1 - fastdebug level (AIX) > > JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) Varada M has updated the pull request incrementally with one additional commit since the last revision: jtreg test case - Changes: - all: https://git.openjdk.org/jdk/pull/25547/files - new: https://git.openjdk.org/jdk/pull/25547/files/e7a35711..ccc650bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25547&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25547&range=00-01 Stats: 54 lines in 1 file changed: 54 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25547/head:pull/25547 PR: https://git.openjdk.org/jdk/pull/25547
Re: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" > throws NoSuchAlgorithmException. > This patch restores the behavior by ensuring that empty mode or padding > strings are interpreted as null. > > Testing done for : tier1 - fastdebug level (AIX) > > JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) Varada M has updated the pull request incrementally with one additional commit since the last revision: whitespace error fix - Changes: - all: https://git.openjdk.org/jdk/pull/25547/files - new: https://git.openjdk.org/jdk/pull/25547/files/ccc650bb..b5854da0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25547&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25547&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25547/head:pull/25547 PR: https://git.openjdk.org/jdk/pull/25547
Re: RFR: 8355379: Annotate lazy fields in java.security @Stable
On Fri, 23 May 2025 04:54:26 GMT, Koushik Muthukrishnan Thirupattur
wrote:
> Several classes in the `java.security` package lazily compute their hash
> value and store it in a field. These fields can typically be annotated with
> the `@Stable` annotation. Many of the current implementations are using -1 as
> a flag for not computed, this needs to be refactored away.
>
> Here are some examples of such classes: PKCS12Attribute, Timestamp,
> Certificate, and URICertStoreParameters.
I think we should add tests that seralizes/deserializes objects several times
to make sure the hash code works as expected here.
src/java.base/share/classes/java/security/CodeSigner.java line 172:
> 170: throw new InvalidObjectException("signerCertPath is null");
> 171: }
> 172: myhash = 0;
I do not think we can use `@Stable` for this class, as `readObject()` can be
called multiple times on an object.
src/java.base/share/classes/java/security/Timestamp.java line 179:
> 177: throw new InvalidObjectException("Invalid null field(s)");
> 178: }
> 179: myhash = 0;
Same here.
-
PR Comment: https://git.openjdk.org/jdk/pull/25405#issuecomment-2939685005
PR Review Comment: https://git.openjdk.org/jdk/pull/25405#discussion_r2126373067
PR Review Comment: https://git.openjdk.org/jdk/pull/25405#discussion_r2126374887
Re: RFR: 8358171: Additional code coverage for PEM API [v2]
> The tests included in this PR add code coverage mainly to the following > classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, > EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are > included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property > and some negative testing Fernando Guallini 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 8358171 - add logging line - lines comments - add final break and test comment - multi thread and defaut algo tests - more test coverage for PEM - Changes: - all: https://git.openjdk.org/jdk/pull/25588/files - new: https://git.openjdk.org/jdk/pull/25588/files/6f18e8b2..a74a76c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25588&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25588&range=00-01 Stats: 8811 lines in 345 files changed: 6496 ins; 1064 del; 1251 mod Patch: https://git.openjdk.org/jdk/pull/25588.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25588/head:pull/25588 PR: https://git.openjdk.org/jdk/pull/25588
Re: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
On Wed, 4 Jun 2025 10:37:28 GMT, Varada M wrote: >> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" >> throws NoSuchAlgorithmException. >> This patch restores the behavior by ensuring that empty mode or padding >> strings are interpreted as null. >> >> Testing done for : tier1 - fastdebug level (AIX) >> >> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) > > Varada M has updated the pull request incrementally with one additional > commit since the last revision: > > whitespace error fix LGTM - Marked as reviewed by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/25547#pullrequestreview-2896543679
RFR: 8358451: SunJCE PBEKey impl should throw IllegalStateException when getEncoded() is called
Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed 2. serialization of such destroyed `PBEKey` object will lead to exception. Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc. - Commit messages: - 8358451: SunJCE PBEKey impl should throw IllegalStateException when getEncoded() is called Changes: https://git.openjdk.org/jdk/pull/25632/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25632&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358451 Stats: 73 lines in 3 files changed: 68 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25632.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25632/head:pull/25632 PR: https://git.openjdk.org/jdk/pull/25632
Re: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
On Wed, 4 Jun 2025 10:37:28 GMT, Varada M wrote: >> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" >> throws NoSuchAlgorithmException. >> This patch restores the behavior by ensuring that empty mode or padding >> strings are interpreted as null. >> >> Testing done for : tier1 - fastdebug level (AIX) >> >> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) > > Varada M has updated the pull request incrementally with one additional > commit since the last revision: > > whitespace error fix @valeriepeng Can you also review this? Thanks. - PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2940086483
RFR: 8358594: Misleading keyLength value captured in JFR event for ML-KEM key
Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category. - Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/25642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25642&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358594 Stats: 112 lines in 2 files changed: 110 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25642/head:pull/25642 PR: https://git.openjdk.org/jdk/pull/25642
Re: RFR: 8358451: SunJCE PBEKey impl should throw IllegalStateException when getEncoded() is called
On Wed, 4 Jun 2025 03:10:29 GMT, Valerie Peng wrote:
> Update the `PBEKey` class of the SunJCE provider which override the
> `javax.security.auth.Destroyable` interface to
>
> 1. throw `IllegalStateException` if `getEncoded()` is called after key is
> destroyed
> 2. serialization of such destroyed `PBEKey` object will lead to exception.
>
> Also update the `PBEKeyFactory` class of the SunJCE provider to check for
> destroyed keys and throw exceptions per the method javadoc.
src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 82:
> 80: }
> 81:
> 82: public byte[] getEncoded() {
I understand this is not a public API class so there is no need to provide
`@throws` in the spec. But, on the other hand, do we need to provide one in its
super class `java.security.key`? I have no opinion.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2126861948
Re: RFR: 8358451: SunJCE PBEKey impl should throw IllegalStateException when getEncoded() is called
On Wed, 4 Jun 2025 03:10:29 GMT, Valerie Peng wrote: > Update the `PBEKey` class of the SunJCE provider which override the > `javax.security.auth.Destroyable` interface to > > 1. throw `IllegalStateException` if `getEncoded()` is called after key is > destroyed > 2. serialization of such destroyed `PBEKey` object will lead to exception. > > Also update the `PBEKeyFactory` class of the SunJCE provider to check for > destroyed keys and throw exceptions per the method javadoc. src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 1: > 1: /* Shall we also throw ISE when `getFormat` and `getAlgorithm` are called? Calling these methods after the key is destroyed looks suspicious and may reveal a coding error. - PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2126853766
Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v6]
> Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP > Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP > Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC > protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 495 commits: - merge latest changes from master branch - http3: fix bug introduced by Http3ConnectionPool and improved debug logs - http3: refactor HTTP/3 connection pool management in a separate class - Ignore DestroyFailedExceptions - Remove outdated TODO - Remove outdated TODO - Remove cryptic TODO - Remove outdated TODO - Fix race in test server's Http3StreamDispatcher - Test H3 server: close connection if control stream closed - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0 - Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=05 Stats: 103642 lines in 473 files changed: 100781 ins; 1345 del; 1516 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751
Re: RFR: 8358594: Misleading keyLength value captured in JFR event for ML-KEM key
On Wed, 4 Jun 2025 14:59:43 GMT, Weijun Wang wrote: > Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new > method `getNistCategory` to get the NIST security category. src/java.base/share/classes/sun/security/util/KeyUtil.java line 56: > 54: * Traditionally, the key size of an asymmetric key refers to the > size of > 55: * its modulus. For example, a 2048-bit RSA key or a 256-bit NIST > P-256 EC > 56: * key. However, modern post-quantum algorithms based on lattice > cryptography, I would not say "modern post-quantum". src/java.base/share/classes/sun/security/util/KeyUtil.java line 134: > 132: > 133: /** > 134: * Returns the NIST security categories defined for PQC algorithms. > It was s/was/is/ - PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2126930677 PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2126940503
Re: RFR: 8358594: Misleading keyLength value captured in JFR event for ML-KEM key
On Wed, 4 Jun 2025 14:59:43 GMT, Weijun Wang wrote: > Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new > method `getNistCategory` to get the NIST security category. src/java.base/share/classes/sun/security/util/KeyUtil.java line 62: > 60: * each standardized parameter set. For example, ML-KEM-768 is > assigned to > 61: * category 3, and ML-DSA-87 to category 5. > 62: * Should we consider returning whatever number is an the end of PQC algorithms as a key size? That would make things consistent and it would allow us to use existing `keySize` algorithm constraints for PQC algorithms. Key sizes for RSA and EC algorithms already differ significantly for the same security level: 3072-bit RSA corresponds to 256-bit EC. So we can return `768` for ML-KEM-768 or `87` for ML-DSA-87. - PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2126968358
Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v5]
On Fri, 16 May 2025 10:26:11 GMT, Daniel Fuchs wrote:
>> Daniel Fuchs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 422 commits:
>>
>> - merge latest changes from master branch
>> - Undo whitespace change
>> - Remove unnecessary import
>> - Merge remote-tracking branch 'origin/master' into http3
>> - Fix test license
>> - Remove leftover file (test was moved to parent directory)
>> - Remove unnecessary import
>> - Update throws clauses
>> - Merge remote-tracking branch 'origin/master' into http3
>> - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>> - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java
> line 737:
>
>> 735: // channel, and a single selector thread, so we can do
>> 736: // the reading directly in the selector thread and offload
>> 737: // the parsing (the readLoop) to the executor.
>
> This comment is outdated. We actually stop reading from the channel when the
> amount of data buffered exceeds a high watermark threshold.
Updated in latest commits
(https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java
> line 822:
>
>> 820: if (this.buffered.get() >= MAX_BUFFERED_HIGH) {
>> 821: pauseReading();
>> 822: readLoopScheduler.runOrSchedule(executor);
>
> This line should not be needed: we should already have kicked the read loop
> at line 797.
Updated in latest commits
(https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126958527
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126959414
Re: RFR: 8358594: Misleading keyLength value captured in JFR event for ML-KEM key [v2]
> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new > method `getNistCategory` to get the NIST security category. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: addressing Mark's comments - Changes: - all: https://git.openjdk.org/jdk/pull/25642/files - new: https://git.openjdk.org/jdk/pull/25642/files/bd7abe8e..157c53b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25642&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25642&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25642/head:pull/25642 PR: https://git.openjdk.org/jdk/pull/25642
Re: RFR: 8358171: Additional code coverage for PEM API [v3]
> The tests included in this PR add code coverage mainly to the following > classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, > EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are > included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property > and some negative testing Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add invalid PEM content test - Changes: - all: https://git.openjdk.org/jdk/pull/25588/files - new: https://git.openjdk.org/jdk/pull/25588/files/a74a76c2..c16eabe1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25588&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25588&range=01-02 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25588.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25588/head:pull/25588 PR: https://git.openjdk.org/jdk/pull/25588
Re: RFR: 8358594: Misleading keyLength value captured in JFR event for ML-KEM key [v2]
On Wed, 4 Jun 2025 16:08:31 GMT, Artur Barashev wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> addressing Mark's comments > > src/java.base/share/classes/sun/security/util/KeyUtil.java line 62: > >> 60: * each standardized parameter set. For example, ML-KEM-768 is >> assigned to >> 61: * category 3, and ML-DSA-87 to category 5. >> 62: * > > Should we consider returning whatever number is an the end of PQC algorithms > as a key size? That would make things consistent and it would allow us to use > existing `keySize` algorithm constraints for PQC algorithms. Key sizes for > RSA and EC algorithms already differ significantly for the same security > level: 3072-bit RSA corresponds to 256-bit EC. So we can return `768` for > ML-KEM-768 or `87` for ML-DSA-87. For ML-DSA-87, 87 isn’t a key size in any sense. Using it as a key size would be misleading. For algorithm constraints, we can use the parameter set name directly. - PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2127040718
Re: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
On Wed, 4 Jun 2025 13:39:50 GMT, Sean Mullan wrote: > @valeriepeng Can you also review this? Thanks. Yes, I have started looking at it. Was about to ask for a regression test, and you beat me to it. - PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2940866076
Re: RFR: 8358594: Misleading keyLength value captured in JFR event for ML-KEM key [v2]
On Wed, 4 Jun 2025 16:50:41 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/KeyUtil.java line 62: >> >>> 60: * each standardized parameter set. For example, ML-KEM-768 is >>> assigned to >>> 61: * category 3, and ML-DSA-87 to category 5. >>> 62: * >> >> Should we consider returning whatever number is an the end of PQC algorithms >> as a key size? That would make things consistent and it would allow us to >> use existing `keySize` algorithm constraints for PQC algorithms. Key sizes >> for RSA and EC algorithms already differ significantly for the same security >> level: 3072-bit RSA corresponds to 256-bit EC. So we can return `768` for >> ML-KEM-768 or `87` for ML-DSA-87. > > For ML-DSA-87, 87 isn’t a key size in any sense. Using it as a key size would > be misleading. For algorithm constraints, we can use the parameter set name > directly. Right, we should probably consider renaming `getKeySize()` to `getKeyStrength()`, but I guess that would be outside of this PR's scope. - PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2127131876
Re: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
On Wed, 4 Jun 2025 10:37:28 GMT, Varada M wrote: >> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" >> throws NoSuchAlgorithmException. >> This patch restores the behavior by ensuring that empty mode or padding >> strings are interpreted as null. >> >> Testing done for : tier1 - fastdebug level (AIX) >> >> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) > > Varada M has updated the pull request incrementally with one additional > commit since the last revision: > > whitespace error fix test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 27: > 25: * @test > 26: * @bug 8358159 > 27: * @summary test that the Cipher.getInstance() handles transformations > with empty mode and/or padding nit: In general, we try to keep the lines <= 80 chars. Could you try breaking lines longer than 80 chars into multiple lines? There are a few lines in this test are longer than 80 chars. - PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2127134802
Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v6]
On Wed, 4 Jun 2025 15:46:36 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the
>> HTTP Client API](https://openjdk.org/jeps/517).
>>
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the
>> HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>>
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC
>> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 495 commits:
>
> - merge latest changes from master branch
> - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
> - http3: refactor HTTP/3 connection pool management in a separate class
> - Ignore DestroyFailedExceptions
> - Remove outdated TODO
> - Remove outdated TODO
> - Remove cryptic TODO
> - Remove outdated TODO
> - Fix race in test server's Http3StreamDispatcher
> - Test H3 server: close connection if control stream closed
> - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0
src/java.net.http/share/classes/jdk/internal/net/http/hpack/HPACK.java line 176:
> 174:
> 175: @FunctionalInterface
> 176: interface BufferUpdateConsumer {
@AlekseiEfimov It looks like this change is no longer required and could be
reverted
src/java.net.http/share/classes/jdk/internal/net/http/hpack/ISO_8859_1.java
line 43:
> 41: // The encoding is simple and well known: 1 byte <-> 1 char
> 42: //
> 43: final class ISO_8859_1 {
OK - this class is actually used in QPack as well as HPack. Same for the
`QuickHuffman` class below (notice that this is Quick - not Quic ;-) )
It might be interesting to investigate if we could pull out these classes to a
common location to break the tie between QPack and HPack. Something to think
about after integration maybe.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126966393
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2127123043
Re: RFR: 8357592: Update output parsing in test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java
On Thu, 22 May 2025 23:03:47 GMT, Matthew Donovan wrote: > In this PR, I updated the jarsigner compatibility test to handle minor > differences in the output of jarsigner between versions. Marked as reviewed by rhalade (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/25403#pullrequestreview-2897643246
Integrated: 8357592: Update output parsing in test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java
On Thu, 22 May 2025 23:03:47 GMT, Matthew Donovan wrote: > In this PR, I updated the jarsigner compatibility test to handle minor > differences in the output of jarsigner between versions. This pull request has now been integrated. Changeset: 5ed246d1 Author:Matthew Donovan URL: https://git.openjdk.org/jdk/commit/5ed246d17d9f40489ed715b7df104ec6a832841e Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8357592: Update output parsing in test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java Reviewed-by: rhalade - PR: https://git.openjdk.org/jdk/pull/25403
Re: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
On Wed, 4 Jun 2025 10:37:28 GMT, Varada M wrote: >> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" >> throws NoSuchAlgorithmException. >> This patch restores the behavior by ensuring that empty mode or padding >> strings are interpreted as null. >> >> Testing done for : tier1 - fastdebug level (AIX) >> >> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) > > Varada M has updated the pull request incrementally with one additional > commit since the last revision: > > whitespace error fix src/java.base/share/classes/javax/crypto/Cipher.java line 393: > 391: this.suffix = suffix.toUpperCase(Locale.ENGLISH); > 392: this.mode = ((mode == null) || mode.isEmpty()) ? null : mode; > 393: this.pad = ((pad == null) || pad.isEmpty()) ? null : pad; Thanks for reporting and fixing this issue. Since this is an internal class used solely inside `Cipher` class, instead of changing the empty string to null inside the `Transform` constuctor, we can do that before calling `Transform` constructor. Also if one of `mode` or `pad` is empty, then maybe we don't need all 4 `Transform`s. - PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2127160213
Re: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
On Wed, 4 Jun 2025 18:06:33 GMT, Valerie Peng wrote:
>> Varada M has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> whitespace error fix
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 393:
>
>> 391: this.suffix = suffix.toUpperCase(Locale.ENGLISH);
>> 392: this.mode = ((mode == null) || mode.isEmpty()) ? null :
>> mode;
>> 393: this.pad = ((pad == null) || pad.isEmpty()) ? null : pad;
>
> Thanks for reporting and fixing this issue.
> Since this is an internal class used solely inside `Cipher` class, instead of
> changing the empty string to null inside the `Transform` constuctor, we can
> do that before calling `Transform` constructor. Also if one of `mode` or
> `pad` is empty, then maybe we don't need all 4 `Transform`s.
For exampl, line 457, 458, we can do something like:
String mode = (parts[1].length() == 0 ? null : parts[1]);
String pad = (parts[2].length() == 0 ? null : parts[2]);
When populating the `list `(after line 467), we can skip the Tranform if the
required component is missing, e.g.
List list = new ArrayList<>(4);
if ((mode != null) && (pad != null)) {
list.add(new Transform(alg, "/" + mode + "/" + pad, null,
null));
}
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2127172956
Re: RFR: 8349550: Improve SASL random usage [v4]
On Fri, 30 May 2025 18:19:13 GMT, Koushik Muthukrishnan Thirupattur wrote: >> Check Digest-MD5 utilities SecureRandom Usage and update random usage with >> secure random > > Koushik Muthukrishnan Thirupattur has updated the pull request with a new > target base due to a merge or a rebase. The incremental webrev excludes the > unrelated changes brought in by the merge/rebase. The pull request contains > seven additional commits since the last revision: > > - 8349550: Improve SASL random usage > - Merge branch 'master' into 8349550 > - 8349550: Improve SASL random usage > - Merge branch 'master' into 8349550 > - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random > usage with secure random > - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random > usage with secure random > - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random > usage with secure random Marked as reviewed by mullan (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/25241#pullrequestreview-2897769890
Re: RFR: 8358099: PEM spec updates [v2]
On Tue, 3 Jun 2025 16:24:44 GMT, Sean Mullan wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> comments
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 127:
>
>> 125: * @implNote An implementation may support other PEM types and
>> 126: * {@code DEREncodable} objects. This implementation additionally
>> supports
>> 127: * PEM types: {@code X509 CERTIFICATE}, {@code X.509 CERTIFICATE},
>> {@code CRL},
>
> Suggest to insert "the following" before "PEM types"
"the following" should not be in the first sentence, only the second sentence,
as:
"This implementation additionally supports the following PEM types: ..."
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25620#discussion_r2127402367
Re: RFR: 8358099: PEM spec updates [v3]
> Hi, I need a review of some PEM updates. `PEMRecord.pem` is renamed to > `content` to better describe that it is the base64 content and not including > the header and footer. Additionally, `PEMRecord.getEncoded()` is removed and > some javadoc clarifications for PEMEncoder and PEMDecoder. Thanks. Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: wrong "PEM types" - Changes: - all: https://git.openjdk.org/jdk/pull/25620/files - new: https://git.openjdk.org/jdk/pull/25620/files/cbb00924..afdc32e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25620&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25620&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25620/head:pull/25620 PR: https://git.openjdk.org/jdk/pull/25620
Re: RFR: 8358594: Misleading keyLength value captured in JFR event for ML-KEM key [v3]
> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new > method `getNistCategory` to get the NIST security category. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: enhance test to be exhaustive - Changes: - all: https://git.openjdk.org/jdk/pull/25642/files - new: https://git.openjdk.org/jdk/pull/25642/files/157c53b9..5ec95fb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25642&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25642&range=01-02 Stats: 42 lines in 1 file changed: 25 ins; 8 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25642/head:pull/25642 PR: https://git.openjdk.org/jdk/pull/25642
Re: RFR: 8358171: Additional code coverage for PEM API [v3]
On Wed, 4 Jun 2025 16:49:11 GMT, Fernando Guallini
wrote:
>> The tests included in this PR add code coverage mainly to the following
>> classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem,
>> EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are
>> included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property
>> and some negative testing
>
> Fernando Guallini has updated the pull request incrementally with one
> additional commit since the last revision:
>
> add invalid PEM content test
test/jdk/java/security/PEM/PEMData.java line 500:
> 498: }
> 499: Entry(String name, String pem, Class clazz, String provider,
> char[] password) {
> 500: this(name, pem, clazz,provider, password, null);
nit: no space after comma
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2127792563
