Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v43]

2024-09-18 Thread Valerie Peng
On Wed, 18 Sep 2024 21:44:08 GMT, Valerie Peng wrote: >> Kevin Driver has updated the pull request incrementally with one additional >> commit since the last revision: >> >> refinement of addIKM and addSalt specifications > > src/java.base/share/classes/com/sun/crypto/provider/HKDFKeyDerivati

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v43]

2024-09-18 Thread Valerie Peng
On Tue, 17 Sep 2024 21:52:47 GMT, Kevin Driver wrote: >> Introduce an API for Key Derivation Functions (KDFs), which are >> cryptographic algorithms for deriving additional keys from a secret key and >> other data. See [JEP 478](https://openjdk.org/jeps/478). >> >> Work was begun in [another P

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v43]

2024-09-18 Thread Valerie Peng
On Tue, 17 Sep 2024 21:52:47 GMT, Kevin Driver wrote: >> Introduce an API for Key Derivation Functions (KDFs), which are >> cryptographic algorithms for deriving additional keys from a secret key and >> other data. See [JEP 478](https://openjdk.org/jeps/478). >> >> Work was begun in [another P

Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server [v2]

2024-09-18 Thread Artur Barashev
On Wed, 18 Sep 2024 11:40:27 GMT, Daniel Jeliński wrote: >> Artur Barashev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> - Rather than proactively scanning every packet for this unlikely >> scenario, we reactively check for unencrypte

Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server [v2]

2024-09-18 Thread Artur Barashev
> https://bugs.openjdk.org/browse/JDK-8331682 Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: - Rather than proactively scanning every packet for this unlikely scenario, we reactively check for unencrypted alert after getting the B

Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server

2024-09-18 Thread Artur Barashev
On Wed, 18 Sep 2024 11:40:27 GMT, Daniel Jeliński wrote: > Should the client send a close_notify if the connection is closed in the > middle of the handshake? I couldn't find a good answer in the TLS1.3 spec, > but I'd assume that closing the connection without sending a close_notify > would b

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]

2024-09-18 Thread Lance Andersen
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the >> corelibs specification. Applet has been deprecated since JDK9, and may be a >> confusing term for new Java developers, so it should be removed from the >> documentati

Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server

2024-09-18 Thread Artur Barashev
On Wed, 18 Sep 2024 11:30:46 GMT, Daniel Jeliński wrote: >> https://bugs.openjdk.org/browse/JDK-8331682 > > src/java.base/share/classes/sun/security/ssl/SSLTransport.java line 112: > >> 110: >> 111: // Check for unexpected plaintext alert message during TLSv1.3 >> handshake, @bug 83316

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]

2024-09-18 Thread Roger Riggs
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the >> corelibs specification. Applet has been deprecated since JDK9, and may be a >> confusing term for new Java developers, so it should be removed from the >> documentati

Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server

2024-09-18 Thread Artur Barashev
On Wed, 18 Sep 2024 13:59:59 GMT, Artur Barashev wrote: >> test/jdk/javax/net/ssl/TLSv13/SSLEngineNoServerHelloClientShutdown.java line >> 204: >> >>> 202: // Server unwrap should process an unencrypted 2 byte packet, >>> 203: log("---Server Unwrap user_cancelled alert---"); >>>

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]

2024-09-18 Thread Iris Clark
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the >> corelibs specification. Applet has been deprecated since JDK9, and may be a >> confusing term for new Java developers, so it should be removed from the >> documentati

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]

2024-09-18 Thread Naoto Sato
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the >> corelibs specification. Applet has been deprecated since JDK9, and may be a >> confusing term for new Java developers, so it should be removed from the >> documentati

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]

2024-09-18 Thread Sean Coffey
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the >> corelibs specification. Applet has been deprecated since JDK9, and may be a >> confusing term for new Java developers, so it should be removed from the >> documentati

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]

2024-09-18 Thread Justin Lu
> Please review this PR which removes occurrences of 'applet' within the > corelibs specification. Applet has been deprecated since JDK9, and may be a > confusing term for new Java developers, so it should be removed from the > documentation. > > Primarily, usages where 'applet' is used interch

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]

2024-09-18 Thread Justin Lu
On Wed, 18 Sep 2024 06:52:17 GMT, Alan Bateman wrote: >> `repaint()` could be substituted with another arbitrary method name to >> highlight some work this thread has to perform. >> >> given the thread name `blink`, perhaps we could just use `blink()` in this >> example. > > Don't waste too mu

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2]

