Re: Update to JEP draft: Key Encapsulation Mechanism API

2023-02-04 Thread Xuelei Fan
On Sat, Feb 4, 2023 at 2:33 PM Wei-Jun Wang wrote: > Hi Xuelei, > > This is a very interesting case since both crypto primitives (KEM and > Cipher) require delayed provider selection. > > I would say line 4 should not throw an exception. A KEM should not reject > any algorithm name, because it mi

Re: Update to JEP draft: Key Encapsulation Mechanism API

2023-02-04 Thread Wei-Jun Wang
Hi Xuelei, This is a very interesting case since both crypto primitives (KEM and Cipher) require delayed provider selection. I would say line 4 should not throw an exception. A KEM should not reject any algorithm name, because it might be any string. It's very likely that the shared secret is

Re: RFR: 8301443: Clean broken comments from Windows code [v2]

2023-02-04 Thread Alexey Ivanov
On Sat, 4 Feb 2023 13:36:54 GMT, Weijun Wang wrote: >> I did think about that too when I first saw it, but the command this is >> often run from is the Windows CMD, which does not accept `` to escape to the >> next line. MSYS bash does not have the required environment set up outside >> of con

Re: Update to JEP draft: Key Encapsulation Mechanism API

2023-02-04 Thread Xuelei Fan
Hi, Thank you for the update. What’s the different impact of parameters like algorithm name, KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I’m not very sure of it. For example, at 2013, the following cord should work without any issues: 1. var kemS = KEM.getInstance("

Re: RFR: 8301443: Clean broken comments from Windows code [v2]

2023-02-04 Thread Weijun Wang
On Sat, 4 Feb 2023 07:42:37 GMT, Julian Waters wrote: >> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 31: >> >>> 29: // This library can be built directly with the following command: >>> 30: // cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ >>> sspi.cpp >>

Re: RFR: 8301760: Fix possible leak in SpNegoContext dispose

2023-02-04 Thread Weijun Wang
On Fri, 3 Feb 2023 14:12:42 GMT, Yuri Nesterenko wrote: > This small change should fix a possible under certain circumstances native > memory leak. In fact, the actual leak was reported in production. Marked as reviewed by weijun (Reviewer). - PR: https://git.openjdk.org/jdk/pull/