On Mon, 18 Apr 2022 20:43:06 GMT, Smita Kamath wrote:
>> When input length provided to the intrinsic is 8192, only 7680 bytes are
>> processed as the intrinsic operates on multiples of 768 bytes.
>> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method,
>> dst.put(bout, 0, PARALLEL_LEN)
On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński wrote:
> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
> portion of time is spent in HandshakeContext initialization, specifically in
> DisabledAlgorithmConstraints class.
>
> There are only a few instances of
On Thu, 21 Apr 2022 23:15:10 GMT, Valerie Peng wrote:
>>> For (1), how about something like below:
>>>
>>> > ```
>>> > * The returned parameters may be the same that were used to initialize
>>> > * this cipher, or may contain additional default or random parameter
>>> > * values used by the
On Wed, 20 Apr 2022 16:40:34 GMT, Sean Mullan wrote:
>>> Hmm, I tried the suggested approach in (1), the result looks very lengthy.
>>> Actually, the Cipher.init(..) methods already has a few paragraphs
>>> describing the behavior for parameter generation, perhaps we should not
>>> repeat
Nice.
On 22/04/2022 6:47 am, Daniel Jeliński wrote:
On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński wrote:
Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
portion of time is spent in HandshakeContext initialization, specifically in
Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
portion of time is spent in HandshakeContext initialization, specifically in
DisabledAlgorithmConstraints class.
There are only a few instances of that class, and they are immutable. Caching
the results should be a
On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński wrote:
> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
> portion of time is spent in HandshakeContext initialization, specifically in
> DisabledAlgorithmConstraints class.
>
> There are only a few instances of
> I ran `codespell` on modules owned by the security team (`java.security.jgss
> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
> accepted those changes where it indeed discovered real typos.
>
On Thu, 21 Apr 2022 14:11:08 GMT, Alan Bateman wrote:
>> I ran `codespell` on modules owned by the security team (`java.security.jgss
>> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
>> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
>>
On Thu, 21 Apr 2022 14:11:08 GMT, Alan Bateman wrote:
>> I ran `codespell` on modules owned by the security team (`java.security.jgss
>> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
>> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
>>
On Thu, 21 Apr 2022 13:51:27 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on modules owned by the security team (`java.security.jgss
> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
>
I ran `codespell` on modules owned by the security team (`java.security.jgss
java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
accepted those changes where it indeed discovered real typos.
I will
On Thu, 21 Apr 2022 06:50:58 GMT, Xue-Lei Andrew Fan wrote:
>> I'd recommend setting `cleanable` to null after it's been cleaned to make
>> the state machine easier to reason about. The invariant would be: if
>> `cleanable` is non-null, then we have something dirty that needs to be
>>
On Wed, 20 Apr 2022 23:38:59 GMT, Stuart Marks wrote:
>> Calling `Cleanable.clean()` calls the `Runnable` action at-most-once.
>> Each `Cleanable` inserted in a list when it is created and is removed when
>> `clear()` or `clean()` is invoked.
>> The action is called only if it is still in the
> Please review this password cleanup enhancement in the PasswordCallback
> implementation. This is one of the effort to clean up the buffered passwords.
>
> The PasswordCallback.setPassword() clones the password, but is not registered
> for cleanup. An application could call clearPassword()
15 matches
Mail list logo