2024-09-18 Thread Justin Lu
On Wed, 18 Sep 2024 06:53:27 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reflect review comments > > src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39: > >> 37: * im

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v40]

2024-09-18 Thread Valerie Peng
On Wed, 18 Sep 2024 17:07:22 GMT, Valerie Peng wrote: >> Not me. > > This is the by-product of the `getNext()` refactoring. I should have modeled > `getNext()` using the code under `getInstance()` instead of > `chooseProvider()` so the debugging and exception can be preserved. Shared > the pro

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v40]

2024-09-18 Thread Valerie Peng
On Wed, 18 Sep 2024 14:31:06 GMT, Weijun Wang wrote: >> src/java.base/share/classes/javax/crypto/KDF.java line 331: >> >>> 329: * if at least one {@code Provider} supports a {@code KDF} >>> 330: * implementation for the specified algorithm but none of >>> them >>> 331:

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v43]

2024-09-18 Thread Valerie Peng
On Tue, 17 Sep 2024 21:52:47 GMT, Kevin Driver wrote: >> Introduce an API for Key Derivation Functions (KDFs), which are >> cryptographic algorithms for deriving additional keys from a secret key and >> other data. See [JEP 478](https://openjdk.org/jeps/478). >> >> Work was begun in [another P

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v43]

2024-09-18 Thread Weijun Wang
On Tue, 17 Sep 2024 21:52:47 GMT, Kevin Driver wrote: >> Introduce an API for Key Derivation Functions (KDFs), which are >> cryptographic algorithms for deriving additional keys from a secret key and >> other data. See [JEP 478](https://openjdk.org/jeps/478). >> >> Work was begun in [another P

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v40]

2024-09-18 Thread Weijun Wang
On Wed, 18 Sep 2024 13:32:06 GMT, Sean Mullan wrote: >> Kevin Driver has updated the pull request incrementally with one additional >> commit since the last revision: >> >> IDE formatting broke snippet > > src/java.base/share/classes/javax/crypto/KDF.java line 331: > >> 329: * i

Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server

2024-09-18 Thread Artur Barashev
On Wed, 18 Sep 2024 11:32:01 GMT, Daniel Jeliński wrote: >> https://bugs.openjdk.org/browse/JDK-8331682 > > test/jdk/javax/net/ssl/TLSv13/SSLEngineNoServerHelloClientShutdown.java line > 204: > >> 202: // Server unwrap should process an unencrypted 2 byte packet, >> 203: log("--

Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v40]

2024-09-18 Thread Sean Mullan
On Mon, 16 Sep 2024 19:21:13 GMT, Kevin Driver wrote: >> Introduce an API for Key Derivation Functions (KDFs), which are >> cryptographic algorithms for deriving additional keys from a secret key and >> other data. See [JEP 478](https://openjdk.org/jeps/478). >> >> Work was begun in [another P

Re: RFR: 8339735: Remove references to Applet in core-libs/security APIs

2024-09-18 Thread Sean Mullan
On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote: > Please review this PR which removes occurrences of 'applet' within the > corelibs specification. Applet has been deprecated since JDK9, and may be a > confusing term for new Java developers, so it should be removed from the > documentation.

Re: RFR: 8331391: Enhance the keytool code by invoking the buildTrustedCerts method for essential options

2024-09-18 Thread Sean Coffey
On Wed, 18 Sep 2024 12:19:18 GMT, Prasadrao Koppula wrote: > Updated the code to call buildTrustedCerts only when the -trustcacerts option > is specified looks reasonable to me - Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21058#pullrequ

RFR: 8331391: Enhance the keytool code by invoking the buildTrustedCerts method for essential options

2024-09-18 Thread Prasadrao Koppula
Updated the code to call buildTrustedCerts only when the -trustcacerts option is specified - Commit messages: - JDK-8331391 Changes: https://git.openjdk.org/jdk/pull/21058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21058&range=00 Issue: https://bugs.openjdk.org/brow

Re: RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server

2024-09-18 Thread Daniel Jeliński
On Tue, 17 Sep 2024 17:44:37 GMT, Artur Barashev wrote: > https://bugs.openjdk.org/browse/JDK-8331682 Should the client send a close_notify if the connection is closed in the middle of the handshake? I couldn't find a good answer in the TLS1.3 spec, but I'd assume that closing the connection w