On Wed, 20 Aug 2025 00:00:51 GMT, Weijun Wang wrote:
> Also, is this consistent among other security providers?
Whether it's NSAE or NSPE depends on how security provider registers the
support. The updated wording in the PR reflects the current JCA behavior, i.e.
Cipher lookup, and should be c
On Tue, 19 Aug 2025 23:59:09 GMT, Weijun Wang wrote:
> I wonder if we should list NSPE before NSAE, since NSAE refers to it.
>
> Or, can we just say NSAE is thrown when the specified algorithm and mode are
> not supported?
Yes, it makes sense to list NSPE before NSAE.
As for the NSAE vs NSPE,
On Tue, 12 Aug 2025 00:12:39 GMT, Valerie Peng wrote:
> The current `getNativeKeyInfo(...)` method impl inside SunPKCS11 provider's
> p11_keymgmt.c queries key attributes and pack the resulting data into a blob
> which is later passed to the `createNativeKey(...)` method to create a native
> k
On Wed, 20 Aug 2025 01:26:19 GMT, Valerie Peng wrote:
>> This patch adds configurability to `PKCS11Test.java`.
>>
>> Specifically, it adds two new system properties:
>>
>> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the
>> `nss_library` field. Prior to this patch, `nss
On Tue, 15 Jul 2025 16:43:16 GMT, Thomas Fitzsimmons wrote:
> This patch adds configurability to `PKCS11Test.java`.
>
> Specifically, it adds two new system properties:
>
> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the
> `nss_library` field. Prior to this patch, `nss
On Tue, 15 Jul 2025 16:43:16 GMT, Thomas Fitzsimmons wrote:
> This patch adds configurability to `PKCS11Test.java`.
>
> Specifically, it adds two new system properties:
>
> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the
> `nss_library` field. Prior to this patch, `nss
On Thu, 14 Aug 2025 15:17:09 GMT, Weijun Wang wrote:
> See the bug report for details. Basically, entries in the SF set should
> always be removed no matter if it's treated signed or not.
This pull request has now been integrated.
Changeset: eca2032c
Author:Weijun Wang
URL:
https:/
On Wed, 13 Aug 2025 00:13:25 GMT, Valerie Peng wrote:
>> This PR is for clarifying the `NoSuchAlgorithmException` and
>> `NoSuchPaddingException` for the `Cipher.getInstance(String transformation,
>> Provider provider)` and `Cipher.getInstance(String transformation, String
>> provider)` method
On Mon, 18 Aug 2025 15:31:21 GMT, Roger Riggs wrote:
> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the
> string. The "shared" flag
On Tue, 19 Aug 2025 20:32:23 GMT, Roger Riggs wrote:
>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
>> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the
>> string. The "shared" f
On Tue, 15 Jul 2025 16:43:16 GMT, Thomas Fitzsimmons wrote:
> This patch adds configurability to `PKCS11Test.java`.
>
> Specifically, it adds two new system properties:
>
> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the
> `nss_library` field. Prior to this patch, `nss
On Tue, 19 Aug 2025 20:32:23 GMT, Roger Riggs wrote:
>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
>> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the
>> string. The "shared" f
> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the
> string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
Rog
On Tue, 19 Aug 2025 19:24:51 GMT, Roger Riggs wrote:
>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
>> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the
>> string. The "shared" f
> This bug fix is to change PEMDecoder.decode(..., Class<>) using
> PKCS8EncodedKeySpec and X509EncodedKeySpec will throw an
> IllegalArgumentException when the decoded data does not match. It should be
> ClassCastException.
>
> Thanks
>
> Tony
Anthony Scarpino has updated the pull request in
> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the
> string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
Rog
On Tue, 19 Aug 2025 18:42:58 GMT, Johannes Döbler wrote:
>> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding
>> JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
>> There is no decoding needed, and no exceptions expected or thrown when
>> creating the string from the supplie
On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs wrote:
> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding
> JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when
> creating the string from the supplied latin1
On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs wrote:
> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding
> JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when
> creating the string from the supplied latin1
On Tue, 19 Aug 2025 17:57:20 GMT, Roger Riggs wrote:
>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
>> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the
>> string. The "shared" f
On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs wrote:
> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding
> JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when
> creating the string from the supplied latin1
On Tue, 19 Aug 2025 17:50:34 GMT, Volkan Yazici wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Flesh out javadoc in src/java.base/share/classes/java/lang/String.java
>>
>> Co-authored-by: Volkan Yazıcı
>
> Ma
> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the
> string. The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
Rog
On Mon, 18 Aug 2025 15:31:21 GMT, Roger Riggs wrote:
> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the
> string. The "shared" flag
On Tue, 19 Aug 2025 14:33:54 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/util/zip/ZipCoder.java line 283:
>>
>>> 281: // We use the JLA.newStringUTF8NoRepl variant to throw
>>> 282: // exceptions eagerly when opening ZipFiles
>>> 283:
On Mon, 18 Aug 2025 21:34:39 GMT, Roger Riggs wrote:
> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding
> JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
> There is no decoding needed, and no exceptions expected or thrown when
> creating the string from the supplied latin1
On Tue, 12 Aug 2025 19:29:28 GMT, Volkan Yazici wrote:
>> `NoRepl`-suffixed `String` methods denote methods that do not replace
>> invalid characters, but throw `CharacterCodingException` on encounter. This
>> behavior cannot easily be derived from the method footprints, has been a
>> source o
On Mon, 18 Aug 2025 15:31:21 GMT, Roger Riggs wrote:
> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the
> string. The "shared" flag
On Tue, 19 Aug 2025 14:11:29 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 330:
>>
>>> 328: * @return the newly created string
>>> 329: */
>>> 330: String uncheckedNewStringWithLatin1Bytes(byte[] bytes);
>>
>> @RogerRiggs, we i
On Wed, 23 Jul 2025 11:00:57 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
A copy of the bytes is made so it can be exclusively used to create the string.
The "shared" flag is no longer needed in String.newStringUTF8NoRepl.
---
On Tue, 19 Aug 2025 05:48:36 GMT, Volkan Yazici wrote:
>> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
>> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
>> A copy of the bytes is made so it can be exclusively used to create the
>> string. The "shared"
On Mon, 18 Aug 2025 15:31:21 GMT, Roger Riggs wrote:
> Simplify JLA by changing ZipCoder to use JLA.uncheckedNewStringNoRepl(byte[]
> bytes, Charset cs) instead of the JLA.newStringUTF8NoRepl.
> A copy of the bytes is made so it can be exclusively used to create the
> string. The "shared" flag
On Tue, 12 Aug 2025 19:29:28 GMT, Volkan Yazici wrote:
>> `NoRepl`-suffixed `String` methods denote methods that do not replace
>> invalid characters, but throw `CharacterCodingException` on encounter. This
>> behavior cannot easily be derived from the method footprints, has been a
>> source o
On Thu, 24 Jul 2025 12:21:56 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
On Thu, 24 Jul 2025 19:28:16 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
On Thu, 24 Jul 2025 17:04:52 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
On Tue, 19 Aug 2025 06:00:16 GMT, Volkan Yazici wrote:
>> Refactor uses of JLAuncheckedNewStringNoRepl(byte[], ISO_8859_1) adding
>> JLA.uncheckedNewStringWithLatin1Bytes(byte[]).
>> There is no decoding needed, and no exceptions expected or thrown when
>> creating the string from the supplied
On Thu, 24 Jul 2025 16:02:44 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
On Thu, 24 Jul 2025 15:31:21 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
On Thu, 24 Jul 2025 15:20:37 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
On Mon, 18 Aug 2025 20:02:46 GMT, ExE Boss wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> PEM reading tweak
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 63:
>
>> 61: */
>> 6
On Mon, 30 Jun 2025 09:45:12 GMT, Daniel Fuchs wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 124:
>>
>>> 122: // exchange so that it can be aborted/timed out mid setup.
>>> 123: final class ConnectionAborter {
>>> 124: // In case of HTTP/3 dir
On Fri, 27 Jun 2025 12:47:23 GMT, Daniel Fuchs wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 121:
>>
>>> 119: }
>>> 120:
>>> 121: // Keeps track of the underlying connection when establishing an
>>> HTTP/2
>>
>> since this is now used with HTTP/3,
On Fri, 27 Jun 2025 15:27:10 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 525 commits:
>>
>> - merge latest changes from master branch
>> - http3: run H3StreamLimitReachedTest.java wit
On Tue, 1 Jul 2025 11:13:44 GMT, Daniel Jeliński 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 525 commits:
>>
>> - merge latest changes from master branch
>> - http3: run H3StreamLimitReachedTest.java w
On Wed, 16 Jul 2025 11:19:42 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
On Thu, 24 Jul 2025 16:59:12 GMT, Daniel Jeliński 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 550 commits:
>>
>> - merge latest changes from master branch
>> - http3: fix new HttpHeadersBuilder constru
On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan wrote:
>> No change should be made to any explicit setting of the timeoutFactor in
>> general as that could cause mass timeouts to occur (old default timeout =
>> 120 * 10 = 1200 but new default = 120 * 2.5 = 300!).
>>
>> However I see the concern o
On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes wrote:
> By rough count there are 1300 tests that have an explicit timeout set. This
> change would reduce the actual applied timeout to a quarter of what was
> previously used, yet you have only had to bump the timeout value for a
> fraction of t
50 matches
Mail list logo
