On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote:
> There are several locations in the JDK source where `System.in` and
> `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the
> default charset. As recommended by the recently merged
> [JDK-8356420](https://bugs.open
On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote:
> There are several locations in the JDK source where `System.in` and
> `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the
> default charset. As recommended by the recently merged
> [JDK-8356420](https://bugs.open
There are several locations in the JDK source where `System.in` and
`FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the
default charset. As recommended by the recently merged
[JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces
the default charse
On Wed, 21 May 2025 14:48:28 GMT, Artur Barashev wrote:
>> The stateless session ticket is included in the ClientHello message, either
>> in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key
>> extension (TLS1.3). With the current construction, the ticket is often the
>> la
On Tue, 20 May 2025 11:01:46 GMT, Per Minborg wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix copyright year
>
> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
> line 459:
>
>
> The stateless session ticket is included in the ClientHello message, either
> in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key
> extension (TLS1.3). With the current construction, the ticket is often the
> largest contributor to the ClientHello message size. For example
On Wed, 21 May 2025 06:50:28 GMT, Daniel Jeliński wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> encrypt() should return an empty byte array on failure
>
> src/java.base/share/classes/sun/security/ssl/SessionTic
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
> instances can be used in classes that were not covered by
> https://github.com/openjdk/jdk/pull/25321
>
> This PR passes tier1, tier2, and tier3
> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
> instances can be used in classes that were not covered by
> https://github.com/openjdk/jdk/pull/25321
>
> This PR passes tier1, tier2, and tier3
On 5/21/25 2:56 AM, Stian Thorgersen wrote:
Thanks,
Are there also plans to add X25519MLKEM768, SecP256r1MLKEM768, and
SecP384r1MLKEM1024 hybrid key agreements from https://
datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/>?
Yes.
On Wed, 21 May 2025 09:10:57 GMT, Alan Bateman wrote:
> > > A question for folks on security-dev. Are there tests for Cipher.doFinal,
> > > CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer
> > > obtained from a memory segment?
> >
> >
> > I don't find any. We'd have to u
On Wed, 21 May 2025 05:00:16 GMT, Valerie Peng wrote:
> > A question for folks on security-dev. Are there tests for Cipher.doFinal,
> > CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer
> > obtained from a memory segment?
>
> I don't find any. We'd have to update them to c
12 matches
Mail list logo
