Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]
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 the last revision:
>>
>> - Merge branch 'master' into msgdrop
>> - JDK-8259732: JDK 16 L10n resource file update - msg drop 10
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
> line 518:
>
>> 516: doclet.footer_specified=\
>> 517: The -footer option is no longer supported and will be ignored.\n\
>> 518: It may be removed in a future release.
>
> I believe this is to fix no newline at the end (unrelated to l10n changes).
> Do we need to change the copyright year for this?
Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan
Gibbons fixed it in another commit 6bb6093. I found his fix after running the
merge. Looks both of us forgot to update the copyright year. Any suggestion?
doclet.help.systemProperties.body=\
The {0} page lists references to system properties.
-
PR: https://git.openjdk.java.net/jdk16/pull/123
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]
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 from [Michael StJohns](mailto:mstjo...@comcast.net) on > [security-dev](mailto:security-dev@openjdk.java.net):_ > > 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.40 started requiring that the publicExponent be stored with the > private key to allow for the public key to be regenerated from a private > key object.?? Going forward,? it might be a good idea to modify the > RSAPrivate(Crt)KeyImpl class to store the publicExponent if provided. > > Mike You are correct that for RSA private CRT keys the necessary values are there for figuring out its corresponding public keys. This change is about adding support for PKCS#1 encoded RSA keys and be able to translate them into PKCS#8 encoded keys and/or extract various key specs out of them. If you already have PKCS#8 RSAPrivateCrtKey obj from SunRsaSign provider, you can call its getPublicExponent() method and use that to create a RSAPublicKeySpec and generate RSA public key with it. If you are using 3rd party impl which does not return the public exponent value somehow, then you can translate it using the RSA key factory impl from SunRsaSign provider and then repeat the fore-mentioned step. Will this address your need? If not, could you elaborate the usage that you have in mind? Not sure if you are suggesting a new KeyFactory.generatePublic() method which take a PrivateKey or else. - PR: https://git.openjdk.java.net/jdk/pull/1787
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]
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.40 started requiring that the publicExponent be stored with the
private key to allow for the public key to be regenerated from a private
key object. Going forward, it might be a good idea to modify the
RSAPrivate(Crt)KeyImpl class to store the publicExponent if provided.
Mike
On 1/14/2021 4:06 PM, Valerie Peng wrote:
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: throw new Exception("Encodings not equal");
158: }
159: }
Can we combine the 2 blocks above into one? That is to say, when key1 and key2
have the same format, we check the equality of both getEncoded() and
themselves. Same for the P11 test.
Sure, will do.
-
PR: https://git.openjdk.java.net/jdk/pull/1787
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v4]
> 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. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update to address review comments from Weijun - Changes: - all: https://git.openjdk.java.net/jdk/pull/1787/files - new: https://git.openjdk.java.net/jdk/pull/1787/files/b48afddd..6f498af0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1787=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1787=02-03 Stats: 26 lines in 4 files changed: 3 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1787/head:pull/1787 PR: https://git.openjdk.java.net/jdk/pull/1787
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]
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: throw new Exception("Encodings not equal");
>> 158: }
>> 159: }
>
> Can we combine the 2 blocks above into one? That is to say, when key1 and
> key2 have the same format, we check the equality of both getEncoded() and
> themselves. Same for the P11 test.
Sure, will do.
-
PR: https://git.openjdk.java.net/jdk/pull/1787
Re: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v3]
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/NoPadding cipher encrypting a byte[1] w/ an update (where more input >> could still be given) would trigger an error. The stack trace for the >> encryption update call (which is the first test, the session should be >> freshly allocated and not a reused one with active state) is below: >> >> java.security.ProviderException: update() failed >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:632) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:529) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:517) >> at java.base/javax.crypto.Cipher.update(Cipher.java:1832) >> at >> CancelMultipart$LeakByteArray.doOperation(CancelMultipart.java:125) >> at CancelMultipart$SessionLeaker.leakAndTry(CancelMultipart.java:63) >> at CancelMultipart.executeTest(CancelMultipart.java:158) >> at CancelMultipart.main(CancelMultipart.java:140) >> at PKCS11Test.premain(PKCS11Test.java:171) >> at PKCS11Test.testNSS(PKCS11Test.java:568) >> at PKCS11Test.main(PKCS11Test.java:207) >> at CancelMultipart.main(CancelMultipart.java:131) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DATA_LEN_RANGE >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native >> Method) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:584) >> ... 17 more > > The update fails because the native mechanism (CKM_AES_ECB) has no padding > and OpenJDK does not buffer data in the Java side for encryption [1] (this is > a bug that I'll address soon). As a result, there is a PKCS#11 call with an > invalid length and we get the error that ends up returning the session to the > Session Manager. I just realized that when we fix the previous padding-bug, > this test path won't work anymore. CKR_BUFFER_TOO_SMALL errors on updates do > not lead to a reset call in the OpenJDK side (contrary to doFinal), so they > wouldn't be useful for the test. I'll investigate if there is a way to > trigger the path. Otherwise we should keep the doFinal path only. I'd still > force a reset if there is an error other than CKR_BUFFER_TOO_SMALL in the > update. > > -- > [1] - > https://github.com/openjdk/jdk/blob/1cc09ccaef9a3695dd2862e3ee121e141e0a8a13/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L583 It's an update call, isn't padding occur when doFinal() is called for encryption? In any case, it's best for the test case to not have this bug dependency. I am ok if you can only test doFinal path only. - PR: https://git.openjdk.java.net/jdk/pull/1901
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]
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 {
>> 88: byte[] encodedPriv = Base64.getDecoder().decode(PKCS1_PRIV_STR);
>> 89: CUSTOM_PRIV = new PrivateKey() {
>
> How about just P1_PRIV?
Either one is fine. I can change to P1_PRIV.
-
PR: https://git.openjdk.java.net/jdk/pull/1787
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]
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:
>
>> 342: if (keySpec instanceof PKCS8EncodedKeySpec) {
>> 343: return RSAPrivateCrtKeyImpl.newKey(type, "PKCS#8",
>> 344: ((PKCS8EncodedKeySpec)keySpec).getEncoded());
>
> Will you clean up the `getEncoded()` output or shall I?
Maybe it's better that you do it this time? Just so that the backport won't
miss it.
> src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line
> 101:
>
>> 99: return new RSAPrivateKeyImpl(key.type, key.keyParams,
>> 100: key.getModulus(), key.getPrivateExponent());
>> 101: } else return key;
>
> Create a one-line block for else inside "{" and "}".
Sure.
-
PR: https://git.openjdk.java.net/jdk/pull/1787
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]
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: > >> 45: * For public keys: >> 46: * . PublicKey with an X.509 encoding >> 47: * . RSA PublicKey with an PKCS#1 encoding > > The line above has not mentioned "RSA". Maybe better to be consistent. Same > as for private key. Sure~ - PR: https://git.openjdk.java.net/jdk/pull/1787
Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]
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 request contains two additional commits since > the last revision: > > - Merge branch 'master' into msgdrop > - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518: > 516: doclet.footer_specified=\ > 517: The -footer option is no longer supported and will be ignored.\n\ > 518: It may be removed in a future release. I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this? - PR: https://git.openjdk.java.net/jdk16/pull/123
Re: RFR: 8253866: Security Libs Terminology Refresh [v2]
> 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 with supporting make > infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this > PR. Such changes will be picked up from their upstream sources. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Minor grammatical fixes - Changes: - all: https://git.openjdk.java.net/jdk/pull/2074/files - new: https://git.openjdk.java.net/jdk/pull/2074/files/9d44a9e1..45492f55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2074=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2074=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2074/head:pull/2074 PR: https://git.openjdk.java.net/jdk/pull/2074
Integrated: 8253866: Security Libs Terminology Refresh
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 follows: > > - blacklisted.certs -> blocked.certs (along with supporting make > infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this > PR. Such changes will be picked up from their upstream sources. This pull request has now been integrated. Changeset: 8554fe6e Author:Jamil Nimeh URL: https://git.openjdk.java.net/jdk/commit/8554fe6e Stats: 351 lines in 17 files changed: 152 ins; 150 del; 49 mod 8253866: Security Libs Terminology Refresh Reviewed-by: erikj, weijun, mullan - PR: https://git.openjdk.java.net/jdk/pull/2074
Re: RFR: 8253866: Security Libs Terminology Refresh [v2]
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 timeout are optional numerical parameters (default >> 1 and >> 454: #5000, which means once and 5 seconds). Please notes that if any of >> the >> 455: #values defined here is more than what is defined in krb5.conf, it >> will be > > Typo: s/is more/are more/ Done. Good catch. > src/java.base/share/conf/security/java.security line 454: > >> 452: #configuration, but with smaller max_retries and timeout values. >> 453: #max_retries and timeout are optional numerical parameters (default >> 1 and >> 454: #5000, which means once and 5 seconds). Please notes that if any of >> the > > Typo: s/notes/note/ fixed - PR: https://git.openjdk.java.net/jdk/pull/2074
Re: RFR: 8253866: Security Libs Terminology Refresh
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 follows: > > - blacklisted.certs -> blocked.certs (along with supporting make > infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this > PR. Such changes will be picked up from their upstream sources. Marked as reviewed by mullan (Reviewer). src/java.base/share/conf/security/java.security line 454: > 452: #configuration, but with smaller max_retries and timeout values. > 453: #max_retries and timeout are optional numerical parameters (default > 1 and > 454: #5000, which means once and 5 seconds). Please notes that if any of > the Typo: s/notes/note/ src/java.base/share/conf/security/java.security line 455: > 453: #max_retries and timeout are optional numerical parameters (default > 1 and > 454: #5000, which means once and 5 seconds). Please notes that if any of > the > 455: #values defined here is more than what is defined in krb5.conf, it > will be Typo: s/is more/are more/ - PR: https://git.openjdk.java.net/jdk/pull/2074
Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10
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, created by `git webrev` and converted. Pls > find this to help your review. @naotoj Would you have time to take a look at this change? Very appreciated! - PR: https://git.openjdk.java.net/jdk16/pull/123
Re: RFR: 8253866: Security Libs Terminology Refresh
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 follows: > > - blacklisted.certs -> blocked.certs (along with supporting make > infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this > PR. Such changes will be picked up from their upstream sources. Code change looks fine to me. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2074
Re: RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol… [v2]
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 has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update to use List.of() and typo changes
Changes requested by mullan (Reviewer).
src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java
line 88:
> 86: boolean ocspNonce;
> 87: }
> 88: private RevocationProperties rp;
I think this field could be `final`.
src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java
line 107:
> 105:
> 106: private void setDefaultNonce() {
> 107: byte[] nonce = null;
This variable looks like it is not used and can be removed.
src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java
line 109:
> 107: byte[] nonce = null;
> 108:
> 109: // Set the nonce by default in OCSP request extension when the
> sytem property
Typo: s/sytem/system/
src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java
line 113:
> 111: if (rp.ocspNonce) {
> 112: try {
> 113: setOcspExtensions(List.of(new
> OCSPNonceExtension(DEFAULT_NONCE_BYTES)));
I don't think we should use the `PKIXRevocationChecker.setOcspExtensions()` API
to add an OCSP Nonce extension. That API is intended to be called by
applications. I think the Nonce extension should be set by the implementation
only and not exposed via the standard API. Also, a nonce should be unique for
each OCSP request, but setting it here means that it could re-use the same
nonce for different OCSP requests.
I think a better place to create/add the OCSPExtension is in the `checkOCSP`
method, and the extension should be created each time that method is called (if
the system property is enabled), so a new nonce is created for each OCSP
request.
-
PR: https://git.openjdk.java.net/jdk/pull/2039
Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]
> 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: - Merge branch 'master' into msgdrop - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 - Changes: - all: https://git.openjdk.java.net/jdk16/pull/123/files - new: https://git.openjdk.java.net/jdk16/pull/123/files/230117b4..d72f444a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16=123=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16=123=00-01 Stats: 718 lines in 32 files changed: 616 ins; 38 del; 64 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123
Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10
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 `git webrev` and converted. Pls find this to help your review. - PR: https://git.openjdk.java.net/jdk16/pull/123
[jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10
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=123=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259732 Stats: 215 lines in 30 files changed: 118 ins; 16 del; 81 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123
Re: RFR: 8253866: Security Libs Terminology Refresh
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 follows: > > - blacklisted.certs -> blocked.certs (along with supporting make > infrastructure and tests) > - master/slave in KRB5 -> primary/replica > - blacklist in other files -> deny list > - whitelist -> allow list > > Addressing similar issues in upstream 3rd party code is out of scope of this > PR. Such changes will be picked up from their upstream sources. Build changes look good. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2074
