Re: RFR: 8256523: Streamline Java SHA2 implementation

2020-11-19 Thread Aleksey Shipilev
On Fri, 20 Nov 2020 00:14:55 GMT, Valerie Peng wrote: >> Current `sun/security/provider/SHA2` implementation is written with lots of >> small method invocations on the fastpath in `implCompress0`. Normally it >> does not matter much, because compilers are able to inline through it, and >>

Re: RFR: 8256523: Streamline Java SHA2 implementation

2020-11-19 Thread Valerie Peng
On Wed, 18 Nov 2020 08:29:49 GMT, Aleksey Shipilev wrote: > Current `sun/security/provider/SHA2` implementation is written with lots of > small method invocations on the fastpath in `implCompress0`. Normally it does > not matter much, because compilers are able to inline through it, and then

Re: RFR: 8253821: Improve ByteBuffer performance with GCM [v4]

2020-11-19 Thread Valerie Peng
On Wed, 18 Nov 2020 05:14:11 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java >> line 560: >> >>> 558: System.arraycopy(buffer, 0, block, 0, blockSize); >>> 559: buflen -= block.length; >>> 560:

Re: RFR: 8253821: Improve ByteBuffer performance with GCM [v4]

2020-11-19 Thread Valerie Peng
On Wed, 18 Nov 2020 04:28:38 GMT, Anthony Scarpino wrote: >> The current impl of constructBlock() seems to have code handling ibuffer >= >> blocksize scenario. Could you fix that and also pass the input offset into >> constructBlock() for this RFE? > > I redid the whole code Sure, I will be

Integrated: JDK-8256682: JDK-8202343 is incomplete

2020-11-19 Thread Sean Mullan
On Thu, 19 Nov 2020 18:49:07 GMT, Sean Mullan wrote: > The fix for disabling TLS 1.0 and 1.1 is causing intermittent failures of > this test which depends on TLSv1 and v1.1. This test needs to run its own VM > because it now needs to modify a security property to re-enable TLSv1 and > v1.1.

Re: RFR: JDK-8256682: JDK-8202343 is incomplete

2020-11-19 Thread Daniel Fuchs
On Thu, 19 Nov 2020 18:49:07 GMT, Sean Mullan wrote: > The fix for disabling TLS 1.0 and 1.1 is causing intermittent failures of > this test which depends on TLSv1 and v1.1. This test needs to run its own VM > because it now needs to modify a security property to re-enable TLSv1 and > v1.1.

RFR: JDK-8256682: JDK-8202343 is incomplete

2020-11-19 Thread Sean Mullan
The fix for disabling TLS 1.0 and 1.1 is causing intermittent failures of this test which depends on TLSv1 and v1.1. This test needs to run its own VM because it now needs to modify a security property to re-enable TLSv1 and v1.1. - Commit messages: - JDK-8256682: JDK-8202343 is

Re: RFR: JDK-8166596: TLS support for the EdDSA signature algorithm [v3]

2020-11-19 Thread Jamil Nimeh
> 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

Integrated: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Hai-May Chao
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. This pull request has now been integrated. Changeset: 9bb82232 Author:Hai-May Chao Committer: Lance Andersen URL:

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Hai-May Chao
On Thu, 19 Nov 2020 17:13:00 GMT, Lance Andersen wrote: >> Small change to retrieve the raw bytes of manifest during verifying signed >> JAR. > > Marked as reviewed by lancea (Reviewer). Thank you all for the review. I added the noreg-trivial label to the bug. - PR:

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Hai-May Chao
On Thu, 19 Nov 2020 17:20:58 GMT, Hai-May Chao wrote: >> Marked as reviewed by lancea (Reviewer). > > Thank you all for the review. I added the noreg-trivial label to the bug. Lance, I've entered /integrate. Thank you for sponsoring this! - PR:

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Lance Andersen
On Thu, 19 Nov 2020 17:08:21 GMT, Alan Bateman wrote: >> Small change to retrieve the raw bytes of manifest during verifying signed >> JAR. > > Marked as reviewed by alanb (Reviewer). I can sponsor once you integrate - PR: https://git.openjdk.java.net/jdk/pull/1299

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Lance Andersen
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1299

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Alan Bateman
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1299

Integrated: 8202343: Disable TLS 1.0 and 1.1

2020-11-19 Thread Sean Mullan
On Mon, 16 Nov 2020 20:18:16 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 > should

Re: RFR: 8256507: Add a micro benchmark for JDK-8153005 [v2]

2020-11-19 Thread Weijun Wang
On Thu, 19 Nov 2020 07:58:36 GMT, Aleksey Shipilev wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> not static anymore > > test/micro/org/openjdk/bench/java/security/PKCS12KeyStores.java line 46: > >> 44: public

Re: RFR: 8256507: Add a micro benchmark for JDK-8153005 [v2]

2020-11-19 Thread Aleksey Shipilev
On Wed, 18 Nov 2020 18:53:21 GMT, Weijun Wang wrote: >> 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 >>