On Sun, 17 Apr 2022 14:45:49 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the simple update reviewed?
>
> In the jdk.crypto.cryptoki module implementation, some of the debug
> information could be calculated even if the debug is not enabled, which is
> not resource friendly.
>
>
On Tue, 19 Apr 2022 17:16:29 GMT, Daniel Jeliński wrote:
>> During TLS handshake, hundreds of constraints are evaluated to determine
>> which cipher suites are usable. Most of the evaluations are performed using
>> `HandshakeContext#algorithmConstraints` object. By default that object
>>
On Tue, 19 Apr 2022 17:21:20 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
>> line 94:
>>
>>> 92: * @return a SSLAlgorithmConstraints instance
>>> 93: */
>>> 94: static AlgorithmConstraints forSocket(SSLSocket socket,
>>
> https://bugs.openjdk.java.net/browse/JDK-8284688
>
> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the
> umbrella bug for this bug. The changes were too large for a single code
> review, so it was decided to split into smaller chunks. This is one such
> chunk:
>
>
On Tue, 19 Apr 2022 13:48:26 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have the simple update reviewed?
>>
>> In the jdk.crypto.cryptoki module implementation, some of the debug
>> information could be calculated even if the debug is not enabled, which is
>> not resource friendly.
>>
On Thu, 14 Apr 2022 18:06:10 GMT, Xue-Lei Andrew Fan wrote:
> This is an effort to fix a problem introduced in the fix for
> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which
> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there
> is a problem
> This trivial change is to deprecate the DEFAULT static field of
> OAEPParameterSpec class. Wordings are mostly the same as the previous
> PSSParameterSpec deprecation change. Rest are just minor code re-factoring.
>
> The CSR will be filed once review is somewhat finished.
>
> Thanks,
>
On Tue, 19 Apr 2022 19:54:24 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed the private no-arg default constructor and minor javadoc update.
>
>
On Tue, 19 Apr 2022 19:52:34 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed the private no-arg default constructor and minor javadoc update.
>
>
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majority of fixes are in
On Mon, 18 Apr 2022 23:36:56 GMT, Valerie Peng wrote:
>> This trivial change is to deprecate the DEFAULT static field of
>> OAEPParameterSpec class. Wordings are mostly the same as the previous
>> PSSParameterSpec deprecation change. Rest are just minor code re-factoring.
>>
>> The CSR will
On Tue, 19 Apr 2022 14:00:06 GMT, Xue-Lei Andrew Fan wrote:
>> This is an effort to fix a problem introduced in the fix for
>> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which
>> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However,
>> there is a
On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes
On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes
On Tue, 19 Apr 2022 14:23:07 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - add more factory methods, update copyright
>> - return DEFAULT also when user constraints are null
>
>
On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote:
> Convert dynamic proxies to hidden classes. Modifies the serialization of
> proxies (requires change in "Java Object Serialization Specification"). Makes
> the proxies hidden in stack traces. Removes duplicate logic in proxy building.
>
> The
> During TLS handshake, hundreds of constraints are evaluated to determine
> which cipher suites are usable. Most of the evaluations are performed using
> `HandshakeContext#algorithmConstraints` object. By default that object
> contains a `SSLAlgorithmConstraints` instance wrapping another
>
On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote:
> Convert dynamic proxies to hidden classes. Modifies the serialization of
> proxies (requires change in "Java Object Serialization Specification"). Makes
> the proxies hidden in stack traces. Removes duplicate logic in proxy building.
>
> The
On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes
On Tue, 19 Apr 2022 16:24:43 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majority of fixes are in comments. A handful is in strings, one in a
> local variable
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majority of fixes are in comments. A handful is in strings, one in a
> local variable
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majority of fixes are in comments. A handful is in strings, one in a
> local variable
Please review these changes to add DES/3DES/MD5 to
`jdk.security.legacyAlgorithms` security property, and to add the legacy
algorithm constraint checking to `keytool` commands that are associated with
secret key entries stored in the keystore. These `keytool` commands are
-genseckey,
> Please review this password cleanup enhancement in the PasswordCallback
> implementation. This is one of the effort to clean up the buffered passwords.
>
> The PasswordCallback.setPassword() clones the password, but is not registered
> for cleanup. An application could call clearPassword()
On Tue, 19 Apr 2022 14:35:37 GMT, Xue-Lei Andrew Fan wrote:
>> Yes, I suppose that is a good enough reason, although this class never had a
>> finalizer AFAIK. Won't there be a small performance hit (perhaps negligible)
>> for code that already calls `clearPassword`? A specification
On Mon, 18 Apr 2022 17:45:22 GMT, Sean Mullan wrote:
> I am not quite seeing the rationale for this change.
There were a lot of effort to clean up the buffering password in JDK. In some
circumstances, the PasswordCallback would be called for further using of the
password. However, because
On Mon, 18 Apr 2022 20:04:05 GMT, Sean Mullan wrote:
>> Yes, exactly. I'd recommend it calling `cleanable.clean()` prior to storing
>> the new password, so that the cleaning action for the old password is
>> explicitly and immediately unregistered.
>
> Yes, I suppose that is a good enough
On Thu, 14 Apr 2022 21:05:06 GMT, Daniel Jeliński wrote:
>> During TLS handshake, hundreds of constraints are evaluated to determine
>> which cipher suites are usable. Most of the evaluations are performed using
>> `HandshakeContext#algorithmConstraints` object. By default that object
>>
On Wed, 13 Apr 2022 06:46:51 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - add more factory methods, update copyright
>> - return DEFAULT also when user constraints are null
>
>
On Tue, 19 Apr 2022 00:14:06 GMT, Valerie Peng wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update signatures for native code
>
> src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 274:
>
>>
> This is an effort to fix a problem introduced in the fix for
> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which
> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there
> is a problem with the code changes. The Runnables registered with Cleaner
>
On Tue, 19 Apr 2022 00:12:26 GMT, Brent Christian wrote:
>> I think it is safer to add the check for 'hModule'.
>>
>>
>> -if (moduleData != NULL) {
>> +if (moduleData != NULL && moduleData->hModule != NULL) {
>
> That is very safe -- we already checked that `ckpNativeData !=
On Mon, 18 Apr 2022 21:54:22 GMT, Valerie Peng wrote:
> With this change, I see no reason to have debug(...) method. May as well just
> remove it and simply do a "System.out.println(...);"?
Yes, that's my preferred style as well. Updated.
-
PR:
> Hi,
>
> May I have the simple update reviewed?
>
> In the jdk.crypto.cryptoki module implementation, some of the debug
> information could be calculated even if the debug is not enabled, which is
> not resource friendly.
>
> Thanks,
> Xuelei
Xue-Lei Andrew Fan has updated the pull request
On Wed, 13 Apr 2022 06:46:51 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - add more factory methods, update copyright
>> - return DEFAULT also when user constraints are null
>
>
- Original Message -
> From: "liach"
> To: "core-libs-dev" , "security-dev"
>
> Sent: Tuesday, April 19, 2022 3:31:24 AM
> Subject: Re: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
> On Mon, 18 Apr 2022 20:42:48 GMT, Remi Forax wrote:
>
>> The third parameter of
37 matches
Mail list logo
