Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Xue-Lei Andrew Fan
On Wed, 12 Apr 2023 23:23:02 GMT, Weijun Wang wrote: > If the interface is only in `KEM`, then it needs a `provider()` method, but > an implementation actually does not know what the provider is. With "implementation", do you mean the javax/crypto/KEPSpi.java or src/java.base/share/classes/com

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Weijun Wang
On Wed, 12 Apr 2023 22:59:23 GMT, Xue-Lei Andrew Fan wrote: >> So you think the name is misleading? >> >> Well, at the beginning there is only the `Encapsulator` interface inside >> `KEMSpi`, and the `Encapsulator` class in `KEM` implements it with an extra >> `provider()` method. However, I t

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Xue-Lei Andrew Fan
On Wed, 12 Apr 2023 22:17:00 GMT, Weijun Wang wrote: > So you think the name is misleading? Yes. > But then if you want to talk about one you have to say which class it is in, > and this could be confusing and sometimes wrong. I did not get the idea yet to define it in KEPSpi. It looks like

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Weijun Wang
On Wed, 12 Apr 2023 21:48:27 GMT, Xue-Lei Andrew Fan wrote: >> Not exactly sure what you want. Security providers need to implement it and >> the `KEM` class uses it. Unlike other `AbcSpi` classes, it will not be >> created with a `getInstance` method. > > If I get it right, SPI means "service

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Xue-Lei Andrew Fan
On Wed, 12 Apr 2023 18:32:30 GMT, Weijun Wang wrote: >> src/java.base/share/classes/javax/crypto/KEMSpi.java line 107: >> >>> 105: * @see KEM.Encapsulator >>> 106: */ >>> 107: interface EncapsulatorSpi { >> >> Is it really necessary to define a EncapsulatorSpi? It looks like an

Integrated: 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

2023-04-12 Thread Jiangli Zhou
On Wed, 12 Apr 2023 03:20:47 GMT, Jiangli Zhou wrote: > Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This > resolves the related duplicate symbol failures when both libnio and libsctp > are statically linked with the launcher. > > Remove #include "nio_util.h" from SctpChan

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Weijun Wang
On Wed, 12 Apr 2023 14:44:10 GMT, Sean Mullan wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in >> https://github.com/openjdk/jdk/pull/13250. > > src/java.base/share/classes/javax/crypto/KEMSpi.java line 39: > >> 37: * to implement a KEM algorithm. >> 38: * >> 39:

Re: RFR: 8304845: COPYING in MUSCLE library includes incomplete license [v2]

2023-04-12 Thread Valerie Peng
> Could someone please help review this fix? Besides updating the md and > COPYING files to address the incomplete license issue, this PR also updates > the version to 1.9.9. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: typo fix

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Weijun Wang
On Wed, 12 Apr 2023 14:10:16 GMT, Xue-Lei Andrew Fan wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in >> https://github.com/openjdk/jdk/pull/13250. > > src/java.base/share/classes/javax/crypto/KEMSpi.java line 107: > >> 105: * @see KEM.Encapsulator >> 106: *

Re: RFR: 8304845: COPYING in MUSCLE library includes incomplete license

2023-04-12 Thread Valerie Peng
On Wed, 12 Apr 2023 01:32:36 GMT, Man Cao wrote: >> Could someone please help review this fix? Besides updating the md and >> COPYING files to address the incomplete license issue, this PR also updates >> the version to 1.9.9. > > src/java.smartcardio/unix/native/libj2pcsc/MUSCLE/COPYING line 2

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Weijun Wang
On Wed, 12 Apr 2023 13:22:48 GMT, Sean Mullan wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in >> https://github.com/openjdk/jdk/pull/13250. > > src/java.base/share/classes/javax/crypto/DecapsulateException.java line 30: > >> 28: >> 29: /** >> 30: * An {@link Except

Re: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

2023-04-12 Thread Jiangli Zhou
On Wed, 12 Apr 2023 03:26:10 GMT, Jiangli Zhou wrote: > I noticed there is a presubmit test failure: > https://github.com/jianglizhou/jdk/actions/runs/4672962155#user-content-java_lang_thread_virtual_tracevirtualthreadlocals > for linux-x86. It appears to be unrelated. Will file a bug tomorrow

Re: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries [v2]

2023-04-12 Thread Jiangli Zhou
On Wed, 12 Apr 2023 17:18:25 GMT, Jiangli Zhou wrote: >> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This >> resolves the related duplicate symbol failures when both libnio and libsctp >> are statically linked with the launcher. >> >> Remove #include "nio_util.h" from Sct

Re: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

2023-04-12 Thread Alan Bateman
On Wed, 12 Apr 2023 17:09:26 GMT, Jiangli Zhou wrote: > Changed loadSocketExtensionFuncs to be static as suggested. Thanks, that avoids having inconsistent naming in the header file. - PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505632040

Re: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

2023-04-12 Thread Jiangli Zhou
On Wed, 12 Apr 2023 06:29:16 GMT, Alan Bateman wrote: > This looks okay but it makes me wonder about loadSocketExtensionFuncs. Maybe > we should remove that from Sctp.h and change loadSocketExtensionFuncs in > SctpNet.c to be static. Changed loadSocketExtensionFuncs to be static as suggested.

Re: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries [v2]

2023-04-12 Thread Jiangli Zhou
> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This > resolves the related duplicate symbol failures when both libnio and libsctp > are statically linked with the launcher. > > Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like > that's only neede

Re: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries [v2]

2023-04-12 Thread Alan Bateman
On Wed, 12 Apr 2023 17:13:56 GMT, Jiangli Zhou wrote: >> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This >> resolves the related duplicate symbol failures when both libnio and libsctp >> are statically linked with the launcher. >> >> Remove #include "nio_util.h" from Sct

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Sean Mullan
On Fri, 31 Mar 2023 02:25:04 GMT, Weijun Wang wrote: > The KEM API and DHKEM impl. Note that this PR uses new methods in > https://github.com/openjdk/jdk/pull/13250. src/java.base/share/classes/javax/crypto/KEMSpi.java line 211: > 209: * The caller of this method has already validated the

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Sean Mullan
On Fri, 31 Mar 2023 02:25:04 GMT, Weijun Wang wrote: > The KEM API and DHKEM impl. Note that this PR uses new methods in > https://github.com/openjdk/jdk/pull/13250. src/java.base/share/classes/javax/crypto/KEMSpi.java line 37: > 35: * This class defines the Service Provider Interface (SPI) >

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Xue-Lei Andrew Fan
On Fri, 31 Mar 2023 02:25:04 GMT, Weijun Wang wrote: > The KEM API and DHKEM impl. Note that this PR uses new methods in > https://github.com/openjdk/jdk/pull/13250. src/java.base/share/classes/javax/crypto/KEMSpi.java line 107: > 105: * @see KEM.Encapsulator > 106: */ > 107: int

RFR: 8255548: Missing coverage for javax.xml.crypto.dom.DOMCryptoContext

2023-04-12 Thread Matthew Donovan
Implemented tests for the `DomCryptoContext.iterator()` method. - Commit messages: - 8255548: Missing coverage for javax.xml.crypto.dom.DOMCryptoContext Changes: https://git.openjdk.org/jdk/pull/13445/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13445&range=00 Issue: ht

Re: RFR: 8297878: KEM: Implementation

2023-04-12 Thread Sean Mullan
On Fri, 31 Mar 2023 02:25:04 GMT, Weijun Wang wrote: > The KEM API and DHKEM impl. Note that this PR uses new methods in > https://github.com/openjdk/jdk/pull/13250. src/java.base/share/classes/javax/crypto/DecapsulateException.java line 30: > 28: > 29: /** > 30: * An {@link Exception} child