On Thu, 24 Mar 2022 06:48:00 GMT, Bradford Wetmore wrote:
>>> @XueleiFan, I'm not following your first comment.
>>
>> Sorry for that. I was wondering something new in the future, which is not
>> doable in the current Java language. Please just leave it alone.
>
> Ah! Thanks.
> IIUC, you are
On Wed, 23 Mar 2022 18:09:46 GMT, Xue-Lei Andrew Fan wrote:
>> Bradford Wetmore 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 12 additional
>>
Hi List,
I find it a bit strange that every user of crypto either have to write or
install specific software for converting JOSE/COSE/PEM keys back-and-forth to
Java's internal representation. This reduces the value of the abstract types as
well.
Now there is whole bunch of new algorithms com
On Wed, 23 Mar 2022 21:59:02 GMT, Valerie Peng wrote:
>> I see.
>>
>> Would you mind add a comment about the provider loading impact, just in case
>> someone else have similar questions in the future?
>
> Sure, I can do that. Will add a comment about this.
Thank you. I have no more comment ex
On Wed, 23 Mar 2022 22:48:41 GMT, Valerie Peng wrote:
>> It's been several years since we increased the default key sizes. Before
>> shifting to PQC, NSA replaced its Suite B cryptography recommendations with
>> the Commercial National Security Algorithm Suite which suggests:
>>
>> - SHA-384 f
On Wed, 23 Mar 2022 18:09:46 GMT, Xue-Lei Andrew Fan wrote:
>> Bradford Wetmore 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 12 additional
>>
On Thu, 24 Mar 2022 00:52:28 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line
>> 114:
>>
>>> 112: * recommended to explicitly specify all desired parameter
>>> 113: * values with
>>> 114: * {@link #PSSPa
On Wed, 23 Mar 2022 02:51:08 GMT, Weijun Wang wrote:
>> Can someone help review this update to the PSSParameterSpec class regarding
>> the constructor with int argument and the DEFAULT static field? Just added
>> @Deprecate javadoc tag and caution about their usage as suggested in the bug
>> r
On Wed, 23 Mar 2022 02:46:20 GMT, Weijun Wang wrote:
>> Can someone help review this update to the PSSParameterSpec class regarding
>> the constructor with int argument and the DEFAULT static field? Just added
>> @Deprecate javadoc tag and caution about their usage as suggested in the bug
>> r
On Wed, 23 Mar 2022 02:37:18 GMT, Weijun Wang wrote:
>> Can someone help review this update to the PSSParameterSpec class regarding
>> the constructor with int argument and the DEFAULT static field? Just added
>> @Deprecate javadoc tag and caution about their usage as suggested in the bug
>> r
> It's been several years since we increased the default key sizes. Before
> shifting to PQC, NSA replaced its Suite B cryptography recommendations with
> the Commercial National Security Algorithm Suite which suggests:
>
> - SHA-384 for secure hashing
> - AES-256 for symmetric encryption
> - RS
On Wed, 23 Mar 2022 21:51:51 GMT, Xue-Lei Andrew Fan wrote:
>> My very first prototype is to implement the AES keysize calculation as you
>> commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE.
>> However, it is later discovered through testing that this leads to deadlocks
On Wed, 23 Mar 2022 20:45:22 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java
>> line 129:
>>
>>> 127: return currVal;
>>> 128: }
>>> 129:
>>
>> I'm not very sure of this method. Is it performance friendly if making the
>>
On Wed, 23 Mar 2022 04:46:48 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Minor code refactoring
>
> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java
> line 1
> Fix repeated typo `exeption`
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8283426: Fix 'exeption' typo
Co-authored-by: Alexey Ivanov <[email protected]>
-
Changes:
- all: https:
On Mon, 21 Mar 2022 19:40:07 GMT, Sean Mullan wrote:
> This fix removes obsolete and deprecated 3DES cipher suites from the default
> enabled cipher suites list of the SunJSSE provider implementation.
>
> Note that 3DES suites are already disabled by default via the
> `jdk.tls.disabledAlgorit
On Wed, 23 Mar 2022 17:01:12 GMT, Bradford Wetmore wrote:
>> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal
>> internal_error (80) and invalidate existing sessions (either completed or
>> under construction) as described in (RFC 4346/TLSv1.1+) if a connection was
>> c
Offhand, sounds like a bug to me. I've filed:
https://bugs.openjdk.java.net/browse/JDK-8283577
to track.
It's possible an optimization might have been done using an in-place
en/decryption, but it should work.
By chance, do you have a simple reproducer handy? If not, we should be
able to c
> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal
> internal_error (80) and invalidate existing sessions (either completed or
> under construction) as described in (RFC 4346/TLSv1.1+) if a connection was
> closed without receiving a close_notify alert from the peer.
>
Hi,
In Netty we've been trying to design some safer APIs, and attempted to make
more use of read-only ByteBuffers.
We discovered that SSLEngine.unwrap does not like read-only input buffers,
even though the input buffers should in theory only be read from. We
obviously make sure that the output bu
On Wed, 23 Mar 2022 15:10:21 GMT, Xue-Lei Andrew Fan wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 799:
>>
>>> 797: } finally {
>>> 798: conContext.closeInbound();
>>> 799: engineLock.unlock();
>>
>> I see that `onContext.
On Wed, 23 Mar 2022 11:34:33 GMT, Daniel Fuchs wrote:
>> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal
>> internal_error (80) and invalidate existing sessions (either completed or
>> under construction) as described in (RFC 4346/TLSv1.1+) if a connection was
>> close
> This PR contains the API and implementation changes for JEP-424 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/424
Maurizio Cimadamore has updated the pull request
On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote:
> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal
> internal_error (80) and invalidate existing sessions (either completed or
> under construction) as described in (RFC 4346/TLSv1.1+) if a connection was
> close
On Wed, 23 Mar 2022 07:31:23 GMT, Andrey Turbanov wrote:
>> Fix repeated typo `exeption`
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8283426: Fix 'exeption' typo
> fix more typos, found by Sean Coffey
Marked as re
> Fix repeated typo `exeption`
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8283426: Fix 'exeption' typo
fix more typos, found by Sean Coffey
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7879/files
26 matches
Mail list logo
