Hi,
the last update to the public suffix list happened about a year ago with
JDK-8255266 [0]. Are there plans for a next update?
Thanks
Christoph
[0] https://bugs.openjdk.org/browse/JDK-8255266
On Wed, 15 Feb 2023 19:35:07 GMT, Valerie Peng wrote:
>> We would like to propose an implementation for the [JDK-8301553: Support
>> Password-Based Cryptography in
>> SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement
>> requirement.
>>
>> In addition to pursuing the requirem
On Thu, 16 Feb 2023 01:30:49 GMT, Valerie Peng wrote:
>> Due to an error in the existing regression test, this bug remain
>> undiscovered until now. Added the key size check to the KeyWrapCipher class
>> and fixed the regression test.
>>
>> Please help review this trivial fix.
>>
>> Thanks in
> Due to an error in the existing regression test, this bug remain undiscovered
> until now. Added the key size check to the KeyWrapCipher class and fixed the
> regression test.
>
> Please help review this trivial fix.
>
> Thanks in advance,
> Valerie
Valerie Peng has updated the pull request
On Wed, 15 Feb 2023 05:30:06 GMT, Xue-Lei Andrew Fan wrote:
>> Due to an error in the existing regression test, this bug remain
>> undiscovered until now. Added the key size check to the KeyWrapCipher class
>> and fixed the regression test.
>>
>> Please help review this trivial fix.
>>
>> Tha
On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote:
> We would like to propose an implementation for the [JDK-8301553: Support
> Password-Based Cryptography in
> SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement
> requirement.
>
> In addition to pursuing the requirement goa
On Mon, 30 Jan 2023 12:26:57 GMT, Lutz Schmidt wrote:
>> This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a
>> message is ciphered in multiple, small (< 16 bytes) segments, the result is
>> incorrect.
>>
>> This is not just a band-aid fix. The issue was taken as a chance
On Thu, 9 Feb 2023 20:59:37 GMT, Sean Mullan wrote:
> Please review this change to increase the default Diffie-Hellman group size
> used in the key exchange method of TLS_DHE cipher suites from 1024-bit to
> 2048-bit. This issue does not affect TLS 1.3 as the minimum DH group size is
> 2048 bi
On Wed, 15 Feb 2023 11:32:32 GMT, Lance Andersen wrote:
>> The habit of opening resources in a TwR is hard to break, but I guess it's
>> ok for a test like this. I have inlined the method and removed the TwR.
>
>> The habit of opening resources in a TwR is hard to break, but I guess it's
>> ok
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Wed, 15 Feb 2023 09:55:04 GMT, Eirik Bjorsnos wrote:
> The habit of opening resources in a TwR is hard to break, but I guess it's ok
> for a test like this. I have inlined the method and removed the TwR.
Agree, thanks for addressing the suggestion as it makes the test cleaner given
expects/
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
On Tue, 14 Feb 2023 23:12:38 GMT, Lance Andersen wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Prefer expectThrows with asserts over test annotation regex
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryN
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
14 matches
Mail list logo
