Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]

2021-01-14 Thread Leo Jiang
On Thu, 14 Jan 2021 17:19:11 GMT, Naoto Sato wrote: >> Leo Jiang has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains two additional commits >> since

Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]

2021-01-14 Thread Valerie Peng
On Wed, 13 Jan 2021 17:07:20 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > Marked as reviewed by weijun (Reviewer). > > > _Mailing list message fro

Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]

2021-01-14 Thread Michael StJohns
Sorry - I'm coming to this a bit late. Any chance of adding the logic for generatePublic() from a PKCS8 RSA private key?   RFC3477 has the PKCS1 RSAPrivateKey ASN1 which includes the modulus and publicExponent - so it should be a pretty straight forward add to generate a public key. PKCS11 2

Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v4]

2021-01-14 Thread Valerie Peng
> Can someone help review this? > > This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 > providers to accept RSA keys in PKCS#1 format and encoding and translate them > to provider-specific RSA keys. Updated the relevant tests with a sample > PKCS#1 encoded key pair. > > Than

Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]

2021-01-14 Thread Valerie Peng
On Wed, 13 Jan 2021 17:00:36 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > test/jdk/sun/security/rsa/TestKeyFactory.java line 159: > >> 157:

Re: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v3]

2021-01-14 Thread Valerie Peng
On Tue, 12 Jan 2021 23:20:11 GMT, Martin Balao wrote: >> I understand that the intention/design is to trigger the error condition on >> various code paths causing the active session to be returned to pool and >> verify if this issue is fixed or not. What I don't get is that why >> AES/ECB/NoPa

Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]

2021-01-14 Thread Valerie Peng
On Wed, 13 Jan 2021 17:02:50 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > test/jdk/sun/security/rsa/TestKeyFactory.java line 89: > >> 87: static

Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]

2021-01-14 Thread Valerie Peng
On Wed, 13 Jan 2021 16:23:17 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 344: >

Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]

2021-01-14 Thread Valerie Peng
On Wed, 13 Jan 2021 16:11:02 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright year from 2020 to 2021. > > src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 47: >

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]

2021-01-14 Thread Naoto Sato
On Thu, 14 Jan 2021 14:27:25 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > Leo Jiang has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull requ

Re: RFR: 8253866: Security Libs Terminology Refresh [v2]

2021-01-14 Thread Jamil Nimeh
> This is the security libs portion of the effort to replace > archaic/non-inclusive words with more neutral terms (see JDK-8253315 for > details). > > Here are the changes covering core libraries code and tests. Terms were > changed as follows: > > - blacklisted.certs -> blocked.certs (along

Integrated: 8253866: Security Libs Terminology Refresh

2021-01-14 Thread Jamil Nimeh
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace > archaic/non-inclusive words with more neutral terms (see JDK-8253315 for > details). > > Here are the changes covering core libraries code and tests. Terms were > changed as fol

Re: RFR: 8253866: Security Libs Terminology Refresh [v2]

2021-01-14 Thread Jamil Nimeh
On Thu, 14 Jan 2021 15:45:43 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Minor grammatical fixes > > src/java.base/share/conf/security/java.security line 455: > >> 453: #max_retries and tim

Re: RFR: 8253866: Security Libs Terminology Refresh

2021-01-14 Thread Sean Mullan
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace > archaic/non-inclusive words with more neutral terms (see JDK-8253315 for > details). > > Here are the changes covering core libraries code and tests. Terms were > changed as fol

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10

2021-01-14 Thread Leo Jiang
On Thu, 14 Jan 2021 14:10:12 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz) > > Since they're Unicode escape sequences in the l10n resource files, so I > attached a human readable webrev, cre

Re: RFR: 8253866: Security Libs Terminology Refresh

2021-01-14 Thread Weijun Wang
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace > archaic/non-inclusive words with more neutral terms (see JDK-8253315 for > details). > > Here are the changes covering core libraries code and tests. Terms were > changed as fol

Re: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol… [v2]

2021-01-14 Thread Sean Mullan
On Tue, 12 Jan 2021 19:18:18 GMT, Hai-May Chao wrote: >> This enhancement adds support for the nonce extension in OCSP request >> extensions by system property jdk.security.certpath.ocspNonce. >> >> Please review the CSR at: >> https://bugs.openjdk.java.net/browse/JDK-8257766 > > Hai-May Chao h

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]

2021-01-14 Thread Leo Jiang
> This is the changes for JDK 16 msg drop 10. Leo Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10

2021-01-14 Thread Leo Jiang
On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang wrote: > This is the changes for JDK 16 msg drop 10. [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz) Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `g

[jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10

2021-01-14 Thread Leo Jiang
This is the changes for JDK 16 msg drop 10. - Commit messages: - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 Changes: https://git.openjdk.java.net/jdk16/pull/123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=00 Issue: https://bugs.openjdk

Re: RFR: 8253866: Security Libs Terminology Refresh

2021-01-14 Thread Erik Joelsson
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort to replace > archaic/non-inclusive words with more neutral terms (see JDK-8253315 for > details). > > Here are the changes covering core libraries code and tests. Terms were > changed as fol