Re: RFR: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion
On Thu, 10 Mar 2022 06:52:14 GMT, John Jiang wrote:
> In class sun.security.ssl.ProtocolVersion, the exception message for
> unsupported protocol needs a space.
>
> ProtocolVersion pv = ProtocolVersion.nameOf(pn);
> if (pv == null) {
> throw new IllegalArgumentException(
>"Unsupported protocol" + pn);
> }
Marked as reviewed by xuelei (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7769
RFR: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion
In class sun.security.ssl.ProtocolVersion, the exception message for
unsupported protocol needs a space.
ProtocolVersion pv = ProtocolVersion.nameOf(pn);
if (pv == null) {
throw new IllegalArgumentException(
"Unsupported protocol" + pn);
}
-
Commit messages:
- 8282932: a space is needed for the unsupported protocol exception message in
ProtocolVersion
Changes: https://git.openjdk.java.net/jdk/pull/7769/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7769&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8282932
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.java.net/jdk/pull/7769.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7769/head:pull/7769
PR: https://git.openjdk.java.net/jdk/pull/7769
Re: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v2]
> Domain value for system property jdk.https.negotiate.cbt is case-insensitive > now. Included Test has been updated to address the change. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Update HttpsCB.java - Changes: - all: https://git.openjdk.java.net/jdk/pull/7759/files - new: https://git.openjdk.java.net/jdk/pull/7759/files/6899fe36..6d276479 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7759.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7759/head:pull/7759 PR: https://git.openjdk.java.net/jdk/pull/7759
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For the bundles in java.xml: For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date. For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header. In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well. - PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v4]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to match the latest SignatureUtil.ifcFfcStrength() impl - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/099a6d92..f728aa7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 `src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties` These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging). - PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]
On Wed, 9 Mar 2022 19:44:39 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update JarSigner javadoc to make it consistent with previous update > > src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > >> 437: * Specifically, if a DSA or RSA key with a key size no less >> than 7680 >> 438: * bits, or an EC key with a key size no less than 512 bits, >> 439: * SHA-512 will be used as the hash function for the signature. > > In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). Right, there are a few places which this is documented. Code and doc aren't closely coupled together plus changed course a few times... I will fix this and double check other files. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/7652
RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
msg drop for jdk19, Mar 9, 2022 - Commit messages: - open jdk19 l10n msg drop Changes: https://git.openjdk.java.net/jdk/pull/7765/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280400 Stats: 13775 lines in 142 files changed: 12170 ins; 1249 del; 356 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary
On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have > found a problem. The problem is, that gnutls does not like use of > user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() > (used by socket.close() unless shutdownOutput was called explicitly) and > considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround > for an issue of not being able to cleanly initialize full (duplex) close of > TLS-1.3 connection (other side is not required to immediately close the after > receiving close_notify, unlike in earlier TLS versions). Some legacy programs > could probably hang or something, expecting socket.close to perform immediate > duplex close. Problem is this is not what user_canceled alert is intended for > [2] and it is therefore undefined how the other side handles this. (JDK > itself replies to close_notify preceded by user_canceled alert by immediately > closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is > already half-closed by the other side). This way it fixes my case (gnutls > client connected to jdk server initiates close) and it should be safe. (As > removing workaround altogether could probably reintroduce issues for legacy > apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] > https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 I am looking at a few things in this PR. Please ping me before integrating. I believe this code is correct, but checking on the overall USER_CANCELED strategy. - PR: https://git.openjdk.java.net/jdk/pull/7664
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]
On Wed, 9 Mar 2022 19:15:36 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Update JarSigner javadoc to make it consistent with previous update Sorry if my previous comment confused you, the code and javadoc are not consistent now. src/java.base/share/classes/sun/security/util/SignatureUtil.java line 561: > 559: return (isDSA || bitLength >= 624 ? "SHA384" : "SHA256"); > 560: } > 561: } In this method, "SHA-384" for 7680-bit key (7680 > 7680 is false). src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > 437: * Specifically, if a DSA or RSA key with a key size no less > than 7680 > 438: * bits, or an EC key with a key size no less than 512 bits, > 439: * SHA-512 will be used as the hash function for the signature. In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update JarSigner javadoc to make it consistent with previous update - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/7f6fe4b5..099a6d92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=01-02 Stats: 16 lines in 2 files changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Integrated: 8282884: Provide OID aliases for MD2, MD5, and OAEP
On Wed, 9 Mar 2022 16:04:02 GMT, Weijun Wang wrote: > Add missing OID aliases for several algorithms. This pull request has now been integrated. Changeset: 70318e1d Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/70318e1d17072198be5674ebe7118fb5f9373144 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod 8282884: Provide OID aliases for MD2, MD5, and OAEP Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/7761
Re: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v4]
On Tue, 8 Mar 2022 15:03:57 GMT, zzambers wrote: >> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was >> introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / >> Socket.shutdownOutput() and InputStream.close() / OutputStream.close() >> performed half-close of TLS-1.3 connection. However this behaviour has >> changed as result of JDK-8216326 [2]. InputStream.close() / >> OutputStream.close() no longer perform half-close but full socket close, but >> API Note was never updated. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8208526 >> [2] https://bugs.openjdk.java.net/browse/JDK-8216326 > > zzambers has updated the pull request incrementally with one additional > commit since the last revision: > > small fixes Marked as reviewed by xuelei (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7648
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2]
On Wed, 9 Mar 2022 02:02:51 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Updated to use SHA-384 as long as the keysize permits. The `JarSigner` API is not updated. - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8282884: Provide OID aliases for MD2, MD5, and OAEP
On Wed, 9 Mar 2022 16:04:02 GMT, Weijun Wang wrote: > Add missing OID aliases for several algorithms. It looks good to me. - Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7761
Integrated: 8280494: (D)TLS signature schemes
On Thu, 27 Jan 2022 22:06:21 GMT, Xue-Lei Andrew Fan wrote: > This update is to support signature schemes customization for individual > (D)TLS connection. Please review the CSR as well: > CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 > RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 > Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 This pull request has now been integrated. Changeset: 6d8d156c Author:Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/6d8d156c97b90a9ab4776c6b42563a962d959741 Stats: 521 lines in 6 files changed: 462 ins; 12 del; 47 mod 8280494: (D)TLS signature schemes Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/7252
Re: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2]
On Wed, 9 Mar 2022 08:35:45 GMT, Сергей Цыпанов wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with >> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when >> called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as >> the latter is null-hostile, however in some cases we are sure that arguments >> are non-null. Into this PR I've included the following cases (in addition to >> those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from >> `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8282662: Revert dubious changes src/java.base/share/classes/java/lang/invoke/MethodType.java line 910: > 908: if (skipPos > myLen || myLen - skipPos > fullLen) > 909: return false; > 910: List> myList = List.of(ptypes); imo should revert this one together with that proxy parameter one - PR: https://git.openjdk.java.net/jdk/pull/7729
RFR: 8282884: Provide OID aliases for MD2, MD5, and OAEP
Add missing OID aliases for several algorithms. - Commit messages: - 8282884: Provide OID aliases for MD2, MD5, and OAEP Changes: https://git.openjdk.java.net/jdk/pull/7761/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7761&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282884 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7761.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7761/head:pull/7761 PR: https://git.openjdk.java.net/jdk/pull/7761
Re: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2]
On Wed, 9 Mar 2022 09:37:30 GMT, Сергей Цыпанов wrote:
>> src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70:
>>
>>> 68: throws IOException
>>> 69: {
>>> 70: this.walker = new FileTreeWalker(List.of(options), maxDepth);
>>
>> Relates to https://bugs.openjdk.java.net/browse/JDK-8145048
>
> Should I keep it as is or revert along with the rest of dubious changes?
probably keep it. this can be updated in the patch for that bug.
-
PR: https://git.openjdk.java.net/jdk/pull/7729
RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive
Domain value for system property jdk.https.negotiate.cbt is case-insensitive now. Included Test has been updated to address the change. - Commit messages: - 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive Changes: https://git.openjdk.java.net/jdk/pull/7759/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282293 Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7759.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7759/head:pull/7759 PR: https://git.openjdk.java.net/jdk/pull/7759
Re: RFR: 8280494: (D)TLS signature schemes [v20]
On Wed, 9 Mar 2022 08:25:48 GMT, Xue-Lei Andrew Fan wrote: >> This update is to support signature schemes customization for individual >> (D)TLS connection. Please review the CSR as well: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 >> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 >> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one > additional commit since the last revision: > > correct test case issues and more Marked as reviewed by mullan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7252
Re: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2]
On Tue, 8 Mar 2022 14:27:23 GMT, liach wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8282662: Revert dubious changes
>
> src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70:
>
>> 68: throws IOException
>> 69: {
>> 70: this.walker = new FileTreeWalker(List.of(options), maxDepth);
>
> Relates to https://bugs.openjdk.java.net/browse/JDK-8145048
Should I keep it as is or revert along with the rest of dubious changes?
-
PR: https://git.openjdk.java.net/jdk/pull/7729
Re: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2]
On Tue, 8 Mar 2022 14:28:00 GMT, liach wrote: >> Сергей Цыпанов has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8282662: Revert dubious changes > > src/java.base/share/classes/sun/reflect/annotation/AnnotationSupport.java > line 79: > >> 77: >> containerBeforeContainee(annotations, annoClass); >> 78: >> 79: result.addAll((indirectFirst ? 0 : 1), List.of(indirect)); > > This `indirect` is most likely to be of size > 2 I've reverted this along with the rest of dubious changes - PR: https://git.openjdk.java.net/jdk/pull/7729
Re: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2]
> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with > smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when > called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as > the latter is null-hostile, however in some cases we are sure that arguments > are non-null. Into this PR I've included the following cases (in addition to > those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from > `Class.getInterfaces()` are never null > - exceptions types of method signature are never null Сергей Цыпанов has updated the pull request incrementally with one additional commit since the last revision: 8282662: Revert dubious changes - Changes: - all: https://git.openjdk.java.net/jdk/pull/7729/files - new: https://git.openjdk.java.net/jdk/pull/7729/files/b31edfcd..5bbe8c4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=00-01 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729
Re: RFR: 8280494: (D)TLS signature schemes [v19]
On Tue, 8 Mar 2022 16:13:08 GMT, Sean Mullan wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> add test for DTLS
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 501:
>
>> 499:
>> 500: // Note that if the System Property value is not defined
>> (JDK
>> 501: // default value) or empty, the provider-specific default
>> is used.
>
> I think you can remove this comment as it is repeated on lines 507-508 (and
> makes more sense there).
I agreed.
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 564:
>
>> 562: String[] signatureSchemes) {
>> 563:
>> 564: if (signatureSchemes == null || signatureSchemes.length == 0) {
>
> Nit: remove extra space after `||`.
Thanks for the catch!
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 576:
>
>> 574: SSLLogger.finest(
>> 575: "Ignore the signature algorithm (" + ss
>> 576: + "), unsupported or unavailable");
>
> Should this message be more consistent with the message in
> `getCustomizedSignatureScheme`?: "The current installed providers do not
> support signature scheme: " + schemeName
The usage of the method is a little bit different. This method is mainly used
for selecting a few from many signature schemes, and it is usually log with
"ignore ..." for those does not match but with high preference. See also the
caller method, getSupportedAlgorithms(), between lines 389-405.
> test/jdk/javax/net/ssl/DTLS/DTLSSignatureSchemes.java line 125:
>
>> 123: testCase.runTest(testCase);
>> 124: if (exceptionExpected) {
>> 125: throw new RuntimeException("Unexpected success!");
>
> The catch block on line 127 will end up catching this exception and
> swallowing it, and the test will incorrectly pass.
Good catch!
> test/jdk/javax/net/ssl/SSLParameters/SignatureSchemes.java line 81:
>
>> 79: super.runClientApplication(sslSocket);
>> 80: if (exceptionExpected) {
>> 81: throw new RuntimeException("Unexpected success!");
>
> The catch block on line 83 will end up catching this exception and swallowing
> it, and the test will incorrectly pass.
Good catch!
-
PR: https://git.openjdk.java.net/jdk/pull/7252
Re: RFR: 8280494: (D)TLS signature schemes [v20]
> This update is to support signature schemes customization for individual > (D)TLS connection. Please review the CSR as well: > CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 > RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 > Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: correct test case issues and more - Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/ca006ee0..f1611238 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=18-19 Stats: 21 lines in 4 files changed: 12 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252 PR: https://git.openjdk.java.net/jdk/pull/7252
