On Fri, 13 Nov 2020 21:00:20 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Code review comment update
>> Major change to test to detect corruption with incremental buffers test
>
>
On Mon, 16 Nov 2020 19:23:20 GMT, Valerie Peng wrote:
>> You don't know what 'len', which includes ibuffer data, until this point in
>> the code.
>
> Well, didn't you already calcuate the 'len' value in the beginning of the
> copied-from-GCTR RuntimeException check?
I'm removing the runtime
On Mon, 16 Nov 2020 19:17:55 GMT, Valerie Peng wrote:
>> This is a very seldom used code path, There was only one existing test that
>> accesses this code and it has not offset.
>>
>> constructBlock() is a generic method. There should be no case where ibuffer
>> is >= blocksize during this
On Fri, 6 Nov 2020 23:09:31 GMT, Valerie Peng wrote:
>> This is not an optimized path for bytebuffers and will never have any data
>> in ibuffer.
>
> Hmm, ok, can we add a check on ibuffer size here just to be sure?
I've rewritten checkDataLength so it can include more values to calculate.
On Tue, 17 Nov 2020 22:21:18 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> Jim Laskey has
> Hello all,
> This change brings in support for certificates with EdDSA keys (both Ed25519
> and Ed448) allowing those signature algorithms to be used both on the
> certificates themselves and used during the handshaking process for messages
> like CertificateVerify, ServerKeyExchange and so
On Tue, 17 Nov 2020 23:31:13 GMT, Jamil Nimeh wrote:
>> I don't think there's any reason why we could use a
>> Collection for these. I'll try switching to that.
>
> Xuelei, I went back and looked at my rationale for using Strings here. The
> reason I went with this approach was so I could
On Tue, 17 Nov 2020 19:43:25 GMT, Jamil Nimeh wrote:
>> test/jdk/javax/net/ssl/TLSCommon/TLSWithEdDSA.java line 81:
>>
>>> 79: static final String DEF_ALL_EE =
>>> "EE_ECDSA_SECP256R1:EE_ECDSA_SECP384R1:" +
>>> 80: "EE_ECDSA_SECP521R1:EE_RSA_2048:EE_EC_RSA_SECP256R1:" +
>>> 81:
On Tue, 17 Nov 2020 18:32:34 GMT, Xue-Lei Andrew Fan wrote:
>> Hello all,
>> This change brings in support for certificates with EdDSA keys (both Ed25519
>> and Ed448) allowing those signature algorithms to be used both on the
>> certificates themselves and used during the handshaking process
On Fri, 6 Nov 2020 23:08:10 GMT, Valerie Peng wrote:
>> I does not. CipherCore only sends block sized data, and the ByteBuffer code
>> uses this method during final operations.
>
> Hmm, ok, this is getting obscure and the correctness is depending on the
> calling pattern. Can we add a check
On Fri, 6 Nov 2020 23:02:54 GMT, Valerie Peng wrote:
>> If the output buffer provided is not big enough, it creates an internal one.
>> Two things happened here, one the variable was renamed because I felt
>> "outWithPadding" was misleading. The second was to only create this buffer
>> when
On Thu, 12 Nov 2020 20:17:39 GMT, Valerie Peng wrote:
>> checkOutputCapacity: Yes.. The method includes the offsets for the output
>> buffer, which I believe would verify that the output area in the buffer with
>> offsets is large enough.
>>
>> outWithPadding: I understand the situation and
On Tue, 17 Nov 2020 22:12:19 GMT, Jim Laskey wrote:
>> @kevinrushforth What is the recommended approach to remove the doc
>> edit/commit?
>
> javadoc can be found at
> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
Presuming your master branch
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
Jim Laskey has updated the pull request with a new target base due to a
On Tue, 17 Nov 2020 21:59:04 GMT, Jim Laskey wrote:
>>> my local branch seems to have the right sources for doc
>>
>> Maybe, but your branch on GitHub does not.
>
> @kevinrushforth What is the recommended approach to remove the doc
> edit/commit?
javadoc can be found at
On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote:
>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
>
> Maybe, but your branch on GitHub does not.
@kevinrushforth What is the recommended approach to remove
This is a micro benchmark for various algorithm settings of PKCS keystores.
Strong for new algorithms and weak for old ones. Different iteration counts are
tried. The result should show that the current setting (strong1) is more
efficient than old setting (weak5).
-
Commit
> On Apr 10, 2020, at 5:03 AM, Weijun Wang wrote:
>
> Please take a review at
>
> CSR : 8228481: Upgrade the default PKCS12 encryption/MAC algorithms
> Release note : https://bugs.openjdk.java.net/browse/JDK-8242069
I forget if the release note has been reviewed before. If not,
On Tue, 17 Nov 2020 19:36:31 GMT, Sean Mullan wrote:
>> New commit and the output will look like:
>> PSSParameterSpec[hashAlgorithm=SHA-256,
>> maskGenAlgorithm=MGF1ParameterSpec[hashAlgorithm=SHA-256], saltLength=32,
>> trailerField=1]
>> I'm using the ASN.1 field names here. (Precisely the
On Tue, 17 Nov 2020 21:33:13 GMT, Magnus Ihse Bursie wrote:
>>> my local branch seems to have the right sources for doc
>>
>> Maybe, but your branch on GitHub does not.
>
> This PR looks seriously messed up:
>
> JimLaskey added 30 commits on Oct 9
> @JimLaskey
> 8248862: Implement Enhanced
On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote:
>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
>
> Maybe, but your branch on GitHub does not.
This PR looks seriously messed up:
JimLaskey added 30
On Tue, 17 Nov 2020 20:56:52 GMT, Jim Laskey wrote:
> my local branch seems to have the right sources for doc
Maybe, but your branch on GitHub does not.
-
PR: https://git.openjdk.java.net/jdk/pull/1273
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
Jim Laskey has updated the pull request incrementally with one additional
On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> It looks like
On Tue, 17 Nov 2020 19:47:37 GMT, Jamil Nimeh wrote:
>> test/jdk/javax/net/ssl/TLSCommon/TLSWithEdDSA.java line 583:
>>
>>> 581: serverParameters.put(ParamType.CERTALIAS, "EE_ED25519");
>>> 582: runtest(testFormat, isPeerEd25519, null, null, null);
>>> 583:
On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> It looks like
On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote:
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
It looks like you have
This PR is to introduce a new random number API for the JDK. The primary API is
found in RandomGenerator and RandomGeneratorFactory. Further description can be
found in the JEP https://openjdk.java.net/jeps/356 .
-
Commit messages:
- 8248862: Implement Enhanced Pseudo-Random
On Tue, 17 Nov 2020 19:07:33 GMT, Xue-Lei Andrew Fan wrote:
>> Hello all,
>> This change brings in support for certificates with EdDSA keys (both Ed25519
>> and Ed448) allowing those signature algorithms to be used both on the
>> certificates themselves and used during the handshaking process
On Tue, 17 Nov 2020 18:29:13 GMT, Xue-Lei Andrew Fan wrote:
>> Hello all,
>> This change brings in support for certificates with EdDSA keys (both Ed25519
>> and Ed448) allowing those signature algorithms to be used both on the
>> certificates themselves and used during the handshaking process
On Tue, 17 Nov 2020 18:24:35 GMT, Xue-Lei Andrew Fan wrote:
>> Hello all,
>> This change brings in support for certificates with EdDSA keys (both Ed25519
>> and Ed448) allowing those signature algorithms to be used both on the
>> certificates themselves and used during the handshaking process
On Tue, 17 Nov 2020 15:34:37 GMT, Weijun Wang wrote:
> New commit and the output will look like:
>
> ```
> PSSParameterSpec[hashAlgorithm=SHA-256,
> maskGenAlgorithm=MGF1ParameterSpec[hashAlgorithm=SHA-256], saltLength=32,
> trailerField=1]
> ```
>
> I'm using the ASN.1 field names here.
On Fri, 13 Nov 2020 04:57:12 GMT, Jamil Nimeh wrote:
> Hello all,
> This change brings in support for certificates with EdDSA keys (both Ed25519
> and Ed448) allowing those signature algorithms to be used both on the
> certificates themselves and used during the handshaking process for
On Tue, 17 Nov 2020 18:09:03 GMT, Xue-Lei Andrew Fan wrote:
>> Sean Mullan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More test changes.
>
> Marked as reviewed by xuelei (Reviewer).
Hi Sean,
The changes to the HttpClient test
On Tue, 17 Nov 2020 17:55:19 GMT, Sean Mullan wrote:
>> This change disables the TLSv1 and TLSv1.1 protocols by adding them to the
>> jdk.tls.disabledAlgorithms security property in the java.security file.
>> These protocols use weak algorithms and are being deprecated by the IETF.
>> They
On Tue, 17 Nov 2020 17:55:19 GMT, Sean Mullan wrote:
>> This change disables the TLSv1 and TLSv1.1 protocols by adding them to the
>> jdk.tls.disabledAlgorithms security property in the java.security file.
>> These protocols use weak algorithms and are being deprecated by the IETF.
>> They
> This change disables the TLSv1 and TLSv1.1 protocols by adding them to the
> jdk.tls.disabledAlgorithms security property in the java.security file. These
> protocols use weak algorithms and are being deprecated by the IETF. They
> should be disabled by default to improve the default security
On Mon, 16 Nov 2020 16:30:04 GMT, Sean Mullan wrote:
>> minor comment on spacing for MGF1 toString()
>
>> Do you want me to consolidate `PSSParameterSpec::toString` into one line?
>> Multi-line toString is usually not very friendly to debug output (esp for
>> grep).
>
> Good question.
> Without this method, `PSSParameterSpec::toString` shows something like:
> MD: SHA-256
> MGF: java.security.spec.MGF1ParameterSpec@77b52d12
> SaltLength: 32
> TrailerField: 1
> This is ugly.
>
> Noreg-trivial.
Weijun Wang has updated the pull request incrementally with one additional
commit
On Mon, 16 Nov 2020 22:02:05 GMT, Xue-Lei Andrew Fan wrote:
>> This change disables the TLSv1 and TLSv1.1 protocols by adding them to the
>> jdk.tls.disabledAlgorithms security property in the java.security file.
>> These protocols use weak algorithms and are being deprecated by the IETF.
>>
On Mon, 16 Nov 2020 22:04:21 GMT, Sean Mullan wrote:
>> I like the 2nd one better, but I'll see how Sean thinks about the verbose
>> record-style toString.
>
> 99% of the time, it will probably be one of the MGF1ParameterSpec constants.
> For those, perhaps it would be nice to just use the
> This patch contains the changes associated with the first incubation round of
> the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
> access support (see JEP 393 [2] and associated pull request [3]).
>
> The main goal of this
On Mon, 16 Nov 2020 18:44:55 GMT, Rajan Halade wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix aarch64 test failure
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 387:
>
43 matches
Mail list logo
