From darcy at openjdk.java.net  Tue Feb  1 06:10:15 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 1 Feb 2022 06:10:15 GMT
Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
 [v13]
In-Reply-To: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
 <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com>
Message-ID: <WtoPNaRlMH7RXQMqSKPRTpOPWxkW3SzJt7ZP74nQ7_g=.961ab978-93bc-49a9-92fa-70f6e9bd89dc@github.com>

On Fri, 28 Jan 2022 16:58:55 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
>> 
>> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
>> 
>> A test will be added separately to the implementation.
>> 
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spec update from CSR

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7065

From xuelei at openjdk.java.net  Tue Feb  1 06:47:00 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 1 Feb 2022 06:47:00 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v8]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <sG6K-OdLargm-F0NU2y6T0p5ZZ1DOJh-AHR7OwwGLas=.77b93b0d-4246-4486-ad0c-c548b89df837@github.com>

> 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

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  Allow null input and return values

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/dfcb7f7d..b5161f75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=06-07

  Stats: 62 lines in 1 file changed: 13 ins; 16 del; 33 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

From xuelei at openjdk.java.net  Tue Feb  1 06:47:00 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 1 Feb 2022 06:47:00 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <TRp4gf1XxdtDmwWZJ41H_oZc6Wt8K_KU5U1VRFFXkZI=.80fc1318-d2f6-436b-aa68-88d54b164b63@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
 <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
 <Xuzs8p6keG9rol3ad_Eh6JQcZV5Hu5yV9u70xJ8HD4o=.aaf3d417-54f2-45df-804c-ca1418e0a109@github.com>
 <TRp4gf1XxdtDmwWZJ41H_oZc6Wt8K_KU5U1VRFFXkZI=.80fc1318-d2f6-436b-aa68-88d54b164b63@github.com>
Message-ID: <1GU_LQE4xPb-k02FTR5Hh-gqBhZTydgJsZf-7SwqY9M=.f972b0ea-0e93-4908-b890-7d57c26929d1@github.com>

On Mon, 31 Jan 2022 21:26:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> As there is increasing number of SSL parameters, applications may just use the constructor with no argument, and use the set methods individually.
>
> Ok. You should specify what the default value of the signature schemes parameter is for this constructor as it does for the other parameters.

Good catch.  Updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Tue Feb  1 06:58:12 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 1 Feb 2022 06:58:12 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v7]
In-Reply-To: <PjhIBZfJetbTaC9Fw2czpxVv6jr6kHxJphsLGUSWio0=.f7bcd1a0-dff4-447e-92e9-d7d663e1d71c@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <DcOEfb1M7AcRaOEWlri_5APSAtNrddKcprzwGQSJPTk=.693c6fc2-3ca4-4f48-9222-bea370854996@github.com>
 <PjhIBZfJetbTaC9Fw2czpxVv6jr6kHxJphsLGUSWio0=.f7bcd1a0-dff4-447e-92e9-d7d663e1d71c@github.com>
Message-ID: <-hZDJJn4jgc8PaH6tf8Bw1oCWbF8UaoFg5oqehCOBXo=.a5dc5158-de3d-4af2-9f90-35c02cd61ff2@github.com>

On Mon, 31 Jan 2022 21:55:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rollback to use captialized S
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 727:
> 
>> 725:      * Note that the underlying provider may define the default signature
>> 726:      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>> 727:      * System Property, "jdk.tls.client.SignatureSchemes" and/or
> 
> Use the javadoc annotation @systemProperty when referring to the system properties. Look at other code for examples.

Thanks! Updated.

> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 734:
> 
>> 732:      * pre-populated objects.
>> 733:      *
>> 734:      * @return a non-null, possibly zero-length array of signature scheme
> 
> The other methods that return arrays like `getCipherSuites` and `getProtocols` return `null` if none have been set. While one could argue whether returning `null` or an empty array is better, there is already a precedent in this API of returning `null`, and with this API programmers will have to check for two different ways of checking for parameters that are not set. I'm not really sure if the inconsistency is worth it.

Yes, it is arguable. The spec is updated, I will update the implementation if we are on the same page for the specification part.

> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 765:
> 
>> 763:      * System Property, "jdk.tls.client.SignatureSchemes" and/or
>> 764:      * "jdk.tls.server.SignatureSchemes", to customize the provider-specific
>> 765:      * default signature schemes. If the {@code signatureSchemes} array is
> 
> In this sentence does `signatureSchemes` mean the "*.SignatureSchemes" property or the `signatureSchemes` parameter? I don't think I understand this sentence. I think you should explain when the system property overrides the parameter in this API, and/or vice-versa.

I removed this section in the setSignatureSchemes() method, and add more details in the getSignatureSchemes().

> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 774:
> 
>> 772:      *        is empty (zero-length), the provider-specific default signature
>> 773:      *        schemes will be used for the SSL/TLS/DTLS connection.
>> 774:      * @throws IllegalArgumentException if signatureSchemes is null, or if
> 
> The other methods that accept arrays like `setCipherSuites` and `setProtocols` accept `null` as a parameter. Like my previous comment, it seems more important to keep this behavior consistent in the API and allow `null` as an acceptable value, which is also useful for clearing the current value of the parameter.

Updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From michaelm at openjdk.java.net  Tue Feb  1 07:30:19 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 1 Feb 2022 07:30:19 GMT
Subject: Integrated: 8279842: HTTPS Channel Binding support for Java
 GSS/Kerberos
In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com>
Message-ID: <wPCmXK1Eo3M2z4eegZS5ioujoPI5sfOx1ihDQX9Aga0=.d31b8d72-e8ac-4301-b655-1f9085e4ab79@github.com>

On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows:
> 
> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains.
> 
> A test will be added separately to the implementation.
> 
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: de3113b9
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de3113b998550021bb502cd6f766036fb8351e7d
Stats:     858 lines in 12 files changed: 696 ins; 146 del; 16 mod

8279842: HTTPS Channel Binding support for Java GSS/Kerberos

Co-authored-by: Weijun Wang <weijun.wang at oracle.com>
Reviewed-by: dfuchs, weijun, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/7065

From bulasevich at openjdk.java.net  Tue Feb  1 08:44:58 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Tue, 1 Feb 2022 08:44:58 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code [v2]
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <Y4H1g8OHuUus4DtDJ_y3RvIXL7b92SJmV-D9mt757Tk=.347ead87-f239-4e36-a49c-cab4575721a5@github.com>

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

Boris Ulasevich 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 one additional commit since the last revision:

  Apply manual inline and unroll, plus moving data into local variables to help C2 with SHA3 impl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6847/files
  - new: https://git.openjdk.java.net/jdk/pull/6847/files/dd889460..4d15fea4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6847&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6847&range=00-01

  Stats: 46135 lines in 1581 files changed: 29727 ins; 9682 del; 6726 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6847.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6847/head:pull/6847

PR: https://git.openjdk.java.net/jdk/pull/6847

From bulasevich at openjdk.java.net  Tue Feb  1 09:52:46 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Tue, 1 Feb 2022 09:52:46 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code [v3]
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <cp6_KXQm0cAh0c__rY28rFIrqYqmLIp-togh1lqvqyo=.83c2a8fb-e69a-467d-885a-e66ad9988f01@github.com>

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:

  copyright fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6847/files
  - new: https://git.openjdk.java.net/jdk/pull/6847/files/4d15fea4..de07332b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6847&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6847&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6847.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6847/head:pull/6847

PR: https://git.openjdk.java.net/jdk/pull/6847

From ascarpino at openjdk.java.net  Tue Feb  1 17:09:10 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 1 Feb 2022 17:09:10 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code [v3]
In-Reply-To: <cp6_KXQm0cAh0c__rY28rFIrqYqmLIp-togh1lqvqyo=.83c2a8fb-e69a-467d-885a-e66ad9988f01@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
 <cp6_KXQm0cAh0c__rY28rFIrqYqmLIp-togh1lqvqyo=.83c2a8fb-e69a-467d-885a-e66ad9988f01@github.com>
Message-ID: <G3BKL5VtrQP1_G4Fnt1mli9Sbyso-n9Ad_Pzs1vXPXI=.125c2aa2-2b18-4f25-ae6f-e4595fcb2f87@github.com>

On Tue, 1 Feb 2022 09:52:46 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Background
>> 
>> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
>> 
>> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
>> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
>> 
>> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
>> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
>> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
>> 
>> Option 1 (this PR)
>> 
>> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
>> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
>> 
>> Option 2 (alternative)
>> 
>> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
>> 
>> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
>> 
>> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
>> 
>> Benchmark results
>> 
>> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
>> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
>> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
>> 
>> Testing
>> 
>> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
>> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
>> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
>> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
>> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
>> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
>> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright fix

Looks good to me

-------------

Marked as reviewed by ascarpino (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6847

From phh at openjdk.java.net  Tue Feb  1 17:13:10 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Tue, 1 Feb 2022 17:13:10 GMT
Subject: RFR: 8275914: SHA3: changing java implementation to help C2 create
 high-performance code [v3]
In-Reply-To: <cp6_KXQm0cAh0c__rY28rFIrqYqmLIp-togh1lqvqyo=.83c2a8fb-e69a-467d-885a-e66ad9988f01@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
 <cp6_KXQm0cAh0c__rY28rFIrqYqmLIp-togh1lqvqyo=.83c2a8fb-e69a-467d-885a-e66ad9988f01@github.com>
Message-ID: <BXDV6ytQ8vBYbZ-qKUW8U-KktlnfnQeodpyBHG4VIbQ=.ad915fcd-4fdc-492f-81c8-d0b0c50f150b@github.com>

On Tue, 1 Feb 2022 09:52:46 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Background
>> 
>> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
>> 
>> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
>> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
>> 
>> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
>> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
>> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
>> 
>> Option 1 (this PR)
>> 
>> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
>> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
>> 
>> Option 2 (alternative)
>> 
>> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
>> 
>> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
>> 
>> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
>> 
>> Benchmark results
>> 
>> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
>> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
>> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
>> 
>> Testing
>> 
>> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
>> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
>> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
>> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
>> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
>> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
>> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright fix

Lgtm as well.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6847

From bulasevich at openjdk.java.net  Tue Feb  1 21:00:12 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Tue, 1 Feb 2022 21:00:12 GMT
Subject: Integrated: 8275914: SHA3: changing java implementation to help C2
 create high-performance code
In-Reply-To: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
References: <-GdKYnL17OXkOLuGXufGFWJWhGqaVJVrVmebnSvihbc=.e1520a9a-a4f4-4c11-ba11-1ca07f50aa64@github.com>
Message-ID: <fZ9V2Iwx7t_o5bOgjZxHd8Ad4vGWyk5piPB70C2cZDg=.e4137337-0bdd-4689-8170-1f7d5b434f4c@github.com>

On Wed, 15 Dec 2021 09:20:38 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Background
> 
> The goal is to improve SHA3 implementation performance as it runs up to two times slower than native (OpenSSL, measured on AMD64 and AArch6464) implementation. Some hardware provides SHA3 accelerators, but most (AMD64 and most AArch64) do not.
> 
> For AArch64 hardware that does support SHA3 accelerators, an intrinsic was implemented for ARMv8.2 with SHA3 instructions support:
> - [JDK-8252204](https://bugs.openjdk.java.net/browse/JDK-8252204): AArch64: Implement SHA3 accelerator/intrinsic
> 
> SHA3 java implementation have already been reworked to eliminate memory consumption and make it work faster:
> - [JDK-8157495](https://bugs.openjdk.java.net/browse/JDK-8157495): SHA-3 Hash algorithm performance improvements (~12x speedup)
> The latter issue addressed this previously, but there is still some room to improve SHA3 performance with current C2 implementation, which is proposed in this PR.
> 
> Option 1 (this PR)
> 
> With this change I unroll the internal cycles manually, inline it manually, and use local variables (not array) for data processing. Such an approach gives the best performance (see benchmark results). Without this change (with current array data processing) we observe a lot of load/store operations in comparison to processing in local variables, both on AMD64 and on AArch64.  
> Native implementations shows that on AArch64 (32 GPU registers) SHA-3 algorithm can hold all 25 data and all temporary variables in registers. C2 can't optimize it as well because many regisers are allocated for internal usage: rscratch1, rscratch2, rmethod, rthread, etc.  With data in local variables the number of excessive load/stores is much smaller and performance result is much better.
> 
> Option 2 (alternative)
> 
> LINK: [the change](https://github.com/bulasevich/jdk/commit/095fc9db)
> 
> This is a more conservative change which minimizes code changes, but it has lower performance improvement. Please let me know if you think this change is better then main one: in this case I will replace it within this Pull Request.
> 
> With this change I unroll the internal cycles manually and use @Forceinline annotation. Manual unrolling is necessary because C2 does not recognize there is a counted cycle that can be completely unrolled. Instead of replacing the loop with five loop bodies C2 splits the loop to pre- main- and post- loop which is not good for this case. C2 works better when the array is created locally, but in our case the array is created on object instantiation, so C2 can't prove the array length is constant. The second issue affecting performance is that methods with unrolled loops get larger and C2 does not inline them. It's addressed here by using @Forceinline annotation.
> 
> Benchmark results
> 
> We measured the change on four platforms: ARM32, PPC, AArch64 (with no advanced SHA-3 instructions) and AMD on
>   [MessageDigests](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/security/MessageDigests.java) benchmark. Here is the result: http://cr.openjdk.java.net/~bulasevich/8275914/sha3_bench.html
> - fix1 (red) is the Option 1 (this PR) change: gains 50/38/83/38% on ARM32/PPC/AArch64/AMD64
> - fix2 (green) is the Option 2 (alternative) change: gains 23/33/40/17% on ARM32/PPC/AArch64/AMD64
> 
> Testing
> 
> Tested with JTREG and SHA-3 Project (NIST) test vectors: run SHA3 implementation over the same vectors before and after the change, and checking the results are the same.
> The test tool: http://cr.openjdk.java.net/~bulasevich/8275914/RunKat.java
> The test vectors compiled from the [Final Algorithm Package](https://csrc.nist.gov/Projects/Hash-Functions/SHA-3-Project):
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_224.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_256.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_384.txt
> http://cr.openjdk.java.net/~bulasevich/8275914/MsgKAT_512.txt

This pull request has now been integrated.

Changeset: c74b8f48
Author:    Boris Ulasevich <bulasevich at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c74b8f48fad8380dbd811e4a42c361006e13021d
Stats:     209 lines in 1 file changed: 114 ins; 93 del; 2 mod

8275914: SHA3: changing java implementation to help C2 create high-performance code

Reviewed-by: ascarpino, phh

-------------

PR: https://git.openjdk.java.net/jdk/pull/6847

From darcy at openjdk.java.net  Tue Feb  1 21:18:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 1 Feb 2022 21:18:42 GMT
Subject: RFR: JDK-8281082: Improve javadoc references to JOSS
Message-ID: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>

The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved.

I'll update copyright years before pushing.

-------------

Commit messages:
 - JDK-8281082: Improve javadoc references to JOSS

Changes: https://git.openjdk.java.net/jdk/pull/7315/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7315&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281082
  Stats: 11 lines in 6 files changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7315.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7315/head:pull/7315

PR: https://git.openjdk.java.net/jdk/pull/7315

From iris at openjdk.java.net  Tue Feb  1 21:30:08 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 1 Feb 2022 21:30:08 GMT
Subject: RFR: JDK-8281082: Improve javadoc references to JOSS
In-Reply-To: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
References: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
Message-ID: <0A1mLhnXMU55jCHgniAz9Ap7i3f94mQsUtxARd7bEcY=.a8cf6306-236e-48b5-8aa2-b8cbc284f71c@github.com>

On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved.
> 
> I'll update copyright years before pushing.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7315

From rriggs at openjdk.java.net  Tue Feb  1 21:35:07 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 1 Feb 2022 21:35:07 GMT
Subject: RFR: JDK-8281082: Improve javadoc references to JOSS
In-Reply-To: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
References: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
Message-ID: <Rqo1yTVdEG7jivj8G1hY87wPrtfkKfQIwQO7wwx9ASQ=.589ec961-a662-40a0-a06a-a397afd2ab30@github.com>

On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved.
> 
> I'll update copyright years before pushing.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7315

From naoto at openjdk.java.net  Tue Feb  1 21:48:11 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 1 Feb 2022 21:48:11 GMT
Subject: RFR: JDK-8281082: Improve javadoc references to JOSS
In-Reply-To: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
References: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
Message-ID: <9KMYQNCC0C_K7XN-QTMUMA1QoE7vMznJdd9j6lmeSco=.79472129-a1b5-4a1e-a736-82c18e0cc527@github.com>

On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved.
> 
> I'll update copyright years before pushing.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7315

From mullan at openjdk.java.net  Tue Feb  1 22:06:37 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 1 Feb 2022 22:06:37 GMT
Subject: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class
 loader in signed JAR
Message-ID: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>

This fixes a bootstrapping issue if a custom system class loader is set with the `-Djava.system.class.loader` option and the custom class loader is inside a signed JAR.  In order to load the custom class loader, the runtime must verify the signed JAR first, and the algorithm constraint code tries to load a `Locale` provider using a `ServiceLoader` before the class loader is set, and this causes a `ServiceConfigurationError`.

The fix removes a dependency from the security algorithm "denyAfter" constraint parsing code on the `Calendar` API which uses a `ServiceLoader` for gathering default locale information. Instead the `ZonedDateTime` API is now used, which simplifies the code and removes some unnecessary code from `keytool` as well.

-------------

Commit messages:
 - Remove trailing whitespace.
 - Initial fix for JDK-8280890.

Changes: https://git.openjdk.java.net/jdk/pull/7316/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7316&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280890
  Stats: 183 lines in 4 files changed: 139 ins; 28 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7316.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7316/head:pull/7316

PR: https://git.openjdk.java.net/jdk/pull/7316

From lancea at openjdk.java.net  Tue Feb  1 22:25:06 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 1 Feb 2022 22:25:06 GMT
Subject: RFR: JDK-8281082: Improve javadoc references to JOSS
In-Reply-To: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
References: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
Message-ID: <-pJCfTKW1eOsAryuQlNdvp7XHYs9N-0ohk2qCV0L7y0=.5bba56c9-e38b-4f89-b24c-84acf723941d@github.com>

On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved.
> 
> I'll update copyright years before pushing.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7315

From darcy at openjdk.java.net  Tue Feb  1 22:33:46 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 1 Feb 2022 22:33:46 GMT
Subject: RFR: JDK-8281082: Improve javadoc references to JOSS [v2]
In-Reply-To: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
References: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
Message-ID: <kR7KXHA1Rsh0bxYRsymyhiVgHMJx02jUQoZKl_-9yVo=.fdcad9b4-621d-44d3-a4ca-603aba32289a@github.com>

> The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved.
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyrights.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7315/files
  - new: https://git.openjdk.java.net/jdk/pull/7315/files/3eb97175..a4e1eb79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7315&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7315&range=00-01

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7315.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7315/head:pull/7315

PR: https://git.openjdk.java.net/jdk/pull/7315

From darcy at openjdk.java.net  Tue Feb  1 22:33:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 1 Feb 2022 22:33:47 GMT
Subject: Integrated: JDK-8281082: Improve javadoc references to JOSS
In-Reply-To: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
References: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
Message-ID: <52u-IKK3Awj6GaFWKhxtKcxbdjigBhKm22BFWPUA2H0=.f82d7961-271e-4f5d-b9e2-4a4649b30a2d@github.com>

On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved.
> 
> I'll update copyright years before pushing.

This pull request has now been integrated.

Changeset: 9ca7ff3e
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9ca7ff3e4f0a944bacf38da7e5426082d64c52bd
Stats:     16 lines in 6 files changed: 3 ins; 0 del; 13 mod

8281082: Improve javadoc references to JOSS

Reviewed-by: iris, rriggs, naoto, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/7315

From alanb at openjdk.java.net  Wed Feb  2 06:43:11 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 2 Feb 2022 06:43:11 GMT
Subject: RFR: JDK-8281082: Improve javadoc references to JOSS [v2]
In-Reply-To: <kR7KXHA1Rsh0bxYRsymyhiVgHMJx02jUQoZKl_-9yVo=.fdcad9b4-621d-44d3-a4ca-603aba32289a@github.com>
References: <ncCKJXDIzg-fQxi8qyExyBYezk8NzjGLuMh1BVsGDOI=.9615c9f8-324a-45ff-a28b-c3ca3d2d0d66@github.com>
 <kR7KXHA1Rsh0bxYRsymyhiVgHMJx02jUQoZKl_-9yVo=.fdcad9b4-621d-44d3-a4ca-603aba32289a@github.com>
Message-ID: <drNiEUyidEH67ZgYw9boPqM9ckssdFm-p1iuonbERJw=.0590a62f-3613-4fc9-a91a-4e734fd81f04@github.com>

On Tue, 1 Feb 2022 22:33:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved.
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrights.

src/java.base/share/classes/java/io/ObjectOutputStream.java line 659:

> 657:      * customize the way in which class descriptors are written to the
> 658:      * serialization stream.  The corresponding method in ObjectInputStream,
> 659:      * {@link ObjectInputStream#readClassDescriptor readClassDescriptor}, should then be overridden to

This makes the line lengths in this paragraph a bit inconsistent, maybe it can be re-formatted so that this one line doesn't stick out so much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7315

From mullan at openjdk.java.net  Wed Feb  2 14:48:18 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 2 Feb 2022 14:48:18 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v8]
In-Reply-To: <sG6K-OdLargm-F0NU2y6T0p5ZZ1DOJh-AHR7OwwGLas=.77b93b0d-4246-4486-ad0c-c548b89df837@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <sG6K-OdLargm-F0NU2y6T0p5ZZ1DOJh-AHR7OwwGLas=.77b93b0d-4246-4486-ad0c-c548b89df837@github.com>
Message-ID: <ywNT7xJLx6IFkUdeGwJIyApN5nm3D1F7MFPaSm9ooUA=.83c17630-167f-4222-9d0c-a52a25ede896@github.com>

On Tue, 1 Feb 2022 06:47:00 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow null input and return values

A few more comments on the API.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 706:

> 704:      * over the SSL/TLS/DTLS protocols.
> 705:      * <p>
> 706:      * Note that the standard list of signature scheme names may be found in

s/may be found/are defined/

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710:

> 708:      * "{@docRoot}/../specs/security/standard-names.html#signature-schemes">
> 709:      * Signature Schemes</a> section of the Java Security Standard Algorithm
> 710:      * Names Specification. Providers may support signature schemes not found

s/found/defined/

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 711:

> 709:      * Signature Schemes</a> section of the Java Security Standard Algorithm
> 710:      * Names Specification. Providers may support signature schemes not found
> 711:      * in this list or might not use the recommended name for a certain

s/might/may/

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 714:

> 712:      * signature scheme.
> 713:      * <p>
> 714:      * The returned array could be {@code null}, in which case the underlying

s/could be/may be/

Suggest rewording as "If the returned array is {@code null}, then the underlying ..."

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 718:

> 716:      * SSL/TLS/DTLS connections.
> 717:      * <p>
> 718:      * The returned array could be empty (zero-length), in which case the

Suggest rewording as "If the returned array is empty (zero-length), then the ..."

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 720:

> 718:      * The returned array could be empty (zero-length), in which case the
> 719:      * signature scheme negotiation mechanism is turned off for SSL/TLS/DTLS
> 720:      * protocols, and the connections may not be able estabilished if the

s/estabilished/to be established/

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 723:

> 721:      * negotiation mechanism is required by a certain SSL/TLS/DTLS protocol.
> 722:      * <p>
> 723:      * The returned array could be neither {@code null} nor empty (zero-length),

Suggest rewording as "If the returned array is not {@code null} or empty (zero-length), then the signature schemes .."

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 730:

> 728:      * For non-null returns, this method will return a new array each time it
> 729:      * is invoked. Providers should ignore unknown signature scheme names
> 730:      * while establishing the SSL/TLS/DTLS connections.

I think this condition should be part of the API specification, and not the implementation specification. This needs to be a required part of the API, otherwise applications cannot safely rely on other implementations of this class to return copies. I suggest moving it to the `@returns` clause.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 736:

> 734:      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
> 735:      * System Property, {@systemProperty jdk.tls.client.SignatureSchemes}
> 736:      * and/or {@systemProperty jdk.tls.server.SignatureSchemes}, to customize

Suggest rewording as "the {@systemProperty jdk.tls.client.SignatureSchemes} and/or {@systemProperty jdk.tls.server.SignatureSchemes} system properties to customize ..."

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 742:

> 740:      * objects, or {@code null} for pre-populated objects.
> 741:      *
> 742:      * @return {@code null} or an array of signature scheme {@code String}s.

Suggest rephrasing as "an array of signature scheme {@code Strings} or {@null} if none have been set."

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 757:

> 755:      * can be used over the SSL/TLS/DTLS protocols.
> 756:      * <p>
> 757:      * Note that the standard list of signature scheme names may be found in

s/may be found/are defined/

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 761:

> 759:      * "{@docRoot}/../specs/security/standard-names.html#signature-schemes">
> 760:      * Signature Schemes</a> section of the Java Security Standard Algorithm
> 761:      * Names Specification. Providers may support signature schemes not found

s/found/defined/

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 762:

> 760:      * Signature Schemes</a> section of the Java Security Standard Algorithm
> 761:      * Names Specification. Providers may support signature schemes not found
> 762:      * in this list or might not use the recommended name for a certain

s/might/may/

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 766:

> 764:      *
> 765:      * @implSpec
> 766:      * This method will make a copy of the {@code signatureSchemes} array.

Should be part of API specification (see my similar comment on `getSignatureSchemes`.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 769:

> 767:      *
> 768:      * @param signatureSchemes {@code null} or an ordered array of signature
> 769:      *        scheme names, with the first entry being the most preferred.

Suggest rewording as: "an ordered array of signature scheme names with the first entry being the most preferred, or {@null}."

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 770:

> 768:      * @param signatureSchemes {@code null} or an ordered array of signature
> 769:      *        scheme names, with the first entry being the most preferred.
> 770:      * @throws IllegalArgumentException if any element in the non-empty

I don't think the word "non-empty" is necessary as an empty array has no elements.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 786:

> 784:                 if (scheme == null || scheme.isBlank()) {
> 785:                     throw new IllegalArgumentException(
> 786:                         "An element of signatureSchemes was null or blank");

s/was/is/

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From mullan at openjdk.java.net  Wed Feb  2 14:48:18 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 2 Feb 2022 14:48:18 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v2]
In-Reply-To: <1GU_LQE4xPb-k02FTR5Hh-gqBhZTydgJsZf-7SwqY9M=.f972b0ea-0e93-4908-b890-7d57c26929d1@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <U_1vl7GpKX2PEBHHY6KcJI4i37uwXwU_xEFhklWan34=.45a56f3b-9da0-406e-8e3b-d3c0cbafd494@github.com>
 <IZRUfuXYVjKW6nK_Sd2UNpr2QOdf6M5XC8cOuVo6AE8=.7b9de096-7cf8-4f41-b7c7-4dfa1309db9d@github.com>
 <Xuzs8p6keG9rol3ad_Eh6JQcZV5Hu5yV9u70xJ8HD4o=.aaf3d417-54f2-45df-804c-ca1418e0a109@github.com>
 <TRp4gf1XxdtDmwWZJ41H_oZc6Wt8K_KU5U1VRFFXkZI=.80fc1318-d2f6-436b-aa68-88d54b164b63@github.com>
 <1GU_LQE4xPb-k02FTR5Hh-gqBhZTydgJsZf-7SwqY9M=.f972b0ea-0e93-4908-b890-7d57c26929d1@github.com>
Message-ID: <vgBVDG9byVqlsNrqEJnBn7cE2fIFVpTFcmQxfVwfmJQ=.c6b7bcc4-c8b1-4a52-81b5-3a066d3d6c57@github.com>

On Tue, 1 Feb 2022 06:42:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Ok. You should specify what the default value of the signature schemes parameter is for this constructor as it does for the other parameters.
>
> Good catch.  Updated.

Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Wed Feb  2 19:12:56 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Feb 2022 19:12:56 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>

> 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

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  More update for the sec and impl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/b5161f75..6b74767e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=07-08

  Stats: 71 lines in 4 files changed: 22 ins; 14 del; 35 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

From xuelei at openjdk.java.net  Wed Feb  2 19:19:06 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Feb 2022 19:19:06 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v8]
In-Reply-To: <ywNT7xJLx6IFkUdeGwJIyApN5nm3D1F7MFPaSm9ooUA=.83c17630-167f-4222-9d0c-a52a25ede896@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <sG6K-OdLargm-F0NU2y6T0p5ZZ1DOJh-AHR7OwwGLas=.77b93b0d-4246-4486-ad0c-c548b89df837@github.com>
 <ywNT7xJLx6IFkUdeGwJIyApN5nm3D1F7MFPaSm9ooUA=.83c17630-167f-4222-9d0c-a52a25ede896@github.com>
Message-ID: <_tv1PlD90bJCcJvKWPx373BEvKUElF6AMnhKzH3GI9c=.11c1c252-2a33-412e-9355-a75d6b717402@github.com>

On Wed, 2 Feb 2022 14:45:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> A few more comments on the API.

All good catches!   Thank you very much.  Updated the spec, CSR and impl.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From kevinw at openjdk.java.net  Wed Feb  2 21:42:40 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 2 Feb 2022 21:42:40 GMT
Subject: RFR: 8272777: Clean up remaining AccessController warnings in test
 library
Message-ID: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>

Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied).

-------------

Commit messages:
 - 8272777: Clean up remaining AccessController warnings in test library

Changes: https://git.openjdk.java.net/jdk/pull/7328/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7328&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272777
  Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7328.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7328/head:pull/7328

PR: https://git.openjdk.java.net/jdk/pull/7328

From mullan at openjdk.java.net  Wed Feb  2 22:09:15 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 2 Feb 2022 22:09:15 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
Message-ID: <7Xyi3AzQOTsAW6xBtgnWviEyMZC0KGMmfeL_Vaw9qV0=.701cded7-5b72-4a65-8ca0-514469dde051@github.com>

On Wed, 2 Feb 2022 19:12:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More update for the sec and impl

Ok, great. I'll need another day or so to review the implementation changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From mullan at openjdk.java.net  Wed Feb  2 22:16:07 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 2 Feb 2022 22:16:07 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
Message-ID: <B7f0ST6A-Jux19Tk-ZUmEPI8oN8H_2cup09mQB8T4MY=.37d96061-7001-4f58-882f-a767bcacda92@github.com>

On Wed, 2 Feb 2022 19:12:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More update for the sec and impl

On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From rriggs at openjdk.java.net  Wed Feb  2 22:20:06 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 2 Feb 2022 22:20:06 GMT
Subject: RFR: 8272777: Clean up remaining AccessController warnings in test
 library
In-Reply-To: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>
References: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>
Message-ID: <_L4Gi3dFyz96bvNUHDkT7IuStFCz3NzUG_gRvtvemNA=.ac833bfc-d84a-4ce0-9053-ed9b515858cc@github.com>

On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied).

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7328

From xuelei at openjdk.java.net  Wed Feb  2 22:31:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Feb 2022 22:31:16 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
Message-ID: <_5H87ADjUIdbVDc-hGXOH-7NFPhG-IvYTw2auTKGnl0=.acd15baf-dfa4-4812-8130-300e851d98d8@github.com>

On Wed, 2 Feb 2022 19:12:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More update for the sec and impl

>

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Wed Feb  2 22:31:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Feb 2022 22:31:16 GMT
Subject: Withdrawn: 8280494: (D)TLS signature schemes
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <uWVHdt49CXs18xes8qUML1s-9xpVjBAXe_Eq8J3LmhY=.8daaf915-871d-4af1-982b-1b5c426a0245@github.com>

On Thu, 27 Jan 2022 22:06:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Wed Feb  2 22:45:14 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Feb 2022 22:45:14 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <B7f0ST6A-Jux19Tk-ZUmEPI8oN8H_2cup09mQB8T4MY=.37d96061-7001-4f58-882f-a767bcacda92@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
 <B7f0ST6A-Jux19Tk-ZUmEPI8oN8H_2cup09mQB8T4MY=.37d96061-7001-4f58-882f-a767bcacda92@github.com>
Message-ID: <P4_y1Yt_iLdbSvZpAm4HsanrXyy4WTkfpWZsfqG6_Jw=.ca20cecc-2a13-4fa7-9d0b-6fa9dab489a2@github.com>

On Wed, 2 Feb 2022 22:13:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think.

It's a good question.  A 3rd party provider need to support to the new APIs.  Otherwise, the spec does not really work except to use the default values.  It might be overweighted if the Java SE API has to detect the implementation details.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From sspitsyn at openjdk.java.net  Wed Feb  2 22:56:16 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 2 Feb 2022 22:56:16 GMT
Subject: RFR: 8272777: Clean up remaining AccessController warnings in test
 library
In-Reply-To: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>
References: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>
Message-ID: <ogCbA-3fxGva6s5rN1akZ9rIa8Lf-T2epQaodvEPXsw=.328f38c9-f9f9-4896-9184-63740fa31b2c@github.com>

On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied).

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7328

From xuelei at openjdk.java.net  Thu Feb  3 00:33:13 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Feb 2022 00:33:13 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled [v2]
In-Reply-To: <CbkUCTEJ14-Em7UKsjDkZMYuHXS1j_gMjlgTl4ufhXI=.4126366b-9cdc-44d2-9e41-8fc83b0d1657@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
 <CbkUCTEJ14-Em7UKsjDkZMYuHXS1j_gMjlgTl4ufhXI=.4126366b-9cdc-44d2-9e41-8fc83b0d1657@github.com>
Message-ID: <b8krPd1uSphsGxRX4QWLWfyI2stPugza0IEu8F1jM0c=.4b103dc1-32ae-4778-868d-3e3cfdfcc6ec@github.com>

On Wed, 26 Jan 2022 18:58:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> A hostname in an URL ending with a dot is valid (See RFC 1034).  However, it is not a valid SNI hostname.  The ending dot should be ignored while checking the hostname with SNI or the name in a X.509 certificate.
>> 
>> The update could be verified with jshell.
>> $ $JDK_HOME/bin/jshell
>> jshell> URL url = new URL("https://www.google.com./");
>> jshell> URLConnection conn = url.openConnection();
>> jshell> conn.connect();
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add regression test with customized hosts

ping ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/7205

From weijun at openjdk.java.net  Thu Feb  3 01:22:04 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 3 Feb 2022 01:22:04 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled [v2]
In-Reply-To: <CbkUCTEJ14-Em7UKsjDkZMYuHXS1j_gMjlgTl4ufhXI=.4126366b-9cdc-44d2-9e41-8fc83b0d1657@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
 <CbkUCTEJ14-Em7UKsjDkZMYuHXS1j_gMjlgTl4ufhXI=.4126366b-9cdc-44d2-9e41-8fc83b0d1657@github.com>
Message-ID: <8nwYMzJN2xQ8n_4E-sNB8kSu_Y-wg_1dVcxkJR2NpSo=.4882ec8b-dbcb-40dc-b872-7ad604032d00@github.com>

On Wed, 26 Jan 2022 18:58:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> A hostname in an URL ending with a dot is valid (See RFC 1034).  However, it is not a valid SNI hostname.  The ending dot should be ignored while checking the hostname with SNI or the name in a X.509 certificate.
>> 
>> The update could be verified with jshell.
>> $ $JDK_HOME/bin/jshell
>> jshell> URL url = new URL("https://www.google.com./");
>> jshell> URLConnection conn = url.openConnection();
>> jshell> conn.connect();
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add regression test with customized hosts

test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java line 8:

> 6:  * it under the terms of the GNU General Public License version 2 as
> 7:  * published by the Free Software Foundation. THL A29 Limited designates
> 8:  * this particular file as subject to the "Classpath" exception as provided

Please remove the Classpath part. It does not apply to tests. Same comment to the other file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7205

From xuelei at openjdk.java.net  Thu Feb  3 03:46:43 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Feb 2022 03:46:43 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled [v3]
In-Reply-To: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
Message-ID: <QZDLlghxNo1ynH4qlgds-MDuEG-IoONonVlUdLuXtHw=.9caf9ebb-9771-4d11-a29f-86e7c7c93283@github.com>

> A hostname in an URL ending with a dot is valid (See RFC 1034).  However, it is not a valid SNI hostname.  The ending dot should be ignored while checking the hostname with SNI or the name in a X.509 certificate.
> 
> The update could be verified with jshell.
> $ $JDK_HOME/bin/jshell
> jshell> URL url = new URL("https://www.google.com./");
> jshell> URLConnection conn = url.openConnection();
> jshell> conn.connect();

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  Update test copyright sections

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7205/files
  - new: https://git.openjdk.java.net/jdk/pull/7205/files/fe3e5f6b..0d53a77c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7205&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7205&range=01-02

  Stats: 36 lines in 2 files changed: 10 ins; 4 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7205.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7205/head:pull/7205

PR: https://git.openjdk.java.net/jdk/pull/7205

From weijun at openjdk.java.net  Thu Feb  3 03:46:44 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 3 Feb 2022 03:46:44 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled [v3]
In-Reply-To: <QZDLlghxNo1ynH4qlgds-MDuEG-IoONonVlUdLuXtHw=.9caf9ebb-9771-4d11-a29f-86e7c7c93283@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
 <QZDLlghxNo1ynH4qlgds-MDuEG-IoONonVlUdLuXtHw=.9caf9ebb-9771-4d11-a29f-86e7c7c93283@github.com>
Message-ID: <DgQ4-KjL7rwmrRdefy85m4-FKs2He-_aTbIxWcbUecY=.5cad7a3c-fde6-4c82-a7f2-41a0ecb4aad2@github.com>

On Thu, 3 Feb 2022 03:42:33 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> A hostname in an URL ending with a dot is valid (See RFC 1034).  However, it is not a valid SNI hostname.  The ending dot should be ignored while checking the hostname with SNI or the name in a X.509 certificate.
>> 
>> The update could be verified with jshell.
>> $ $JDK_HOME/bin/jshell
>> jshell> URL url = new URL("https://www.google.com./");
>> jshell> URLConnection conn = url.openConnection();
>> jshell> conn.connect();
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test copyright sections

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7205

From xuelei at openjdk.java.net  Thu Feb  3 03:46:46 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Feb 2022 03:46:46 GMT
Subject: RFR: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled [v2]
In-Reply-To: <8nwYMzJN2xQ8n_4E-sNB8kSu_Y-wg_1dVcxkJR2NpSo=.4882ec8b-dbcb-40dc-b872-7ad604032d00@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
 <CbkUCTEJ14-Em7UKsjDkZMYuHXS1j_gMjlgTl4ufhXI=.4126366b-9cdc-44d2-9e41-8fc83b0d1657@github.com>
 <8nwYMzJN2xQ8n_4E-sNB8kSu_Y-wg_1dVcxkJR2NpSo=.4882ec8b-dbcb-40dc-b872-7ad604032d00@github.com>
Message-ID: <YopDSxjD_0wP3MbOkbHKugL3QkdYC_iFg-F1enZGlZw=.1e053dc1-0a0d-4750-8597-660a3971e413@github.com>

On Thu, 3 Feb 2022 01:19:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add regression test with customized hosts
>
> test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java line 8:
> 
>> 6:  * it under the terms of the GNU General Public License version 2 as
>> 7:  * published by the Free Software Foundation. THL A29 Limited designates
>> 8:  * this particular file as subject to the "Classpath" exception as provided
> 
> Please remove the Classpath part. It does not apply to tests. Same comment to the other file.

Ooops, I missed it.  Thank you!  Updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7205

From xuelei at openjdk.java.net  Thu Feb  3 06:32:12 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Feb 2022 06:32:12 GMT
Subject: Integrated: 8065422: Trailing dot in hostname causes TLS handshake to
 fail with SNI disabled
In-Reply-To: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
References: <5NXPQeXxUTpeopdnJzGszJyuoRGuZw6-NDUOEbB9Bso=.5a6fa970-cd53-462f-abc8-e8cff383c44d@github.com>
Message-ID: <sFXHcnxnDCu5eII5ZHW3y9Zpekqb7Aa-7fEB6kVmCN0=.5b210a6a-066f-4e79-bd86-70b85c74c831@github.com>

On Tue, 25 Jan 2022 00:13:32 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> A hostname in an URL ending with a dot is valid (See RFC 1034).  However, it is not a valid SNI hostname.  The ending dot should be ignored while checking the hostname with SNI or the name in a X.509 certificate.
> 
> The update could be verified with jshell.
> $ $JDK_HOME/bin/jshell
> jshell> URL url = new URL("https://www.google.com./");
> jshell> URLConnection conn = url.openConnection();
> jshell> conn.connect();

This pull request has now been integrated.

Changeset: a95ee5ad
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a95ee5ada230a0177517efd3a417f319066169dd
Stats:     616 lines in 4 files changed: 613 ins; 0 del; 3 mod

8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/7205

From kevinw at openjdk.java.net  Thu Feb  3 10:14:14 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 3 Feb 2022 10:14:14 GMT
Subject: RFR: 8272777: Clean up remaining AccessController warnings in test
 library
In-Reply-To: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>
References: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>
Message-ID: <UzycM0YDltihvfjtJShFvINVIL3lpL1ro0QQuQUsINc=.00c128ee-b3de-48cf-90e7-f3dc7eff462a@github.com>

On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied).

Thanks Roger and Serguei!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7328

From kevinw at openjdk.java.net  Thu Feb  3 10:14:14 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 3 Feb 2022 10:14:14 GMT
Subject: Integrated: 8272777: Clean up remaining AccessController warnings in
 test library
In-Reply-To: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>
References: <aPKb80c62y0Cq3WSoJQfg3NmQoftXGcFtH0iDqKD5aw=.17ba6bf5-9e70-4be7-a84e-6dcd27556c77@github.com>
Message-ID: <mmLDRRLnGDWCzAv1aQwdzyvtPNpTMEe3R5-Uvjr2DNI=.57d19124-98b3-4024-8f7a-24cadf5091d1@github.com>

On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied).

This pull request has now been integrated.

Changeset: 63a00a0d
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/63a00a0df24b154ef459936dbd69bcd2f0626235
Stats:     5 lines in 3 files changed: 3 ins; 0 del; 2 mod

8272777: Clean up remaining AccessController warnings in test library

Reviewed-by: rriggs, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7328

From duke at openjdk.java.net  Thu Feb  3 11:22:57 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Thu, 3 Feb 2022 11:22:57 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v4]
In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
Message-ID: <cWeSIQfCvQ049dkCCJKjPmfYNAGEcX8qJ16OWXIq7J8=.8cacbd79-ca0f-4411-8fc1-9b209b5d38d4@github.com>

> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
> JDK-8273142
> JDK-8268464
> JDK-8268133

Mahendra Chhipa 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 four additional commits since the last revision:

 - Merge branch 'master' into JDK-8061729
 - Implemented the review comments.
 - Implemented review comments.
 - JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5937/files
  - new: https://git.openjdk.java.net/jdk/pull/5937/files/b1b76be9..6f4b7d3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=02-03

  Stats: 1041549 lines in 4815 files changed: 560242 ins; 453231 del; 28076 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937

PR: https://git.openjdk.java.net/jdk/pull/5937

From mullan at openjdk.java.net  Thu Feb  3 15:45:15 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 3 Feb 2022 15:45:15 GMT
Subject: [jdk18] RFR: 8279385: [test]  Adjust
 sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344
In-Reply-To: <X5mFtyCzo_UtDUuTuCNVtzIDSBmZdxA0HV9EHxi6NDU=.b24627f1-9cb7-4913-a87f-2295a3b3b322@github.com>
References: <X5mFtyCzo_UtDUuTuCNVtzIDSBmZdxA0HV9EHxi6NDU=.b24627f1-9cb7-4913-a87f-2295a3b3b322@github.com>
Message-ID: <FrUCzSokcn5pIEoefDk9Zm4y4ewZHLEAaCVXLzRzhoM=.81376bc0-0a3e-4737-9a19-0c7adc535aba@github.com>

On Mon, 10 Jan 2022 13:36:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8279385: [test]  Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/91

From xuelei at openjdk.java.net  Thu Feb  3 17:16:23 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Feb 2022 17:16:23 GMT
Subject: [jdk18] RFR: 8279385: [test]  Adjust
 sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344
In-Reply-To: <X5mFtyCzo_UtDUuTuCNVtzIDSBmZdxA0HV9EHxi6NDU=.b24627f1-9cb7-4913-a87f-2295a3b3b322@github.com>
References: <X5mFtyCzo_UtDUuTuCNVtzIDSBmZdxA0HV9EHxi6NDU=.b24627f1-9cb7-4913-a87f-2295a3b3b322@github.com>
Message-ID: <NQ4lT67InDhOwy6FvjPiuMF4JgixVpiKHVSDQQQciL8=.9267fa61-c609-4b67-b841-f84fd156b04b@github.com>

On Mon, 10 Jan 2022 13:36:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8279385: [test]  Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/91

From weijun at openjdk.java.net  Thu Feb  3 17:21:32 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 3 Feb 2022 17:21:32 GMT
Subject: RFR: 8281175: Add a -providerPath option to jarsigner
Message-ID: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>

Add the `-providerPath` option to jarsigner to be consistent with keytool.

-------------

Commit messages:
 - 8281175: Add a -providerPath option to jarsigner

Changes: https://git.openjdk.java.net/jdk/pull/7338/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7338&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281175
  Stats: 39 lines in 3 files changed: 24 ins; 5 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7338.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7338/head:pull/7338

PR: https://git.openjdk.java.net/jdk/pull/7338

From xuelei at openjdk.java.net  Thu Feb  3 18:15:04 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 3 Feb 2022 18:15:04 GMT
Subject: RFR: 8281175: Add a -providerPath option to jarsigner
In-Reply-To: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
References: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
Message-ID: <c61VbPnBszZDrBE2wrUhbua95-o39hPp2YLw1RuyZmo=.5f7cd68b-7c2f-45dc-9053-200b45a0670d@github.com>

On Thu, 3 Feb 2022 17:12:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add the `-providerPath` option to jarsigner to be consistent with keytool.

Looks good to me except a minor comment.  It's fine to me if you don't want to take it.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 256:

> 254:                     String path = null;
> 255:                     path = PathList.appendPath(
> 256:                             path, System.getProperty("java.class.path"));

Is it more straightforward to use "String path = System.getProperty(...)", by combining line 254 and 255?

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7338

From weijun at openjdk.java.net  Thu Feb  3 18:29:12 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 3 Feb 2022 18:29:12 GMT
Subject: RFR: 8281175: Add a -providerPath option to jarsigner
In-Reply-To: <c61VbPnBszZDrBE2wrUhbua95-o39hPp2YLw1RuyZmo=.5f7cd68b-7c2f-45dc-9053-200b45a0670d@github.com>
References: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
 <c61VbPnBszZDrBE2wrUhbua95-o39hPp2YLw1RuyZmo=.5f7cd68b-7c2f-45dc-9053-200b45a0670d@github.com>
Message-ID: <vv_ocJW9OfWtbmVQhHkfTebKiD_XWVuODtOY-bCZPC0=.37a6ef52-b78f-428f-b078-fe946e8d2a1f@github.com>

On Thu, 3 Feb 2022 18:03:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Add the `-providerPath` option to jarsigner to be consistent with keytool.
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 256:
> 
>> 254:                     String path = null;
>> 255:                     path = PathList.appendPath(
>> 256:                             path, System.getProperty("java.class.path"));
> 
> Is it more straightforward to use "String path = System.getProperty(...)", by combining line 254 and 255?

Seems so. I'll fix it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7338

From weijun at openjdk.java.net  Thu Feb  3 18:32:42 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 3 Feb 2022 18:32:42 GMT
Subject: RFR: 8281175: Add a -providerPath option to jarsigner [v2]
In-Reply-To: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
References: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
Message-ID: <PkNwpEq0iLG-oeroy1to30pHtgxPdnVrF3HioAckdxA=.a6fdb35c-4e30-4c36-ac31-77f19271774d@github.com>

> Add the `-providerPath` option to jarsigner to be consistent with keytool.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  no need to append to null

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7338/files
  - new: https://git.openjdk.java.net/jdk/pull/7338/files/c28d9c1d..99172de5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7338&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7338&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7338.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7338/head:pull/7338

PR: https://git.openjdk.java.net/jdk/pull/7338

From weijun at openjdk.java.net  Thu Feb  3 18:35:28 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 3 Feb 2022 18:35:28 GMT
Subject: RFR: 8281234: The -protected option is not always checked in keytool
 and jarsigner
Message-ID: <myBBDTONMJ5D3z2WZ5zjbnNdWGAuVvjwmrezvu_LZhw=.808f9c00-e41e-4e6a-a301-de2b5b2acf2a@github.com>

The option means there is no need to provide a password when loading a keystore. In some places in jarsigner and keytool, even with the option specified, password is still prompted for or warnings are still shown.

-------------

Commit messages:
 - 8281234: The -protected option is not always checked in keytool and jarsigner

Changes: https://git.openjdk.java.net/jdk/pull/7339/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7339&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281234
  Stats: 198 lines in 4 files changed: 194 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7339.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7339/head:pull/7339

PR: https://git.openjdk.java.net/jdk/pull/7339

From hchao at openjdk.java.net  Thu Feb  3 19:14:14 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 3 Feb 2022 19:14:14 GMT
Subject: RFR: 8281175: Add a -providerPath option to jarsigner [v2]
In-Reply-To: <PkNwpEq0iLG-oeroy1to30pHtgxPdnVrF3HioAckdxA=.a6fdb35c-4e30-4c36-ac31-77f19271774d@github.com>
References: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
 <PkNwpEq0iLG-oeroy1to30pHtgxPdnVrF3HioAckdxA=.a6fdb35c-4e30-4c36-ac31-77f19271774d@github.com>
Message-ID: <BaNEnNRmO-0ViZGqkLWfonk9bAF4Y_1Ramu-Zu1PAb8=.e7e9b854-12a9-433b-a00c-84d92c93b1cb@github.com>

On Thu, 3 Feb 2022 18:32:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add the `-providerPath` option to jarsigner to be consistent with keytool.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to append to null

Code change looks good to me.
I have a comment on the CSR. The ?Options for jarsigner? section in `jarsigner` manpage, where it describes `-digestalg algorithm` and `-sigalg algorithm`, we would update it to include this new option `-providerPath` there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7338

From weijun at openjdk.java.net  Thu Feb  3 20:49:05 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 3 Feb 2022 20:49:05 GMT
Subject: RFR: 8281175: Add a -providerPath option to jarsigner [v2]
In-Reply-To: <BaNEnNRmO-0ViZGqkLWfonk9bAF4Y_1Ramu-Zu1PAb8=.e7e9b854-12a9-433b-a00c-84d92c93b1cb@github.com>
References: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
 <PkNwpEq0iLG-oeroy1to30pHtgxPdnVrF3HioAckdxA=.a6fdb35c-4e30-4c36-ac31-77f19271774d@github.com>
 <BaNEnNRmO-0ViZGqkLWfonk9bAF4Y_1Ramu-Zu1PAb8=.e7e9b854-12a9-433b-a00c-84d92c93b1cb@github.com>
Message-ID: <oBP3H4GOu49Q04zkJ7-KRRLZQ3kRIgk13GCIoBfUHQA=.e09a5439-a8c1-48d1-9eda-1d31cebe2029@github.com>

On Thu, 3 Feb 2022 19:11:17 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Code change looks good to me.
> I have a comment on the CSR. The ?Options for jarsigner? section in `jarsigner` manpage, where it describes `-digestalg algorithm` and `-sigalg algorithm`, we would update it to include this new option `-providerPath` there.

Correct. I've added some lines in the man page.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7338

From mullan at openjdk.java.net  Thu Feb  3 21:34:12 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 3 Feb 2022 21:34:12 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <P4_y1Yt_iLdbSvZpAm4HsanrXyy4WTkfpWZsfqG6_Jw=.ca20cecc-2a13-4fa7-9d0b-6fa9dab489a2@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
 <B7f0ST6A-Jux19Tk-ZUmEPI8oN8H_2cup09mQB8T4MY=.37d96061-7001-4f58-882f-a767bcacda92@github.com>
 <P4_y1Yt_iLdbSvZpAm4HsanrXyy4WTkfpWZsfqG6_Jw=.ca20cecc-2a13-4fa7-9d0b-6fa9dab489a2@github.com>
Message-ID: <hFlYbqjO825biF8_5GBgAbgR4OfRo1T8-C_jInMqOUM=.5e7316dd-0ed5-497a-93e2-0b02ba2700bc@github.com>

On Wed, 2 Feb 2022 22:41:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think.
> 
> It's a good question. A 3rd party provider need to support to the new APIs. Otherwise, the spec does not really work except to use the default values. It might be overweighted if the Java SE API has to detect the implementation details.

Fair point. However, I think then we have to make some changes to the specification wording that state that these new methods depend on support from the underlying provider. In other words something like `SSLParameters.setSignatureSchemes(new String[] {"ecdsa_secp521r1_sha512"})` could be silently ignored if the provider doesn't support the new method. It's unfortunate because a developer may miss this point or it may go undetected, whereas throwing an `UnsupportedOperationException` would probably be detected (but which won't work for this API). I do note that previous methods we have added to SSLParameters have probably had this same issue. But I think we should try to address it better with these methods. I'll suggest some wording changes.

To help reduce this potential issue, we can make sure we mention this issue in the release notes, and encourage 3rd party providers to add support for these methods when they add support for JDK 18.

Open to other ideas though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From weijun at openjdk.java.net  Fri Feb  4 01:19:51 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 4 Feb 2022 01:19:51 GMT
Subject: RFR: 8281234: The -protected option is not always checked in
 keytool and jarsigner [v2]
In-Reply-To: <myBBDTONMJ5D3z2WZ5zjbnNdWGAuVvjwmrezvu_LZhw=.808f9c00-e41e-4e6a-a301-de2b5b2acf2a@github.com>
References: <myBBDTONMJ5D3z2WZ5zjbnNdWGAuVvjwmrezvu_LZhw=.808f9c00-e41e-4e6a-a301-de2b5b2acf2a@github.com>
Message-ID: <GG1iYptIpwueW-PnWJu97qjVYkGMWP2wv7AX7WKyCIA=.ff612811-17d7-4deb-a0fb-54d238862049@github.com>

> The option means there is no need to provide a password when loading a keystore. In some places in jarsigner and keytool, even with the option specified, password is still prompted for or warnings are still shown.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  only expand system property if it has a name

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7339/files
  - new: https://git.openjdk.java.net/jdk/pull/7339/files/7030b908..3f23e2d9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7339&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7339&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7339.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7339/head:pull/7339

PR: https://git.openjdk.java.net/jdk/pull/7339

From aturbanov at openjdk.java.net  Fri Feb  4 07:11:10 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 4 Feb 2022 07:11:10 GMT
Subject: Integrated: 8280970: Cleanup dead code in java.security.Provider
In-Reply-To: <G0Hx4RPo_c8gmFz7mlfEhEHRg-6s2SbEvcnEy_VME4Y=.205f4a50-9922-4629-8a7c-43182d56d8bb@github.com>
References: <G0Hx4RPo_c8gmFz7mlfEhEHRg-6s2SbEvcnEy_VME4Y=.205f4a50-9922-4629-8a7c-43182d56d8bb@github.com>
Message-ID: <hAMuN5PXvvqxfvGYLUZ4ZhV-Xal212H8tkGHoNj3q-o=.90b7318e-60fb-4624-bbda-31c30be400c6@github.com>

On Thu, 20 Jan 2022 18:25:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Method `Provider.getKey` was added in [JDK-8276660](https://bugs.openjdk.java.net/browse/JDK-8276660). It was unused since introduction.
> Method `EngineDescription.getConstructorParameterClass()` and field `EngineDescription.constructorParameterClass` is unused since [JDK-7191662](https://bugs.openjdk.java.net/browse/JDK-7191662)

This pull request has now been integrated.

Changeset: 63e11cfa
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/63e11cfa3f887515ca36ab5147c3e6fa540978d3
Stats:     14 lines in 1 file changed: 0 ins; 14 del; 0 mod

8280970: Cleanup dead code in java.security.Provider

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk/pull/7164

From xuelei at openjdk.java.net  Fri Feb  4 07:46:07 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Feb 2022 07:46:07 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <hFlYbqjO825biF8_5GBgAbgR4OfRo1T8-C_jInMqOUM=.5e7316dd-0ed5-497a-93e2-0b02ba2700bc@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
 <B7f0ST6A-Jux19Tk-ZUmEPI8oN8H_2cup09mQB8T4MY=.37d96061-7001-4f58-882f-a767bcacda92@github.com>
 <P4_y1Yt_iLdbSvZpAm4HsanrXyy4WTkfpWZsfqG6_Jw=.ca20cecc-2a13-4fa7-9d0b-6fa9dab489a2@github.com>
 <hFlYbqjO825biF8_5GBgAbgR4OfRo1T8-C_jInMqOUM=.5e7316dd-0ed5-497a-93e2-0b02ba2700bc@github.com>
Message-ID: <CJBfFRylqTahl916QY56eFP5TvLaSe3yjSCY-OlPnS0=.b2e0896d-5553-4701-8f45-dd2cccaf0d33@github.com>

On Thu, 3 Feb 2022 21:30:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think.
> > 
> > 
> > It's a good question. A 3rd party provider need to support to the new APIs. Otherwise, the spec does not really work except to use the default values. It might be overweighted if the Java SE API has to detect the implementation details.
> 
> Fair point. However, I think then we have to make some changes to the specification wording that state that these new methods depend on support from the underlying provider. In other words something like `SSLParameters.setSignatureSchemes(new String[] {"ecdsa_secp521r1_sha512"})` could be silently ignored if the provider doesn't support the new method. It's unfortunate because a developer may miss this point or it may go undetected, whereas throwing an `UnsupportedOperationException` would probably be detected (but which won't work for this API). I do note that previous methods we have added to SSLParameters have probably had this same issue. But I think we should try to address it better with these methods. I'll suggest some wording changes.
> 
> To help reduce this potential issue, we can make sure we mention this issue in the release notes, and encourage 3rd party providers to add support for these methods when they add support for JDK 18.
> 
> Open to other ideas though.

Good points.  I will try to add an apiNote.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From mbaesken at openjdk.java.net  Fri Feb  4 07:51:13 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 4 Feb 2022 07:51:13 GMT
Subject: [jdk18] Integrated: 8279385: [test]  Adjust
 sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344
In-Reply-To: <X5mFtyCzo_UtDUuTuCNVtzIDSBmZdxA0HV9EHxi6NDU=.b24627f1-9cb7-4913-a87f-2295a3b3b322@github.com>
References: <X5mFtyCzo_UtDUuTuCNVtzIDSBmZdxA0HV9EHxi6NDU=.b24627f1-9cb7-4913-a87f-2295a3b3b322@github.com>
Message-ID: <rvAIZ06Rsg7vt3_F7mUsl1G7ggM_PXJHo9SYXblXzss=.af636215-f517-4a67-adde-ed4e32304656@github.com>

On Mon, 10 Jan 2022 13:36:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8279385: [test]  Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344

This pull request has now been integrated.

Changeset: 01f93ddf
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/01f93ddf18daea5c0798ac949c6717c37d9cefa0
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8279385: [test]  Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344

Reviewed-by: mullan, xuelei
Backport-of: 9bdf6eb7b2412ecff523015f1430dfb6a0e4dd09

-------------

PR: https://git.openjdk.java.net/jdk18/pull/91

From jwilhelm at openjdk.java.net  Fri Feb  4 13:46:05 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 4 Feb 2022 13:46:05 GMT
Subject: RFR: Merge jdk18
Message-ID: <2BadReJSAoCMpSuLYdr8_tQe3yi47rVfGWL-y4_YpU4=.20f6c7e0-27b8-40f6-a06c-206a3b591911@github.com>

Forwardport JDK 18 -> JDK 19

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18
 - 8279385: [test]  Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/7351/files
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7351.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7351/head:pull/7351

PR: https://git.openjdk.java.net/jdk/pull/7351

From lancea at openjdk.java.net  Fri Feb  4 14:01:48 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Feb 2022 14:01:48 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
Message-ID: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>

Hi all,

Please review the attached patch to address

- That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
- Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs

Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs

Best
Lance

-------------

Commit messages:
 - Update copyright year
 - Address Zip/JarFile::getInputStream Exception handling

Changes: https://git.openjdk.java.net/jdk/pull/7348/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280409
  Stats: 1081 lines in 3 files changed: 1026 ins; 26 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348

PR: https://git.openjdk.java.net/jdk/pull/7348

From jwilhelm at openjdk.java.net  Fri Feb  4 14:51:10 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 4 Feb 2022 14:51:10 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <2BadReJSAoCMpSuLYdr8_tQe3yi47rVfGWL-y4_YpU4=.20f6c7e0-27b8-40f6-a06c-206a3b591911@github.com>
References: <2BadReJSAoCMpSuLYdr8_tQe3yi47rVfGWL-y4_YpU4=.20f6c7e0-27b8-40f6-a06c-206a3b591911@github.com>
Message-ID: <82huB3y7Zg2Sfepn-QoGmBKm5ujV908DZ92uPcCcvKQ=.bfdcaf38-5433-4062-8c11-b9e47118de8d@github.com>

On Fri, 4 Feb 2022 13:38:52 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 7207f2a3
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7207f2a3b59c684d9d51d378257629729fa7041d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/7351

From alanb at openjdk.java.net  Fri Feb  4 15:14:16 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 4 Feb 2022 15:14:16 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <FZEhhAgnMfwGuyLCbvemF8yQ7CtnnrT08LMMZBz6uag=.90153883-8187-4c85-9635-d81dc9dcc963@github.com>

On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

src/java.base/share/classes/java/util/jar/JarFile.java line 840:

> 838:         throws IOException
> 839:     {
> 840:         Objects.requireNonNull(ze, "ze");

Is the NPE specified?

src/java.base/share/classes/java/util/jar/JarFile.java line 866:

> 864:         } catch (Exception e2) {
> 865:             // Any other Exception should be a ZipException
> 866:             throw (ZipException) new ZipException("Zip file format error").initCause(e2);

If there is ZIP format error then I would expect ZipException or the more general IOException is already thrown. So I think this is catching other cases, maybe broken manifests or signed JAR files, in which case a JarException may be better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Fri Feb  4 15:22:06 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Feb 2022 15:22:06 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <FZEhhAgnMfwGuyLCbvemF8yQ7CtnnrT08LMMZBz6uag=.90153883-8187-4c85-9635-d81dc9dcc963@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <FZEhhAgnMfwGuyLCbvemF8yQ7CtnnrT08LMMZBz6uag=.90153883-8187-4c85-9635-d81dc9dcc963@github.com>
Message-ID: <TiIB4oeKaIj_4fCqw8-bMvFSp9gfVzk177CaUVHyWrs=.20710b05-93c4-4f73-99d5-9abb0741914a@github.com>

On Fri, 4 Feb 2022 15:06:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the attached patch to address
>> 
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
>> 
>> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
>> 
>> Best
>> Lance
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 840:
> 
>> 838:         throws IOException
>> 839:     {
>> 840:         Objects.requireNonNull(ze, "ze");
> 
> Is the NPE specified?

Yes it is specified in the  JarFile main paragraph

`Unless otherwise noted, passing a null argument to a constructor or method in this class will cause a NullPointerException to be thrown.`

ZipFile::getInputStream validates the argument as soon as it is passed to getInputStream.

> src/java.base/share/classes/java/util/jar/JarFile.java line 866:
> 
>> 864:         } catch (Exception e2) {
>> 865:             // Any other Exception should be a ZipException
>> 866:             throw (ZipException) new ZipException("Zip file format error").initCause(e2);
> 
> If there is ZIP format error then I would expect ZipException or the more general IOException is already thrown. So I think this is catching other cases, maybe broken manifests or signed JAR files, in which case a JarException may be better.

JarFile::getInputStream. mentions ZipException but not JarException which is why I chose this.  If we change this to JarException, I would need to update the javadoc and create a CSR.

Please let me know your preference

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Fri Feb  4 15:58:16 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 4 Feb 2022 15:58:16 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <ocdPUBNCFvEJgmBCxKGU9MxwqJ5ahU57lngv-qqNFQQ=.5564a4c7-feb5-4e57-bdd2-c4b8f331dd90@github.com>

On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

Could these unexpected exceptions also occur when using the `JarInputStream` API?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Fri Feb  4 16:10:11 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Feb 2022 16:10:11 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <ocdPUBNCFvEJgmBCxKGU9MxwqJ5ahU57lngv-qqNFQQ=.5564a4c7-feb5-4e57-bdd2-c4b8f331dd90@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <ocdPUBNCFvEJgmBCxKGU9MxwqJ5ahU57lngv-qqNFQQ=.5564a4c7-feb5-4e57-bdd2-c4b8f331dd90@github.com>
Message-ID: <lUHqxOgL_KtcV9ZeM_8Ci61UIneyhy9e206eXymk6s0=.22b7aded-2d90-43db-b081-76daf75db880@github.com>

On Fri, 4 Feb 2022 15:55:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Could these unexpected exceptions also occur when using the `JarInputStream` API?

It's a different code path as Zip/JarFile leverage the CEN where Zip/JarInputStream leverage the LOC.   I can give it a go and if there is an issue will create a separate issue

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Fri Feb  4 16:39:19 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 4 Feb 2022 16:39:19 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
Message-ID: <tijZT23Eh_Zed15sE4VRdVZl1Bu9ENbiSG5COBcP4bg=.53d2ef0d-0cca-4a95-9f20-2c78b233ef35@github.com>

On Wed, 2 Feb 2022 19:12:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More update for the sec and impl

Changes requested by mullan (Reviewer).

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 713:

> 711:      * in this list or may not use the recommended name for a certain
> 712:      * signature scheme.
> 713:      * <p>

Regarding my previous comment about providers not supporting these new methods, I think something like the following might suffice:


@apiNote Note that a provider may not have been updated to support this method and in that case may return null instead of the default signature schemes for pre-populated objects.
@implNote The SunJSSE provider supports this method.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 735:

> 733:      * {@link #setSignatureSchemes} method has not been called, this method
> 734:      * should return the default signature schemes for connection populated
> 735:      * objects, or {@code null} for pre-populated objects.

I think this sentence should be part of the specification and not the implementation note since ideally you would want all provider implementations to behave this way (assuming they supported this method): 

"If the {@link #setSignatureSchemes} method has not been called, this method should return the default signature schemes for connection populated objects, or {@code null} for pre-populated objects."

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 752:

> 750: 
> 751:     /**
> 752:      * Sets the prioritized array of signature scheme names that

If the system properties are set, does it override this API? I think it is important to mention that here in an @implNote. I know you discuss them in `getSignatureSchemes` but I think a developer is more likely to want to know the behavior of the properties for this method especially if they will override this setting.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 761:

> 759:      * Names Specification.  Providers may support signature schemes not defined
> 760:      * in this list or may not use the recommended name for a certain
> 761:      * signature scheme.

Did you want to say something about what the behavior should be if a provider does not support one of these schemes? Is it ignored, or is an exception thrown?

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 762:

> 760:      * in this list or may not use the recommended name for a certain
> 761:      * signature scheme.
> 762:      *

Regarding my previous comment about providers not supporting these new methods, I think something like the following might suffice:


@apiNote Note that a provider may not have been updated to support this method and in that case may ignore the schemes that are set.
@implNote The SunJSSE provider supports this method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From lancea at openjdk.java.net  Fri Feb  4 16:43:06 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Feb 2022 16:43:06 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <lUHqxOgL_KtcV9ZeM_8Ci61UIneyhy9e206eXymk6s0=.22b7aded-2d90-43db-b081-76daf75db880@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <ocdPUBNCFvEJgmBCxKGU9MxwqJ5ahU57lngv-qqNFQQ=.5564a4c7-feb5-4e57-bdd2-c4b8f331dd90@github.com>
 <lUHqxOgL_KtcV9ZeM_8Ci61UIneyhy9e206eXymk6s0=.22b7aded-2d90-43db-b081-76daf75db880@github.com>
Message-ID: <FvKJW-ChZN19016cs_IcJCtNoxWDOqal1UIUCguMaTI=.7e2f503c-6bc9-4e6c-b346-938259712f12@github.com>

On Fri, 4 Feb 2022 16:06:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > Could these unexpected exceptions also occur when using the `JarInputStream` API?
> 
> It's a different code path as Zip/JarFile leverage the CEN where Zip/JarInputStream leverage the LOC. I can give it a go and if there is an issue will create a separate issue

Not an issue given how Zip/JarInputStream work

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From xuelei at openjdk.java.net  Fri Feb  4 18:15:18 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Feb 2022 18:15:18 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v10]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <e91fiBurv70isPGouyLCtgsDtOgjS9UJJ-LiCIirhI8=.17d39ab2-b560-4681-bdd5-43c5b1c98847@github.com>

> 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

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  More spec udpate

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/6b74767e..9670efbd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=08-09

  Stats: 39 lines in 2 files changed: 34 ins; 3 del; 2 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

From xuelei at openjdk.java.net  Fri Feb  4 18:20:14 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Feb 2022 18:20:14 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <tijZT23Eh_Zed15sE4VRdVZl1Bu9ENbiSG5COBcP4bg=.53d2ef0d-0cca-4a95-9f20-2c78b233ef35@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
 <tijZT23Eh_Zed15sE4VRdVZl1Bu9ENbiSG5COBcP4bg=.53d2ef0d-0cca-4a95-9f20-2c78b233ef35@github.com>
Message-ID: <D2KMCG6xSJr9XmkFYsC6gOhZP8W0KYK5l6GlJ3J_HLo=.41453245-50ae-4672-bd74-c5907c75c150@github.com>

On Fri, 4 Feb 2022 16:34:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More update for the sec and impl
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 735:
> 
>> 733:      * {@link #setSignatureSchemes} method has not been called, this method
>> 734:      * should return the default signature schemes for connection populated
>> 735:      * objects, or {@code null} for pre-populated objects.
> 
> I think this sentence should be part of the specification and not the implementation note since ideally you would want all provider implementations to behave this way (assuming they supported this method): 
> 
> "If the {@link #setSignatureSchemes} method has not been called, this method should return the default signature schemes for connection populated objects, or {@code null} for pre-populated objects."

I agreed.

> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 752:
> 
>> 750: 
>> 751:     /**
>> 752:      * Sets the prioritized array of signature scheme names that
> 
> If the system properties are set, does it override this API? I think it is important to mention that here in an @implNote. I know you discuss them in `getSignatureSchemes` but I think a developer is more likely to want to know the behavior of the properties for this method especially if they will override this setting.

I though it is a spec of the get method.  But I agree with you that it could be helpful if we have it in the set method as well.  Updated.

> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 761:
> 
>> 759:      * Names Specification.  Providers may support signature schemes not defined
>> 760:      * in this list or may not use the recommended name for a certain
>> 761:      * signature scheme.
> 
> Did you want to say something about what the behavior should be if a provider does not support one of these schemes? Is it ignored, or is an exception thrown?

Just as your suggested in a later comment, an apiNote was added.

> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 762:
> 
>> 760:      * in this list or may not use the recommended name for a certain
>> 761:      * signature scheme.
>> 762:      *
> 
> Regarding my previous comment about providers not supporting these new methods, I think something like the following might suffice:
> 
> 
> @apiNote Note that a provider may not have been updated to support this method and in that case may ignore the schemes that are set.
> @implNote The SunJSSE provider supports this method.

Thank you for the suggestion.  Updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Fri Feb  4 18:26:10 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Feb 2022 18:26:10 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v11]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <hsouJEew8Qk1O50c3hQ6-fDu8hKRW7cZQQsAAsEbIT0=.b4838b02-41c5-485d-952e-7f2b5af0e788@github.com>

> 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

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  Add missed spec, and delete swp file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/9670efbd..70382768

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=09-10

  Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 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

From xuelei at openjdk.java.net  Fri Feb  4 18:33:46 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Feb 2022 18:33:46 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v12]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <mDT2PiGlJjI9ON0BLX_RM3rruD9tz0A96YyrhZ_Fqi0=.974c5df3-b24b-44e5-979e-04c670def94e@github.com>

> 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

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  Correct the set spec

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/70382768..70c3755b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=10-11

  Stats: 2 lines in 1 file changed: 1 ins; 0 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

From xuelei at openjdk.java.net  Fri Feb  4 18:33:49 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Feb 2022 18:33:49 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v9]
In-Reply-To: <tijZT23Eh_Zed15sE4VRdVZl1Bu9ENbiSG5COBcP4bg=.53d2ef0d-0cca-4a95-9f20-2c78b233ef35@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ItkEX9uCQ1fD4HDwsGGElssE8rh-qpAWLf0aj7iQ-MY=.a15b7b8a-2a67-4742-a596-3c4ef5ea0060@github.com>
 <tijZT23Eh_Zed15sE4VRdVZl1Bu9ENbiSG5COBcP4bg=.53d2ef0d-0cca-4a95-9f20-2c78b233ef35@github.com>
Message-ID: <rdmQuVKCSaQdpwVWOMRDy8_lLmks2-i2JiorkgXyljg=.196f61e7-86ed-4635-84d3-2d8dfa1e6a11@github.com>

On Fri, 4 Feb 2022 16:35:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More update for the sec and impl
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 713:
> 
>> 711:      * in this list or may not use the recommended name for a certain
>> 712:      * signature scheme.
>> 713:      * <p>
> 
> Regarding my previous comment about providers not supporting these new methods, I think something like the following might suffice:
> 
> 
> @apiNote Note that a provider may not have been updated to support this method and in that case may return null instead of the default signature schemes for pre-populated objects.
> @implNote The SunJSSE provider supports this method.

It looks like a typo. Replaced "pre-populated objects" with "connection populated objects", and added to the spec.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From hchao at openjdk.java.net  Fri Feb  4 18:42:05 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 4 Feb 2022 18:42:05 GMT
Subject: RFR: 8281175: Add a -providerPath option to jarsigner [v2]
In-Reply-To: <PkNwpEq0iLG-oeroy1to30pHtgxPdnVrF3HioAckdxA=.a6fdb35c-4e30-4c36-ac31-77f19271774d@github.com>
References: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
 <PkNwpEq0iLG-oeroy1to30pHtgxPdnVrF3HioAckdxA=.a6fdb35c-4e30-4c36-ac31-77f19271774d@github.com>
Message-ID: <jVzbmacrZBitFvEs8g_zRQmc3fzjOIV-jaQK_awOOh0=.55e8fd34-df23-4dfd-af30-218f850cbd6e@github.com>

On Thu, 3 Feb 2022 18:32:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add the `-providerPath` option to jarsigner to be consistent with keytool.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to append to null

Marked as reviewed by hchao (Committer).

Updated CSR looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7338

From weijun at openjdk.java.net  Fri Feb  4 19:33:10 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 4 Feb 2022 19:33:10 GMT
Subject: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class
 loader in signed JAR
In-Reply-To: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
References: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
Message-ID: <9rmWfI6hsIf7MiCxJlViM3z75i7JwPsNKUkVZcddAuc=.6a46d675-66b4-4d6a-ba59-df3a464874ad@github.com>

On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This fixes a bootstrapping issue if a custom system class loader is set with the `-Djava.system.class.loader` option and the custom class loader is inside a signed JAR.  In order to load the custom class loader, the runtime must verify the signed JAR first, and the algorithm constraint code tries to load a `Locale` provider using a `ServiceLoader` before the class loader is set, and this causes a `ServiceConfigurationError`.
> 
> The fix removes a dependency from the security algorithm "denyAfter" constraint parsing code on the `Calendar` API which uses a `ServiceLoader` for gathering default locale information. Instead the `ZonedDateTime` API is now used, which simplifies the code and removes some unnecessary code from `keytool` as well.

LGTM.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7316

From hchao at openjdk.java.net  Fri Feb  4 19:38:12 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Fri, 4 Feb 2022 19:38:12 GMT
Subject: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class
 loader in signed JAR
In-Reply-To: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
References: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
Message-ID: <_tI3GPKicRHHrW6sqKsvwMd4RW7fkXhkbLTuk5Qb8Y8=.69f89f58-dce2-4e5f-86f5-2efbd1c922bf@github.com>

On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This fixes a bootstrapping issue if a custom system class loader is set with the `-Djava.system.class.loader` option and the custom class loader is inside a signed JAR.  In order to load the custom class loader, the runtime must verify the signed JAR first, and the algorithm constraint code tries to load a `Locale` provider using a `ServiceLoader` before the class loader is set, and this causes a `ServiceConfigurationError`.
> 
> The fix removes a dependency from the security algorithm "denyAfter" constraint parsing code on the `Calendar` API which uses a `ServiceLoader` for gathering default locale information. Instead the `ZonedDateTime` API is now used, which simplifies the code and removes some unnecessary code from `keytool` as well.

Marked as reviewed by hchao (Committer).

Looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7316

From xuelei at openjdk.java.net  Fri Feb  4 20:58:46 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Feb 2022 20:58:46 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>

> 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

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  correct null tags

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/70c3755b..be947693

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=11-12

  Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 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

From xuelei at openjdk.java.net  Fri Feb  4 23:08:32 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 4 Feb 2022 23:08:32 GMT
Subject: RFR: 8281289: Improve with List.copyOf
Message-ID: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>

Please review this trivial code clean up, for a little bit better performance.

-------------

Commit messages:
 - 8281289: Improve with List.copyOf

Changes: https://git.openjdk.java.net/jdk/pull/7356/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7356&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281289
  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7356.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7356/head:pull/7356

PR: https://git.openjdk.java.net/jdk/pull/7356

From jnimeh at openjdk.java.net  Sat Feb  5 00:16:11 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Sat, 5 Feb 2022 00:16:11 GMT
Subject: RFR: 8281289: Improve with List.copyOf
In-Reply-To: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
References: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
Message-ID: <LvnN33XACc3_k6QAnttVxjYVRsHY-KghoiNnHD3-EbA=.7a496c0c-b6b5-4d47-ab46-bb1732d9e635@github.com>

On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Please review this trivial code clean up, for a little bit better performance.

Looks good to me.

-------------

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7356

From hchao at openjdk.java.net  Sat Feb  5 02:21:12 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Sat, 5 Feb 2022 02:21:12 GMT
Subject: RFR: 8281289: Improve with List.copyOf
In-Reply-To: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
References: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
Message-ID: <ifVnU6RpU_njJCZlFSjSUE3lEXR_vmHNW0uHn9o1S_I=.06b539bf-792e-427b-b141-20a7b443683e@github.com>

On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Please review this trivial code clean up, for a little bit better performance.

Marked as reviewed by hchao (Committer).

Looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7356

From xuelei at openjdk.java.net  Sat Feb  5 07:49:18 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 5 Feb 2022 07:49:18 GMT
Subject: Integrated: 8281289: Improve with List.copyOf
In-Reply-To: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
References: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
Message-ID: <6sMS8ar3Ycy8lizlmln6RJ_rWCl4B0zUKEPywds8PS8=.6cf14dbf-b795-4f63-9030-a016dc66c7a7@github.com>

On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Please review this trivial code clean up, for a little bit better performance.

This pull request has now been integrated.

Changeset: 42e272e1
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42e272e181f188c89fa88f144715f19235943fca
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8281289: Improve with List.copyOf

Reviewed-by: jnimeh, hchao

-------------

PR: https://git.openjdk.java.net/jdk/pull/7356

From jpai at openjdk.java.net  Sat Feb  5 11:51:09 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 5 Feb 2022 11:51:09 GMT
Subject: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class
 loader in signed JAR
In-Reply-To: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
References: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
Message-ID: <RKQxM3uQwShgBFAChiOcMdHcgZnvdOcIzD0s58BJXeU=.021ee2e4-6b0c-409a-8dbc-18b89c167b21@github.com>

On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This fixes a bootstrapping issue if a custom system class loader is set with the `-Djava.system.class.loader` option and the custom class loader is inside a signed JAR.  In order to load the custom class loader, the runtime must verify the signed JAR first, and the algorithm constraint code tries to load a `Locale` provider using a `ServiceLoader` before the class loader is set, and this causes a `ServiceConfigurationError`.
> 
> The fix removes a dependency from the security algorithm "denyAfter" constraint parsing code on the `Calendar` API which uses a `ServiceLoader` for gathering default locale information. Instead the `ZonedDateTime` API is now used, which simplifies the code and removes some unnecessary code from `keytool` as well.

test/jdk/java/security/SignedJar/SignedJarWithCustomClassLoader.java line 65:

> 63: 
> 64:         // create signer's keypair
> 65:         SecurityTools.keytool("-genkeypair -keyalg RSA -keystore ks " +

Hello Sean,
Looking at the `SecurityTools.keytool` and `SecurityTools.jarsigner` methods, they internally launch a process corresponding to these tools but do not check for the exit code of that process execution. Perhaps the calls to these methods in this test, should add a check to assert that the exit code is `0` by using the returned `OutputAnalyzer`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7316

From redestad at openjdk.java.net  Sat Feb  5 13:25:12 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 5 Feb 2022 13:25:12 GMT
Subject: RFR: 8281289: Improve with List.copyOf
In-Reply-To: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
References: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
Message-ID: <7TsJR1VAUZRYopniWdA62B53Zif3V-vELI1PZ2jWgUI=.61c65ef7-872d-4733-b809-f7f53cb844e0@github.com>

On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Please review this trivial code clean up, for a little bit better performance.

There's a small compatibility risk with this change, e.g., `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't.

If we accept that compatibility risk (which should probably be decided by CSR) it might also make sense to use `List.of()` for the empty case, which will reduce the number of List implementation classes returned from the API.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7356

From xuelei at openjdk.java.net  Sat Feb  5 20:34:10 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 5 Feb 2022 20:34:10 GMT
Subject: RFR: 8281289: Improve with List.copyOf
In-Reply-To: <7TsJR1VAUZRYopniWdA62B53Zif3V-vELI1PZ2jWgUI=.61c65ef7-872d-4733-b809-f7f53cb844e0@github.com>
References: <gIZP0vyYcfxn9dSMEXEA4eIm888jqCFuUZI2WSdP7OU=.2a38ac3d-6fdd-4397-9d2e-4ceb97bebcb8@github.com>
 <7TsJR1VAUZRYopniWdA62B53Zif3V-vELI1PZ2jWgUI=.61c65ef7-872d-4733-b809-f7f53cb844e0@github.com>
Message-ID: <-jTrCzKIxs7SZWrvqmtk6OH6PlA9XolGP_LYAQs00ZU=.8fab488c-8a77-4a4f-b9b4-f4b906f43c80@github.com>

On Sat, 5 Feb 2022 13:22:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There's a small compatibility risk with this change, e.g., `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't.
> 
> If we accept that compatibility risk (which should probably be decided by CSR) it might also make sense to use `List.of()` for the empty case, which will reduce the number of List implementation classes returned from the API.

All GOOD points!  Thanks!

I filed a new JDK-8281298, and a new [pull request](https://github.com/openjdk/jdk/pull/7359).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7356

From xuelei at openjdk.java.net  Sat Feb  5 20:36:36 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 5 Feb 2022 20:36:36 GMT
Subject: RFR: 8281298: Revise the creation of unmodifiable list
Message-ID: <xYoMqeidmquw2mWpUyuZQnR36CsZ8qzqllmTPOvM9-Y=.b38f3660-93a2-44d5-b355-3b3e177ae558@github.com>

In [JDK-8281289](https://bugs.openjdk.java.net/browse/JDK-8281289), the SSLParameters class was updated with the patch:

- return Collections.<SNIServerName>unmodifiableList(new ArrayList<>(sniNames.values()));
+ return List.copyOf(sniNames.values());

However, there's a small compatibility risk with this change, `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't. It may be not worthy of the risk although the impact may be minimal.

This update will re-use the Collections.unmodifiableList() methods, but re-org the code for better performance.

-------------

Commit messages:
 - 8281298: Revise the creation of unmodifiable list

Changes: https://git.openjdk.java.net/jdk/pull/7359/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7359&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281298
  Stats: 71 lines in 1 file changed: 18 ins; 25 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7359.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7359/head:pull/7359

PR: https://git.openjdk.java.net/jdk/pull/7359

From mullan at openjdk.java.net  Sun Feb  6 19:51:05 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 6 Feb 2022 19:51:05 GMT
Subject: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class
 loader in signed JAR [v2]
In-Reply-To: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
References: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
Message-ID: <U81FDRhcgZhZol451kjLefo8J7jgd1LfCbsYJ4CkZ1s=.e55e7279-01ee-42cd-85ec-8111042fa1d1@github.com>

> This fixes a bootstrapping issue if a custom system class loader is set with the `-Djava.system.class.loader` option and the custom class loader is inside a signed JAR.  In order to load the custom class loader, the runtime must verify the signed JAR first, and the algorithm constraint code tries to load a `Locale` provider using a `ServiceLoader` before the class loader is set, and this causes a `ServiceConfigurationError`.
> 
> The fix removes a dependency from the security algorithm "denyAfter" constraint parsing code on the `Calendar` API which uses a `ServiceLoader` for gathering default locale information. Instead the `ZonedDateTime` API is now used, which simplifies the code and removes some unnecessary code from `keytool` as well.

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Check exit status of keytool and jarsigner in test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7316/files
  - new: https://git.openjdk.java.net/jdk/pull/7316/files/914c8821..a52e5137

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7316&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7316&range=00-01

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7316.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7316/head:pull/7316

PR: https://git.openjdk.java.net/jdk/pull/7316

From mullan at openjdk.java.net  Sun Feb  6 19:51:05 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 6 Feb 2022 19:51:05 GMT
Subject: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class
 loader in signed JAR [v2]
In-Reply-To: <RKQxM3uQwShgBFAChiOcMdHcgZnvdOcIzD0s58BJXeU=.021ee2e4-6b0c-409a-8dbc-18b89c167b21@github.com>
References: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
 <RKQxM3uQwShgBFAChiOcMdHcgZnvdOcIzD0s58BJXeU=.021ee2e4-6b0c-409a-8dbc-18b89c167b21@github.com>
Message-ID: <SVBUri2XeOCgGs1bH4dB_w39nd1TC3hU9fS6IU9vVNE=.0a07443f-186a-413e-bcfc-9538a7bdf7a6@github.com>

On Sat, 5 Feb 2022 11:48:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check exit status of keytool and jarsigner in test.
>
> test/jdk/java/security/SignedJar/SignedJarWithCustomClassLoader.java line 65:
> 
>> 63: 
>> 64:         // create signer's keypair
>> 65:         SecurityTools.keytool("-genkeypair -keyalg RSA -keystore ks " +
> 
> Hello Sean,
> Looking at the `SecurityTools.keytool` and `SecurityTools.jarsigner` methods, they internally launch a process corresponding to these tools but do not check for the exit code of that process execution. Perhaps the calls to these methods in this test, should add a check to assert that the exit code is `0` by using the returned `OutputAnalyzer`?

Good catch - fixed in latest update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7316

From redestad at openjdk.java.net  Sun Feb  6 22:14:11 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 6 Feb 2022 22:14:11 GMT
Subject: RFR: 8281298: Revise the creation of unmodifiable list
In-Reply-To: <xYoMqeidmquw2mWpUyuZQnR36CsZ8qzqllmTPOvM9-Y=.b38f3660-93a2-44d5-b355-3b3e177ae558@github.com>
References: <xYoMqeidmquw2mWpUyuZQnR36CsZ8qzqllmTPOvM9-Y=.b38f3660-93a2-44d5-b355-3b3e177ae558@github.com>
Message-ID: <cH6UcWnD5-CftRqYyIQkdAZzgbNWTi_7JFDb4-dI8FE=.8a121f1c-872b-4cd7-b01c-9662fb29b340@github.com>

On Sat, 5 Feb 2022 20:29:50 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In [JDK-8281289](https://bugs.openjdk.java.net/browse/JDK-8281289), the SSLParameters class was updated with the patch:
> 
> - return Collections.<SNIServerName>unmodifiableList(new ArrayList<>(sniNames.values()));
> + return List.copyOf(sniNames.values());
> 
> However, there's a small compatibility risk with this change, `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't. It may be not worthy of the risk although the impact may be minimal.
> 
> This update will re-use the Collections.unmodifiableList() methods, but re-org the code for better performance.

This looks like an appropriate solution which avoids the minor compatibility risk introduced by the previous change - and you might even end up being more efficient both when setting and reading the names/matchers. 

(Since we're going down the route of optimizing this: the `type` of a `SNIServerName` is constrained to a value between 0 and 255, so there's likely a small micro-optimization opportunity in using a `BitSet` for the duplicate checking rather a `ArrayList<Integer>`.. A `BitSet(256)` should have lower memory use and the existence check will run in O(1) instead of O(n) time. Might not be worthwhile to optimize these setters, though..)

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7359

From jpai at openjdk.java.net  Mon Feb  7 03:29:05 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 7 Feb 2022 03:29:05 GMT
Subject: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class
 loader in signed JAR [v2]
In-Reply-To: <U81FDRhcgZhZol451kjLefo8J7jgd1LfCbsYJ4CkZ1s=.e55e7279-01ee-42cd-85ec-8111042fa1d1@github.com>
References: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
 <U81FDRhcgZhZol451kjLefo8J7jgd1LfCbsYJ4CkZ1s=.e55e7279-01ee-42cd-85ec-8111042fa1d1@github.com>
Message-ID: <AUuCAe-fQUK2B2tI0aoZYw1VTqSqbeD20fhJ4Jpcgsc=.18671fb5-14fe-48ef-93f2-bd1a2908d861@github.com>

On Sun, 6 Feb 2022 19:51:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This fixes a bootstrapping issue if a custom system class loader is set with the `-Djava.system.class.loader` option and the custom class loader is inside a signed JAR.  In order to load the custom class loader, the runtime must verify the signed JAR first, and the algorithm constraint code tries to load a `Locale` provider using a `ServiceLoader` before the class loader is set, and this causes a `ServiceConfigurationError`.
>> 
>> The fix removes a dependency from the security algorithm "denyAfter" constraint parsing code on the `Calendar` API which uses a `ServiceLoader` for gathering default locale information. Instead the `ZonedDateTime` API is now used, which simplifies the code and removes some unnecessary code from `keytool` as well.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit status of keytool and jarsigner in test.

Thank you for that change, Sean. Looks fine to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7316

From xuelei at openjdk.java.net  Mon Feb  7 05:52:06 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Feb 2022 05:52:06 GMT
Subject: RFR: 8281298: Revise the creation of unmodifiable list
In-Reply-To: <cH6UcWnD5-CftRqYyIQkdAZzgbNWTi_7JFDb4-dI8FE=.8a121f1c-872b-4cd7-b01c-9662fb29b340@github.com>
References: <xYoMqeidmquw2mWpUyuZQnR36CsZ8qzqllmTPOvM9-Y=.b38f3660-93a2-44d5-b355-3b3e177ae558@github.com>
 <cH6UcWnD5-CftRqYyIQkdAZzgbNWTi_7JFDb4-dI8FE=.8a121f1c-872b-4cd7-b01c-9662fb29b340@github.com>
Message-ID: <xDNLuz7hIMq5sQBn8qf_6r7S76v-ETcON2n_iU3bR64=.413fb58b-c115-4e20-a2ac-11a6c5454c70@github.com>

On Sun, 6 Feb 2022 22:11:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This looks like an appropriate solution which avoids the minor compatibility risk introduced by the previous change - and you might even end up being more efficient both when setting and reading the names/matchers.
> 
> (Since we're going down the route of optimizing this: the `type` of a `SNIServerName` is constrained to a value between 0 and 255, so there's likely a small micro-optimization opportunity in using a `BitSet` for the duplicate checking rather a `ArrayList<Integer>`.. A `BitSet(256)` should have lower memory use and the existence check will run in O(1) instead of O(n) time. Might not be worthwhile to optimize these setters, though..)

Thank you for the quick review.  As the number of SNIServerName is normally one in practice, I'm not very sure of the improvement to use BitSet yet.  But I'm glad to know the BitSet could be a better choice if the items number goes beyond 4.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7359

From xuelei at openjdk.java.net  Mon Feb  7 06:33:11 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Feb 2022 06:33:11 GMT
Subject: Integrated: 8281298: Revise the creation of unmodifiable list
In-Reply-To: <xYoMqeidmquw2mWpUyuZQnR36CsZ8qzqllmTPOvM9-Y=.b38f3660-93a2-44d5-b355-3b3e177ae558@github.com>
References: <xYoMqeidmquw2mWpUyuZQnR36CsZ8qzqllmTPOvM9-Y=.b38f3660-93a2-44d5-b355-3b3e177ae558@github.com>
Message-ID: <tpVhr2pOfaAjwGDSgIu-mnwV9anoiaqQUCWLTZXvCEw=.f714d421-49c5-420e-8fdb-917345d4762e@github.com>

On Sat, 5 Feb 2022 20:29:50 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In [JDK-8281289](https://bugs.openjdk.java.net/browse/JDK-8281289), the SSLParameters class was updated with the patch:
> 
> - return Collections.<SNIServerName>unmodifiableList(new ArrayList<>(sniNames.values()));
> + return List.copyOf(sniNames.values());
> 
> However, there's a small compatibility risk with this change, `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't. It may be not worthy of the risk although the impact may be minimal.
> 
> This update will re-use the Collections.unmodifiableList() methods, but re-org the code for better performance.

This pull request has now been integrated.

Changeset: f2302822
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f2302822c0ef30fbf7cb4e31b8dc1513e9413a23
Stats:     71 lines in 1 file changed: 18 ins; 25 del; 28 mod

8281298: Revise the creation of unmodifiable list

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/7359

From mullan at openjdk.java.net  Mon Feb  7 14:10:13 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Feb 2022 14:10:13 GMT
Subject: Integrated: 8280890: Cannot use '-Djava.system.class.loader' with
 class loader in signed JAR
In-Reply-To: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
References: <jtxgjOIKJGNx0pknyNvp5I-usGgGjltnyjTgsUJtm00=.f75c5956-bd6f-41f3-83fe-a0d8ccb9b4fb@github.com>
Message-ID: <vcQoNT9PiA5V70PvRj6zYL3wFyU_7Caj3xzlJMUeIuU=.ff0349fd-58b5-4739-889b-9ddc63285b96@github.com>

On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This fixes a bootstrapping issue if a custom system class loader is set with the `-Djava.system.class.loader` option and the custom class loader is inside a signed JAR.  In order to load the custom class loader, the runtime must verify the signed JAR first, and the algorithm constraint code tries to load a `Locale` provider using a `ServiceLoader` before the class loader is set, and this causes a `ServiceConfigurationError`.
> 
> The fix removes a dependency from the security algorithm "denyAfter" constraint parsing code on the `Calendar` API which uses a `ServiceLoader` for gathering default locale information. Instead the `ZonedDateTime` API is now used, which simplifies the code and removes some unnecessary code from `keytool` as well.

This pull request has now been integrated.

Changeset: a0f6f240
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a0f6f2409ea61ff9ed9dc2e2b46e309c751d456d
Stats:     186 lines in 4 files changed: 142 ins; 28 del; 16 mod

8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR

Reviewed-by: weijun, hchao

-------------

PR: https://git.openjdk.java.net/jdk/pull/7316

From weijun at openjdk.java.net  Mon Feb  7 15:09:10 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 7 Feb 2022 15:09:10 GMT
Subject: Integrated: 8281175: Add a -providerPath option to jarsigner
In-Reply-To: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
References: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>
Message-ID: <PVXPU7SXAx_sgSG42jw-M7A8rFGciswpNpHYYaPqcV4=.7d234cef-1b66-4640-84dc-9b7f7281151a@github.com>

On Thu, 3 Feb 2022 17:12:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add the `-providerPath` option to jarsigner to be consistent with keytool.

This pull request has now been integrated.

Changeset: 2ed1f4cf
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2ed1f4cf32b1cef4ccb129d622f9368c3469d1d4
Stats:     40 lines in 4 files changed: 22 ins; 7 del; 11 mod

8281175: Add a -providerPath option to jarsigner

Reviewed-by: xuelei, hchao

-------------

PR: https://git.openjdk.java.net/jdk/pull/7338

From mullan at openjdk.java.net  Mon Feb  7 15:20:12 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Feb 2022 15:20:12 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <TiIB4oeKaIj_4fCqw8-bMvFSp9gfVzk177CaUVHyWrs=.20710b05-93c4-4f73-99d5-9abb0741914a@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <FZEhhAgnMfwGuyLCbvemF8yQ7CtnnrT08LMMZBz6uag=.90153883-8187-4c85-9635-d81dc9dcc963@github.com>
 <TiIB4oeKaIj_4fCqw8-bMvFSp9gfVzk177CaUVHyWrs=.20710b05-93c4-4f73-99d5-9abb0741914a@github.com>
Message-ID: <ob-uYJrvM40z1nd_OgGwyJuQiy5mPBjdqYSDCLtzEp8=.00b5932a-4f7a-4e92-8ffa-29f00fe165c5@github.com>

On Fri, 4 Feb 2022 15:19:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarFile.java line 866:
>> 
>>> 864:         } catch (Exception e2) {
>>> 865:             // Any other Exception should be a ZipException
>>> 866:             throw (ZipException) new ZipException("Zip file format error").initCause(e2);
>> 
>> If there is ZIP format error then I would expect ZipException or the more general IOException is already thrown. So I think this is catching other cases, maybe broken manifests or signed JAR files, in which case a JarException may be better.
>
> JarFile::getInputStream. mentions ZipException but not JarException which is why I chose this.  If we change this to JarException, I would need to update the javadoc and create a CSR.
> 
> Please let me know your preference

`JarException` is a subclass of `ZipException` though, so I think this would be ok to throw and still be compliant with the specification.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Mon Feb  7 16:55:10 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Feb 2022 16:55:10 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <ob-uYJrvM40z1nd_OgGwyJuQiy5mPBjdqYSDCLtzEp8=.00b5932a-4f7a-4e92-8ffa-29f00fe165c5@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <FZEhhAgnMfwGuyLCbvemF8yQ7CtnnrT08LMMZBz6uag=.90153883-8187-4c85-9635-d81dc9dcc963@github.com>
 <TiIB4oeKaIj_4fCqw8-bMvFSp9gfVzk177CaUVHyWrs=.20710b05-93c4-4f73-99d5-9abb0741914a@github.com>
 <ob-uYJrvM40z1nd_OgGwyJuQiy5mPBjdqYSDCLtzEp8=.00b5932a-4f7a-4e92-8ffa-29f00fe165c5@github.com>
Message-ID: <Xa5ku8xJPdILDpBNYisdAA-LCDN3wwYxY1xI2CsU-jU=.a39cee43-4f7a-446e-942f-33c7ff3b21e1@github.com>

On Mon, 7 Feb 2022 15:16:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> JarFile::getInputStream. mentions ZipException but not JarException which is why I chose this.  If we change this to JarException, I would need to update the javadoc and create a CSR.
>> 
>> Please let me know your preference
>
> `JarException` is a subclass of `ZipException` though, so I think this would be ok to throw and still be compliant with the specification.

Looking at this a bit more,  it looks like `JariFile::initializeVerifier` is the only place currently in `JarFile` that could throw a `JarException` and that method could be called from `JarFile::getInputStream`

As `verifiableEntry` is only called from `JarFile::getInputStream `and this change validates the `ZipEntry` for being null, which is should,  the only other possible error would be in the unlikely event. `ZipEntry` was subclassed passed into `JarFile::getInputStream` resulting in the call to `ZipEntry::getName` returning null(in which case `ZipFile::getEntry` will return a `NullPointerException`) or the name being invalid resulting once again in a possible null value for the returned `ZipEntry` from `JarFile::getJarEntry` (which calls `ZipFile::getEntry`)


I am still leaning towards a `ZipException`, not a `JarException`, thrown from `verifiableEntry`.

That being said, I will go with whatever the consensus is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Mon Feb  7 18:47:09 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Feb 2022 18:47:09 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <Xa5ku8xJPdILDpBNYisdAA-LCDN3wwYxY1xI2CsU-jU=.a39cee43-4f7a-446e-942f-33c7ff3b21e1@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <FZEhhAgnMfwGuyLCbvemF8yQ7CtnnrT08LMMZBz6uag=.90153883-8187-4c85-9635-d81dc9dcc963@github.com>
 <TiIB4oeKaIj_4fCqw8-bMvFSp9gfVzk177CaUVHyWrs=.20710b05-93c4-4f73-99d5-9abb0741914a@github.com>
 <ob-uYJrvM40z1nd_OgGwyJuQiy5mPBjdqYSDCLtzEp8=.00b5932a-4f7a-4e92-8ffa-29f00fe165c5@github.com>
 <Xa5ku8xJPdILDpBNYisdAA-LCDN3wwYxY1xI2CsU-jU=.a39cee43-4f7a-446e-942f-33c7ff3b21e1@github.com>
Message-ID: <S3jp1OqAvAM4SUp-gNsx7BTXuTsBBr2M5u-Q4J7Tq8c=.f61b16ed-b837-49b0-a4cb-7e703b33458c@github.com>

On Mon, 7 Feb 2022 16:52:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> `JarException` is a subclass of `ZipException` though, so I think this would be ok to throw and still be compliant with the specification.
>
> Looking at this a bit more,  it looks like `JariFile::initializeVerifier` is the only place currently in `JarFile` that could throw a `JarException` and that method could be called from `JarFile::getInputStream`
> 
> As `verifiableEntry` is only called from `JarFile::getInputStream `and this change validates the `ZipEntry` for being null, which is should,  the only other possible error would be in the unlikely event. `ZipEntry` was subclassed passed into `JarFile::getInputStream` resulting in the call to `ZipEntry::getName` returning null(in which case `ZipFile::getEntry` will return a `NullPointerException`) or the name being invalid resulting once again in a possible null value for the returned `ZipEntry` from `JarFile::getJarEntry` (which calls `ZipFile::getEntry`)
> 
> 
> I am still leaning towards a `ZipException`, not a `JarException`, thrown from `verifiableEntry`.
> 
> That being said, I will go with whatever the consensus is.

If you are pretty sure the only other case are as above, I wonder if a simpler fix would be to change `verifiableEntry()` to check for these null cases and throw a `ZipException` which will get directly propagated by `getInputStream()`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Mon Feb  7 20:03:14 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Feb 2022 20:03:14 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
Message-ID: <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>

On Fri, 4 Feb 2022 20:58:46 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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 null tags

Changes requested by mullan (Reviewer).

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 47:

> 45:  * <p>
> 46:  * SSLParameters can be created via the constructors in this class.
> 47:  * Objects can also be obtained using the {@code getSSLParameters()}

Since you introduce the terms "pre-populated" and "connection populated" in the new methods, I think it would be useful to describe them up front in the summary, ex:

`{@code SSLParameter} objects can be created via the constructors in this class, and can be described as pre-populated objects. {@code SSLParameter} objects can also be obtained using the ... <list all the methods>, and can be described as connection populated objects."

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 744:

> 742:      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
> 743:      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
> 744:      * customize the provider-specific default signature schemes.

This still doesn't say if the properties override the API. I would suggest adding a sentence: "If set, these properties will override the signature schemes returned by this method."

Similar comment in `setSignatureSchemes`.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 747:

> 745:      *
> 746:      * @return an array of signature scheme {@code Strings} or {@code null} if
> 747:      *         none have been set.  For non-null returns, this method willu

Typo, s/willu/will/

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From lancea at openjdk.java.net  Mon Feb  7 20:20:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Feb 2022 20:20:05 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName()
In-Reply-To: <S3jp1OqAvAM4SUp-gNsx7BTXuTsBBr2M5u-Q4J7Tq8c=.f61b16ed-b837-49b0-a4cb-7e703b33458c@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <FZEhhAgnMfwGuyLCbvemF8yQ7CtnnrT08LMMZBz6uag=.90153883-8187-4c85-9635-d81dc9dcc963@github.com>
 <TiIB4oeKaIj_4fCqw8-bMvFSp9gfVzk177CaUVHyWrs=.20710b05-93c4-4f73-99d5-9abb0741914a@github.com>
 <ob-uYJrvM40z1nd_OgGwyJuQiy5mPBjdqYSDCLtzEp8=.00b5932a-4f7a-4e92-8ffa-29f00fe165c5@github.com>
 <Xa5ku8xJPdILDpBNYisdAA-LCDN3wwYxY1xI2CsU-jU=.a39cee43-4f7a-446e-942f-33c7ff3b21e1@github.com>
 <S3jp1OqAvAM4SUp-gNsx7BTXuTsBBr2M5u-Q4J7Tq8c=.f61b16ed-b837-49b0-a4cb-7e703b33458c@github.com>
Message-ID: <4Z4KMKwU2HO_ZDgoDG0maJaYDyr-NYxyN413b0Ipxjw=.bbb8869b-dfeb-4b13-9384-cc54dfce268b@github.com>

On Mon, 7 Feb 2022 18:44:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Looking at this a bit more,  it looks like `JariFile::initializeVerifier` is the only place currently in `JarFile` that could throw a `JarException` and that method could be called from `JarFile::getInputStream`
>> 
>> As `verifiableEntry` is only called from `JarFile::getInputStream `and this change validates the `ZipEntry` for being null, which is should,  the only other possible error would be in the unlikely event. `ZipEntry` was subclassed passed into `JarFile::getInputStream` resulting in the call to `ZipEntry::getName` returning null(in which case `ZipFile::getEntry` will return a `NullPointerException`) or the name being invalid resulting once again in a possible null value for the returned `ZipEntry` from `JarFile::getJarEntry` (which calls `ZipFile::getEntry`)
>> 
>> 
>> I am still leaning towards a `ZipException`, not a `JarException`, thrown from `verifiableEntry`.
>> 
>> That being said, I will go with whatever the consensus is.
>
> If you are pretty sure the only other case are as above, I wonder if a simpler fix would be to change `verifiableEntry()` to check for these null cases and throw a `ZipException` which will get directly propagated by `getInputStream()`?

I can certainly throw a ZipException from `verifiableEntry`. I am a bit reluctant to not catch any other `Exception` and then throw a `ZipException` from `getInputStream()` as it is certainly possible of encountering some other issue due to some stray value in the CEN.

So I will update `verifiableEntry` to validate `ZipEntry` and` ZipEntry::getName()` potential issues

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From xuelei at openjdk.java.net  Mon Feb  7 22:03:19 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Feb 2022 22:03:19 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
Message-ID: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>

On Mon, 7 Feb 2022 19:51:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correct null tags
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 744:
> 
>> 742:      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>> 743:      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>> 744:      * customize the provider-specific default signature schemes.
> 
> This still doesn't say if the properties override the API. I would suggest adding a sentence: "If set, these properties will override the signature schemes returned by this method."
> 
> Similar comment in `setSignatureSchemes`.

I think lines 714-816/723-725 describe the behavior already.

I was hesitate to use "override", as the System Property values and the default signature schemes are not actually overrode.  The default signature schemes are still there, and they are not just used for this specific connection, when the connection use the non-default values.

It might be something like, "If the returned array of this method is not {@code null} or empty, the default signature schemes are not used, and signature schemes in the returned array of this method will be used instead".  But I think it is a duplicate of lines 714-816/723-725 .

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Mon Feb  7 22:15:54 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Feb 2022 22:15:54 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v14]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <HOY3WI9E1s6k1m2TMpUHn5Zb41lz-wI2JWXk4qSA54Q=.7808a7c6-4ac0-42ac-a9cb-4c318e5195b7@github.com>

> 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:

  Update class summary

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/be947693..8302c592

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=12-13

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 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

From xuelei at openjdk.java.net  Mon Feb  7 22:24:11 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Feb 2022 22:24:11 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
Message-ID: <d5c65EGU29-zFDOHi7rveg7qabQCQt6I8wI9836xVck=.b53170b6-83ae-4175-b550-87bcebb38601@github.com>

On Mon, 7 Feb 2022 19:59:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correct null tags
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 47:
> 
>> 45:  * <p>
>> 46:  * SSLParameters can be created via the constructors in this class.
>> 47:  * Objects can also be obtained using the {@code getSSLParameters()}
> 
> Since you introduce the terms "pre-populated" and "connection populated" in the new methods, I think it would be useful to describe them up front in the summary, ex:
> 
> `{@code SSLParameter} objects can be created via the constructors in this class, and can be described as pre-populated objects. {@code SSLParameter} objects can also be obtained using the ... <list all the methods>, and can be described as connection populated objects."

Nice!  It is something I want to add for quite a while, but never get a chance.  The suggested description is really simple and great!

Updated!

> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 747:
> 
>> 745:      *
>> 746:      * @return an array of signature scheme {@code Strings} or {@code null} if
>> 747:      *         none have been set.  For non-null returns, this method willu
> 
> Typo, s/willu/will/

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From mullan at openjdk.java.net  Mon Feb  7 22:24:12 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Feb 2022 22:24:12 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
 <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>
Message-ID: <VaoboQauDvyeErq1uQ2T9ZoYJfWdoBoConxHC5vfuJw=.cec74dd9-3e6e-4fb4-889e-aafbdcf96cf4@github.com>

On Mon, 7 Feb 2022 22:00:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 744:
>> 
>>> 742:      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>>> 743:      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>>> 744:      * customize the provider-specific default signature schemes.
>> 
>> This still doesn't say if the properties override the API. I would suggest adding a sentence: "If set, these properties will override the signature schemes returned by this method."
>> 
>> Similar comment in `setSignatureSchemes`.
>
> I think lines 714-816/723-725 describe the behavior already.
> 
> I was hesitate to use "override", as the System Property values and the default signature schemes are not actually overrode.  The default signature schemes are still there, and they are not just used for this specific connection, when the connection use the non-default values.
> 
> It might be something like, "If the returned array of this method is not {@code null} or empty, the default signature schemes are not used, and signature schemes in the returned array of this method will be used instead".  But I think it is a duplicate of lines 714-816/723-725 .

Sorry, you will have to bear with me as I am still not sure how it works - I want to know who wins, the API or the properties, if both are set and I can't find where it answers that above. Maybe I need to read the code. Are you maybe saying that this method returns the value of the system properties if they are set?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Mon Feb  7 23:01:11 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Feb 2022 23:01:11 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <VaoboQauDvyeErq1uQ2T9ZoYJfWdoBoConxHC5vfuJw=.cec74dd9-3e6e-4fb4-889e-aafbdcf96cf4@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
 <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>
 <VaoboQauDvyeErq1uQ2T9ZoYJfWdoBoConxHC5vfuJw=.cec74dd9-3e6e-4fb4-889e-aafbdcf96cf4@github.com>
Message-ID: <yude3erR_j09o2sux8u5kGbMlTjt3f7ozrfZAnyEHlY=.a262f389-9735-474b-adda-750462285a2d@github.com>

On Mon, 7 Feb 2022 22:18:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I think lines 714-816/723-725 describe the behavior already.
>> 
>> I was hesitate to use "override", as the System Property values and the default signature schemes are not actually overrode.  The default signature schemes are still there, and they are not just used for this specific connection, when the connection use the non-default values.
>> 
>> It might be something like, "If the returned array of this method is not {@code null} or empty, the default signature schemes are not used, and signature schemes in the returned array of this method will be used instead".  But I think it is a duplicate of lines 714-816/723-725 .
>
> Sorry, you will have to bear with me as I am still not sure how it works - I want to know who wins, the API or the properties, if both are set and I can't find where it answers that above. Maybe I need to read the code. Are you maybe saying that this method returns the value of the system properties if they are set?

> "If set, these properties will override the signature schemes returned by this method."

If I understand your ideas correctly, the behavior should be "the returned value of this method will override these properties", except the case if the returned value is null.

But let me trying  if I could understand the spec by myself.

For the getSignatureSchemes() method's spec:

     * If the returned array is {@code null}, then the underlying
     * provider-specific default signature schemes will be used over the
     * SSL/TLS/DTLS connections.

With the spec above, the API getSignatureSchemes() returns null, and the provider-specific default signature schemes will be used for the connection.  As the properties could be used to customize the default signature schemes, the properties wins in this situation for your question.  However, I would like to express that the default signature schemes win (See bellow about why I don't want to use the properties).


     * If the returned array is empty (zero-length), then the signature scheme
     * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
     * the connections may not be able to be established if the negotiation
     * mechanism is required by a certain SSL/TLS/DTLS protocol.

With the spec above, the API getSignatureSchemes() returns empty array, and no signature schemes will be used.  The API wins, the default signature schemes are not used.


     * <p>
     * If the returned array is not {@code null} or empty (zero-length),
     * then the signature schemes in the returned array will be used over
     * the SSL/TLS/DTLS connections.

With the spec above, the API getSignatureSchemes() returns non-null and non-empty, and the returned array will be used.  The API wins, the default signature schemes are not used.


     * @implNote
     * Note that the underlying provider may define the default signature
     * schemes for each SSL/TLS/DTLS connection.  Applications may also use
     * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
     * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
     * customize the provider-specific default signature schemes.

With the spec above, I could understand what are the default signature schemes, and how they could be customized with properties.

So back to my question above, why I don't want to use the properties, and use the default signature schemes instead?  We need to take care of three things: the properties, the API set values and the provider default values.  If I use the properties values, I would have to describe the provider default values as well.  As the properties values are used to set the provider default values, it should be sufficient to use the provider default values for the description in this context.

What if both the properties and the APIs are set?  The properties are used to set the provider default values, and the properties will change the  provider default values.  So we only need to consider the provider default values and the API, then I think we can refer to the 3 spec sections before the @implNote tag above.  Simply, if both set, the API wins.

Similar to the set method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From lancea at openjdk.java.net  Mon Feb  7 23:02:54 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Feb 2022 23:02:54 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Reduce Exception checking to JarFile::verifiableEntry

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7348/files
  - new: https://git.openjdk.java.net/jdk/pull/7348/files/b50ebf05..6c75384a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=00-01

  Stats: 162 lines in 3 files changed: 90 ins; 21 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Mon Feb  7 23:11:07 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Feb 2022 23:11:07 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <4Z4KMKwU2HO_ZDgoDG0maJaYDyr-NYxyN413b0Ipxjw=.bbb8869b-dfeb-4b13-9384-cc54dfce268b@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <FZEhhAgnMfwGuyLCbvemF8yQ7CtnnrT08LMMZBz6uag=.90153883-8187-4c85-9635-d81dc9dcc963@github.com>
 <TiIB4oeKaIj_4fCqw8-bMvFSp9gfVzk177CaUVHyWrs=.20710b05-93c4-4f73-99d5-9abb0741914a@github.com>
 <ob-uYJrvM40z1nd_OgGwyJuQiy5mPBjdqYSDCLtzEp8=.00b5932a-4f7a-4e92-8ffa-29f00fe165c5@github.com>
 <Xa5ku8xJPdILDpBNYisdAA-LCDN3wwYxY1xI2CsU-jU=.a39cee43-4f7a-446e-942f-33c7ff3b21e1@github.com>
 <S3jp1OqAvAM4SUp-gNsx7BTXuTsBBr2M5u-Q4J7Tq8c=.f61b16ed-b837-49b0-a4cb-7e703b33458c@github.com>
 <4Z4KMKwU2HO_ZDgoDG0maJaYDyr-NYxyN413b0Ipxjw=.bbb8869b-dfeb-4b13-9384-cc54dfce268b@github.com>
Message-ID: <WYn9kttT6y92Z-pIfr7TmHYzoRs4wE_2hOJnTt-XtEY=.35b47be8-4539-4fee-be76-3bb4a9c67a51@github.com>

On Mon, 7 Feb 2022 20:16:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> If you are pretty sure the only other case are as above, I wonder if a simpler fix would be to change `verifiableEntry()` to check for these null cases and throw a `ZipException` which will get directly propagated by `getInputStream()`?
>
> I can certainly throw a ZipException from `verifiableEntry`. I am a bit reluctant to not catch any other `Exception` and then throw a `ZipException` from `getInputStream()` as it is certainly possible of encountering some other issue due to some stray value in the CEN.
> 
> So I will update `verifiableEntry` to validate `ZipEntry` and` ZipEntry::getName()` potential issues

Per an offline-discussion with Sean, I narrowed the Exception checking to JarFile::verifiableEntry.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From xuelei at openjdk.java.net  Mon Feb  7 23:16:09 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Feb 2022 23:16:09 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <yude3erR_j09o2sux8u5kGbMlTjt3f7ozrfZAnyEHlY=.a262f389-9735-474b-adda-750462285a2d@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
 <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>
 <VaoboQauDvyeErq1uQ2T9ZoYJfWdoBoConxHC5vfuJw=.cec74dd9-3e6e-4fb4-889e-aafbdcf96cf4@github.com>
 <yude3erR_j09o2sux8u5kGbMlTjt3f7ozrfZAnyEHlY=.a262f389-9735-474b-adda-750462285a2d@github.com>
Message-ID: <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com>

On Mon, 7 Feb 2022 22:56:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Sorry, you will have to bear with me as I am still not sure how it works - I want to know who wins, the API or the properties, if both are set and I can't find where it answers that above. Maybe I need to read the code. Are you maybe saying that this method returns the value of the system properties if they are set?
>
>> "If set, these properties will override the signature schemes returned by this method."
> 
> If I understand your ideas correctly, the behavior should be "the returned value of this method will override these properties", except the case if the returned value is null.
> 
> But let me trying  if I could understand the spec by myself.
> 
> For the getSignatureSchemes() method's spec:
> 
>      * If the returned array is {@code null}, then the underlying
>      * provider-specific default signature schemes will be used over the
>      * SSL/TLS/DTLS connections.
> 
> With the spec above, the API getSignatureSchemes() returns null, and the provider-specific default signature schemes will be used for the connection.  As the properties could be used to customize the default signature schemes, the properties wins in this situation for your question.  However, I would like to express that the default signature schemes win (See bellow about why I don't want to use the properties).
> 
> 
>      * If the returned array is empty (zero-length), then the signature scheme
>      * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
>      * the connections may not be able to be established if the negotiation
>      * mechanism is required by a certain SSL/TLS/DTLS protocol.
> 
> With the spec above, the API getSignatureSchemes() returns empty array, and no signature schemes will be used.  The API wins, the default signature schemes are not used.
> 
> 
>      * <p>
>      * If the returned array is not {@code null} or empty (zero-length),
>      * then the signature schemes in the returned array will be used over
>      * the SSL/TLS/DTLS connections.
> 
> With the spec above, the API getSignatureSchemes() returns non-null and non-empty, and the returned array will be used.  The API wins, the default signature schemes are not used.
> 
> 
>      * @implNote
>      * Note that the underlying provider may define the default signature
>      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>      * customize the provider-specific default signature schemes.
> 
> With the spec above, I could understand what are the default signature schemes, and how they could be customized with properties.
> 
> So back to my question above, why I don't want to use the properties, and use the default signature schemes instead?  We need to take care of three things: the properties, the API set values and the provider default values.  If I use the properties values, I would have to describe the provider default values as well.  As the properties values are used to set the provider default values, it should be sufficient to use the provider default values for the description in this context.
> 
> What if both the properties and the APIs are set?  The properties are used to set the provider default values, and the properties will change the  provider default values.  So we only need to consider the provider default values and the API, then I think we can refer to the 3 spec sections before the @implNote tag above.  Simply, if both set, the API wins.
> 
> Similar to the set method.
> 
> Please let me know if you are on the same page as well.  I am open to make more changes if the spec is still not clear.

> Are you maybe saying that this method returns the value of the system properties if they are set?

The return value of this method depends on the following specs:

     * If the {@link #setSignatureSchemes} method has not been called, this
     * method should return the default signature schemes for connection
     * populated objects, or {@code null} for pre-populated objects.
``` 

If the setSignatureSchemes() method has been called, the get method will return the set values.  I may miss this spec.  But I think it is a common sense that the getter method returns the values set with setter method.  Let me know if you would like to have an explicit clarification in the spec.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From mullan at openjdk.java.net  Tue Feb  8 15:41:21 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 8 Feb 2022 15:41:21 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
Message-ID: <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>

On Mon, 7 Feb 2022 23:02:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the attached patch to address
>> 
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
>> 
>> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce Exception checking to JarFile::verifiableEntry

Marked as reviewed by mullan (Reviewer).

src/java.base/share/classes/java/util/jar/JarFile.java line 871:

> 869:         }
> 870:         // ZipEntry::getName should not return null
> 871:         if(ze.getName() != null) {

Nit, add space after "if"

src/java.base/share/classes/java/util/jar/JarFile.java line 874:

> 872:             ze = getJarEntry(ze.getName());
> 873:         } else {
> 874:             throw new ZipException("Error: ZipEntry::getName returned null!");

I'd probably leave out the "Error:" and the "!".

src/java.base/share/classes/java/util/jar/JarFile.java line 877:

> 875:         }
> 876:         // ZipEntry returned from JarFile::getJarEntry should not be null
> 877:         if(ze == null) {

Nit, add space after "if"

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From alanb at openjdk.java.net  Tue Feb  8 16:02:11 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Feb 2022 16:02:11 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
Message-ID: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>

On Tue, 8 Feb 2022 15:27:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce Exception checking to JarFile::verifiableEntry
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 871:
> 
>> 869:         }
>> 870:         // ZipEntry::getName should not return null
>> 871:         if(ze.getName() != null) {
> 
> Nit, add space after "if"

if ZipEntry is extended and getName() overridden then you can't trust the name. So I think you'll have extract the name rather than calling ZipEntry::getName twice. I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry is null.

> src/java.base/share/classes/java/util/jar/JarFile.java line 877:
> 
>> 875:         }
>> 876:         // ZipEntry returned from JarFile::getJarEntry should not be null
>> 877:         if(ze == null) {
> 
> Nit, add space after "if"

ze can't be null here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Tue Feb  8 16:18:05 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 8 Feb 2022 16:18:05 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
Message-ID: <MWm-pkAiwXJvibYK-JdpuDAVDRxY8RRpF0Mvg3ACq9Y=.45c002da-7a51-4910-bb5d-68b400668bbe@github.com>

On Tue, 8 Feb 2022 15:57:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarFile.java line 871:
>> 
>>> 869:         }
>>> 870:         // ZipEntry::getName should not return null
>>> 871:         if(ze.getName() != null) {
>> 
>> Nit, add space after "if"
>
> if ZipEntry is extended and getName() overridden then you can't trust the name. So I think you'll have extract the name rather than calling ZipEntry::getName twice. I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null.

Ah, yes - good catch!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From hchao at openjdk.java.net  Tue Feb  8 17:20:34 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Feb 2022 17:20:34 GMT
Subject: RFR: 8265765: DomainKeyStore may stop enumerating aliases if a
 constituting KeyStore is empty
Message-ID: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>

This is to fix `DomainKeyStore::engineAliases` to take into account that there may be empty keystore(s) within the collection of keystores of a domain keystore.

-------------

Commit messages:
 - 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty

Changes: https://git.openjdk.java.net/jdk/pull/7386/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7386&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265765
  Stats: 128 lines in 2 files changed: 121 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7386.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7386/head:pull/7386

PR: https://git.openjdk.java.net/jdk/pull/7386

From lancea at openjdk.java.net  Tue Feb  8 18:15:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 8 Feb 2022 18:15:05 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <MWm-pkAiwXJvibYK-JdpuDAVDRxY8RRpF0Mvg3ACq9Y=.45c002da-7a51-4910-bb5d-68b400668bbe@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <MWm-pkAiwXJvibYK-JdpuDAVDRxY8RRpF0Mvg3ACq9Y=.45c002da-7a51-4910-bb5d-68b400668bbe@github.com>
Message-ID: <p-NSARSjUmZEmQjUnlpcVjgnvbHb2RQhcxilqi6jhgk=.9653e7ad-f41d-4f42-b596-c36786c28bc6@github.com>

On Tue, 8 Feb 2022 16:15:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> if ZipEntry is extended and getName() overridden then you can't trust the name. So I think you'll have extract the name rather than calling ZipEntry::getName twice. I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null.
>
> Ah, yes - good catch!

Will do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Tue Feb  8 18:15:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 8 Feb 2022 18:15:05 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <p-NSARSjUmZEmQjUnlpcVjgnvbHb2RQhcxilqi6jhgk=.9653e7ad-f41d-4f42-b596-c36786c28bc6@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <MWm-pkAiwXJvibYK-JdpuDAVDRxY8RRpF0Mvg3ACq9Y=.45c002da-7a51-4910-bb5d-68b400668bbe@github.com>
 <p-NSARSjUmZEmQjUnlpcVjgnvbHb2RQhcxilqi6jhgk=.9653e7ad-f41d-4f42-b596-c36786c28bc6@github.com>
Message-ID: <JhoDgihYZ7XmeOgF9KGUS6s8WR3J4if7tBYULD_UwCQ=.6451cad2-386e-41f5-ac2c-b938fd482037@github.com>

On Tue, 8 Feb 2022 18:06:52 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Ah, yes - good catch!
>
> Will do.

> I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null.

I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream,  aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere,  there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Tue Feb  8 18:15:06 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 8 Feb 2022 18:15:06 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
Message-ID: <xAxTx_goD11w0x08XJJBI5jAUXM9Rh9KwIOVmKi-yKo=.7dd6b303-04a2-49de-ab05-a4ab735c53fa@github.com>

On Tue, 8 Feb 2022 15:31:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce Exception checking to JarFile::verifiableEntry
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 874:
> 
>> 872:             ze = getJarEntry(ze.getName());
>> 873:         } else {
>> 874:             throw new ZipException("Error: ZipEntry::getName returned null!");
> 
> I'd probably leave out the "Error:" and the "!".

OK, I can do that if you prefer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Tue Feb  8 18:15:07 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 8 Feb 2022 18:15:07 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
Message-ID: <FvpMWBZG79ZGdjZKlMqlAAM3nAMg1qS36E691xMjU5A=.0cecdc0c-cb71-4fd9-96bd-848adeb38016@github.com>

On Tue, 8 Feb 2022 15:55:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> ze can't be null here.

Actually it can be:  Consider the following:


        try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(), true)) {
            var ze = new ZipEntry("org/gotham/Batcave.class");
            var ex= expectThrows(ZipException.class,
                    () -> jf.getInputStream(ze) );
            // Validate that we receive the expected message from
            // JarFile::verifiableEntry when ZipEntry::getName returns null
            assertTrue( ex != null && ex.getMessage().equals("Error: ZipEntry should not be null!"));
        }


The above code does generate the error.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Tue Feb  8 18:15:07 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 8 Feb 2022 18:15:07 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <FvpMWBZG79ZGdjZKlMqlAAM3nAMg1qS36E691xMjU5A=.0cecdc0c-cb71-4fd9-96bd-848adeb38016@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <FvpMWBZG79ZGdjZKlMqlAAM3nAMg1qS36E691xMjU5A=.0cecdc0c-cb71-4fd9-96bd-848adeb38016@github.com>
Message-ID: <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com>

On Tue, 8 Feb 2022 18:05:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> ze can't be null here.
>
>> ze can't be null here.
> 
> Actually it can be:  Consider the following:
> 
> 
>         try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(), true)) {
>             var ze = new ZipEntry("org/gotham/Batcave.class");
>             var ex= expectThrows(ZipException.class,
>                     () -> jf.getInputStream(ze) );
>             // Validate that we receive the expected message from
>             // JarFile::verifiableEntry when ZipEntry::getName returns null
>             assertTrue( ex != null && ex.getMessage().equals("Error: ZipEntry should not be null!"));
>         }
> 
> 
> The above code does generate the error.

> Nit, add space after "if"

will fix

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From alanb at openjdk.java.net  Tue Feb  8 18:59:07 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Feb 2022 18:59:07 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <JhoDgihYZ7XmeOgF9KGUS6s8WR3J4if7tBYULD_UwCQ=.6451cad2-386e-41f5-ac2c-b938fd482037@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <MWm-pkAiwXJvibYK-JdpuDAVDRxY8RRpF0Mvg3ACq9Y=.45c002da-7a51-4910-bb5d-68b400668bbe@github.com>
 <p-NSARSjUmZEmQjUnlpcVjgnvbHb2RQhcxilqi6jhgk=.9653e7ad-f41d-4f42-b596-c36786c28bc6@github.com>
 <JhoDgihYZ7XmeOgF9KGUS6s8WR3J4if7tBYULD_UwCQ=.6451cad2-386e-41f5-ac2c-b938fd482037@github.com>
Message-ID: <fxyQKSIfgdRYqadNoFydQJ8hNSGukkP_RMGsI2w-7VM=.a0d45a85-5dc2-41bb-951a-395e0ff21a7e@github.com>

On Tue, 8 Feb 2022 18:11:38 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream, aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere, there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called.

I think the scenario that we are discussing is where the parameter is not null. It's the case where getInputStream(ZipEntry) is called with a ZipEntry that reports its name as null. I don't think it is covered by existing javadoc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Tue Feb  8 19:20:10 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 8 Feb 2022 19:20:10 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <fxyQKSIfgdRYqadNoFydQJ8hNSGukkP_RMGsI2w-7VM=.a0d45a85-5dc2-41bb-951a-395e0ff21a7e@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <MWm-pkAiwXJvibYK-JdpuDAVDRxY8RRpF0Mvg3ACq9Y=.45c002da-7a51-4910-bb5d-68b400668bbe@github.com>
 <p-NSARSjUmZEmQjUnlpcVjgnvbHb2RQhcxilqi6jhgk=.9653e7ad-f41d-4f42-b596-c36786c28bc6@github.com>
 <JhoDgihYZ7XmeOgF9KGUS6s8WR3J4if7tBYULD_UwCQ=.6451cad2-386e-41f5-ac2c-b938fd482037@github.com>
 <fxyQKSIfgdRYqadNoFydQJ8hNSGukkP_RMGsI2w-7VM=.a0d45a85-5dc2-41bb-951a-395e0ff21a7e@github.com>
Message-ID: <AlXAhuKdIJJqwPW93-25QxZkV0gA74wWSmaP9tOCsic=.b63cbee1-c2a1-4645-b511-3605ab40c954@github.com>

On Tue, 8 Feb 2022 18:56:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null.
>> 
>> I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream,  aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere,  there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called.
>
>> I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream, aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere, there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called.
> 
> I think the scenario that we are discussing is where the parameter is not null. It's the case where getInputStream(ZipEntry) is called with a ZipEntry that reports its name as null. I don't think it is covered by existing javadoc.

Ah, OK, sorry I was focused on the NPE and uber focused on the `ZipEntry` passed to `getInputStream`.

If you *prefer* an IAE, I can change that when `ZipEntry::getName` returns null.  I do think we are technically covered via `ZipException` which is defined : ` if a zip file format error has occurred` and unless something has gone amiss with the Zip/Jar LOC/CEN, you should expect a non-null value.

Please let me know your preference as if we go the IAE route, I will need to create a CSR which I was hoping to avoid

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Tue Feb  8 20:21:23 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 8 Feb 2022 20:21:23 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
 <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>
 <VaoboQauDvyeErq1uQ2T9ZoYJfWdoBoConxHC5vfuJw=.cec74dd9-3e6e-4fb4-889e-aafbdcf96cf4@github.com>
 <yude3erR_j09o2sux8u5kGbMlTjt3f7ozrfZAnyEHlY=.a262f389-9735-474b-adda-750462285a2d@github.com>
 <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com>
Message-ID: <sP989FQ1Wf2qqD5ci8lHpuPEr2dq0HQRlIn9oCb7r18=.015e7d27-0670-448c-9251-1224f27a9152@github.com>

On Mon, 7 Feb 2022 23:13:13 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> "If set, these properties will override the signature schemes returned by this method."
>> 
>> If I understand your ideas correctly, the behavior should be "the returned value of this method will override these properties", except the case if the returned value is null.
>> 
>> But let me trying  if I could understand the spec by myself.
>> 
>> For the getSignatureSchemes() method's spec:
>> 
>>      * If the returned array is {@code null}, then the underlying
>>      * provider-specific default signature schemes will be used over the
>>      * SSL/TLS/DTLS connections.
>> 
>> With the spec above, the API getSignatureSchemes() returns null, and the provider-specific default signature schemes will be used for the connection.  As the properties could be used to customize the default signature schemes, the properties wins in this situation for your question.  However, I would like to express that the default signature schemes win (See bellow about why I don't want to use the properties).
>> 
>> 
>>      * If the returned array is empty (zero-length), then the signature scheme
>>      * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
>>      * the connections may not be able to be established if the negotiation
>>      * mechanism is required by a certain SSL/TLS/DTLS protocol.
>> 
>> With the spec above, the API getSignatureSchemes() returns empty array, and no signature schemes will be used.  The API wins, the default signature schemes are not used.
>> 
>> 
>>      * <p>
>>      * If the returned array is not {@code null} or empty (zero-length),
>>      * then the signature schemes in the returned array will be used over
>>      * the SSL/TLS/DTLS connections.
>> 
>> With the spec above, the API getSignatureSchemes() returns non-null and non-empty, and the returned array will be used.  The API wins, the default signature schemes are not used.
>> 
>> 
>>      * @implNote
>>      * Note that the underlying provider may define the default signature
>>      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>>      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>>      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>>      * customize the provider-specific default signature schemes.
>> 
>> With the spec above, I could understand what are the default signature schemes, and how they could be customized with properties.
>> 
>> So back to my question above, why I don't want to use the properties, and use the default signature schemes instead?  We need to take care of three things: the properties, the API set values and the provider default values.  If I use the properties values, I would have to describe the provider default values as well.  As the properties values are used to set the provider default values, it should be sufficient to use the provider default values for the description in this context.
>> 
>> What if both the properties and the APIs are set?  The properties are used to set the provider default values, and the properties will change the  provider default values.  So we only need to consider the provider default values and the API, then I think we can refer to the 3 spec sections before the @implNote tag above.  Simply, if both set, the API wins.
>> 
>> Similar to the set method.
>> 
>> Please let me know if you are on the same page as well.  I am open to make more changes if the spec is still not clear.
>
>> Are you maybe saying that this method returns the value of the system properties if they are set?
> 
> The return value of this method depends on the following specs:
> 
>      * If the {@link #setSignatureSchemes} method has not been called, this
>      * method should return the default signature schemes for connection
>      * populated objects, or {@code null} for pre-populated objects.
> ``` 
> 
> If the setSignatureSchemes() method has been called, the get method will return the set values.  I may miss this spec.  But I think it is a common sense that the getter method returns the values set with setter method.  Let me know if you would like to have an explicit clarification in the spec.

Ok, I get it now, the API wins if both are set. But I could not discern that from the current text. I think it is ok to be more clear about this. I suggest adding something like the following:

"The set of signature schemes that will be used is determined in this order of preference: 1. explicitly set by application; 2. specified by system property; 3. specified by provider defaults. For example, setting the signature schemes in your application overrides settings specified in jdk.tls.client.SignatureSchemes or jdk.tls.client.SignatureSchemes, as well as JDK provider defaults."

Does that accurately capture the implementation behavior?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From weijun at openjdk.java.net  Tue Feb  8 23:07:05 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 8 Feb 2022 23:07:05 GMT
Subject: RFR: 8265765: DomainKeyStore may stop enumerating aliases if a
 constituting KeyStore is empty
In-Reply-To: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>
References: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>
Message-ID: <-n2r6comAgHdRrFW-yXElPWNBbxVtT8qnVX7SgHodFU=.3773c3ff-304a-4f01-9e78-4254cf27ef39@github.com>

On Tue, 8 Feb 2022 17:13:53 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This is to fix `DomainKeyStore::engineAliases` to take into account that there may be empty keystore(s) within the collection of keystores of a domain keystore.

Looks good to me.

Do you want to play with text blocks in the test for `twoPartsConfiguration` and `threePartsConfiguration`?

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7386

From xuelei at openjdk.java.net  Tue Feb  8 23:39:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Feb 2022 23:39:16 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <sP989FQ1Wf2qqD5ci8lHpuPEr2dq0HQRlIn9oCb7r18=.015e7d27-0670-448c-9251-1224f27a9152@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
 <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>
 <VaoboQauDvyeErq1uQ2T9ZoYJfWdoBoConxHC5vfuJw=.cec74dd9-3e6e-4fb4-889e-aafbdcf96cf4@github.com>
 <yude3erR_j09o2sux8u5kGbMlTjt3f7ozrfZAnyEHlY=.a262f389-9735-474b-adda-750462285a2d@github.com>
 <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com>
 <sP989FQ1Wf2qqD5ci8lHpuPEr2dq0HQRlIn9oCb7r18=.015e7d27-0670-448c-9251-1224f27a9152@github.com>
Message-ID: <RWG-jUQu_TY58O9CzlTeR9fbJtUZvE9f0A8igsterGs=.86828079-0ea0-4bc1-96a9-c432c38db50b@github.com>

On Tue, 8 Feb 2022 20:18:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> Are you maybe saying that this method returns the value of the system properties if they are set?
>> 
>> The return value of this method depends on the following specs:
>> 
>>      * If the {@link #setSignatureSchemes} method has not been called, this
>>      * method should return the default signature schemes for connection
>>      * populated objects, or {@code null} for pre-populated objects.
>> ``` 
>> 
>> If the setSignatureSchemes() method has been called, the get method will return the set values.  I may miss this spec.  But I think it is a common sense that the getter method returns the values set with setter method.  Let me know if you would like to have an explicit clarification in the spec.
>
> Ok, I get it now, the API wins if both are set. But I could not discern that from the current text. I think it is ok to be more clear about this. I suggest adding something like the following:
> 
> "The set of signature schemes that will be used is determined in this order of preference: 1. explicitly set by application; 2. specified by system property; 3. specified by provider defaults. For example, setting the signature schemes in your application overrides settings specified in jdk.tls.client.SignatureSchemes or jdk.tls.server.SignatureSchemes, as well as JDK provider defaults."
> 
> Does that accurately capture the implementation behavior?

Basically, the suggestion captures the implementation behaviors correctly.  To make it more accuracy, if we want to use it, we may need to consider more cases:
1. _explicitly set by application_, with null, empty or 1+ schemes.
2. _specified by system property_, with unset, empty or 1+ schemes.

I think the description could be in the following logic:
A. the system properties are used to customize the provider default schemes.
B. If the API set it to null, use the the provider default schemes (including system properties customized default schemes).
C. If the API set it to empty, don't use any schemes.
D. if the API set it to 1+ scheme, use the API set schemes.

With logic A, we don't have to describe both _system properties_ and the _provider default schemes_ each time when we talk about the interaction behaviors of them. And then we can simplify the 3 interactive factors into 2 factors.

Here is the general 3 interactive factors:
1. the API.
2. the System properties.
3. the provider default.

Here is set 1 of the 2 interactive factors:
1. The System properties;
2. the provider default.

Here is set 2 of the 2 interactive factors:
1. the API
2. the provider default.

Then, we could describe set 1 and set 2 individually.  I think it is easier to understand.

Then, we could have the sections accordingly.
For A, we have (for set 1 of the 2 interactive factors):

     * @implNote
     * Note that the underlying provider may define the default signature
     * schemes for each SSL/TLS/DTLS connection.  Applications may also use
     * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
     * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
     * customize the provider-specific default signature schemes.
``` 

For B, we have (for set 2 of the 2 interactive factors):

     * If the returned array is {@code null}, then the underlying
     * provider-specific default signature schemes will be used over the
     * SSL/TLS/DTLS connections.


For C, we have (for set 2 of the 2 interactive factors):

     * If the returned array is empty (zero-length), then the signature scheme
     * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
     * the connections may not be able to be established if the negotiation
     * mechanism is required by a certain SSL/TLS/DTLS protocol.


For D, we have (for set 2 of the 2 interactive factors):

     * <p>
     * If the returned array is not {@code null} or empty (zero-length),
     * then the signature schemes in the returned array will be used over
     * the SSL/TLS/DTLS connections.


That's the current description we have.  That's, in order to explain behavior of the null, empty and 1+ schemes setting, I cut the sentence into 4 sections above.

I understand it could be confusing when multiple facts are involved.  It may be clear if re-org the description. What do you think of the following descriptions?

In the get method:

     * <p>
     * Note that the underlying provider may define the default signature schemes for
     * each SSL/TLS/DTLS connection.  Applications may also use the {@systemProperty
     * jdk.tls.client.SignatureSchemes} and/or {@systemProperty 
     * jdk.tls.server.SignatureSchemes} system properties to customize the
     *  provider-specific default signature schemes.
     * <p>
     * The set of signature schemes that will be used over the SSL/TLS/DTLS
     * connections is determined by the returned array of this method and the 
     * underlying provider-specific default signature schemes.
     * <p>
     * If the returned array is {@code null}, then the underlying
     * provider-specific default signature schemes will be used over the
     * SSL/TLS/DTLS connections.
     * <p>
     * If the returned array is empty (zero-length), then the signature scheme
     * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
     * the connections may not be able to be established if the negotiation
     * mechanism is required by a certain SSL/TLS/DTLS protocol.
     * <p>
     * If the returned array is not {@code null} or empty (zero-length),
     * then the signature schemes in the returned array will be used over
     * the SSL/TLS/DTLS connections.


and similarly, in the set method:

     * <p>
     * Note that the underlying provider may define the default signature
     * schemes for each SSL/TLS/DTLS connection.  Applications may also use
     * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
     * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
     * customize the provider-specific default signature schemes.
     * <p>
     * The set of signature schemes that will be used over the SSL/TLS/DTLS
     * connections is determined by the input parameter {@code signatureSchemes} array
     *  and the underlying provider-specific default signature schemes.
     * <p>
     * If the input parameter {@code signatureSchemes} array is {@code null},
     * then the underlying provider-specific default signature schemes will
     * be used over the SSL/TLS/DTLS connections.
     * <p>
     * If the input parameter {@code signatureSchemes} array is empty
     * (zero-length), then the signature scheme negotiation mechanism is
     * turned off for SSL/TLS/DTLS protocols, and the connections may not be
     * able to be established if the negotiation mechanism is required by a
     * certain SSL/TLS/DTLS protocol.
     * <p>
     * If the input parameter {@code signatureSchemes} array is not {@code null}
     * or empty (zero-length), then the signature schemes specified in the
     * {@code signatureSchemes} array will be used over the SSL/TLS/DTLS
     * connections.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From hchao at openjdk.java.net  Tue Feb  8 23:46:04 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 8 Feb 2022 23:46:04 GMT
Subject: RFR: 8265765: DomainKeyStore may stop enumerating aliases if a
 constituting KeyStore is empty
In-Reply-To: <-n2r6comAgHdRrFW-yXElPWNBbxVtT8qnVX7SgHodFU=.3773c3ff-304a-4f01-9e78-4254cf27ef39@github.com>
References: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>
 <-n2r6comAgHdRrFW-yXElPWNBbxVtT8qnVX7SgHodFU=.3773c3ff-304a-4f01-9e78-4254cf27ef39@github.com>
Message-ID: <CHYPZ4RCzqLctsYcns_mSBSW0v6pvYG9GhvfDTjYjts=.9b190948-5ab6-49ec-a0e8-4fa8c526052f@github.com>

On Tue, 8 Feb 2022 23:03:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is to fix `DomainKeyStore::engineAliases` to take into account that there may be empty keystore(s) within the collection of keystores of a domain keystore.
>
> Looks good to me.
> 
> Do you want to play with text blocks in the test for `twoPartsConfiguration` and `threePartsConfiguration`?

@wangweij Thanks for the review. The `threePartsConfiguration` with the current names for the three keystores would fail the test without the fix in engineAliases. So I'd keep the text block for it as is because names in Map entry order may differ. For the `twoPartsConfiguration`, its domainkeystore has no empty keystore inside it, so it'd cover the "non empty" part of the testing. Is there a particular configuration that you thought to be covered?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7386

From hchao at openjdk.java.net  Wed Feb  9 06:34:40 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 9 Feb 2022 06:34:40 GMT
Subject: RFR: 8265765: DomainKeyStore may stop enumerating aliases if a
 constituting KeyStore is empty [v2]
In-Reply-To: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>
References: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>
Message-ID: <PqBU5VDgDEhQhVLksQvWt2OzTpPJxCeEoDyJto2ym74=.85e410e8-62a2-4c99-b5d4-30fd765bbf85@github.com>

> This is to fix `DomainKeyStore::engineAliases` to take into account that there may be empty keystore(s) within the collection of keystores of a domain keystore.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Testcase updated

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7386/files
  - new: https://git.openjdk.java.net/jdk/pull/7386/files/200fa1b7..a9adc254

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7386&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7386&range=00-01

  Stats: 13 lines in 1 file changed: 8 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7386.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7386/head:pull/7386

PR: https://git.openjdk.java.net/jdk/pull/7386

From weijun at openjdk.java.net  Wed Feb  9 13:32:04 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 9 Feb 2022 13:32:04 GMT
Subject: RFR: 8265765: DomainKeyStore may stop enumerating aliases if a
 constituting KeyStore is empty [v2]
In-Reply-To: <PqBU5VDgDEhQhVLksQvWt2OzTpPJxCeEoDyJto2ym74=.85e410e8-62a2-4c99-b5d4-30fd765bbf85@github.com>
References: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>
 <PqBU5VDgDEhQhVLksQvWt2OzTpPJxCeEoDyJto2ym74=.85e410e8-62a2-4c99-b5d4-30fd765bbf85@github.com>
Message-ID: <CgTIOyYq2hFLghKkivgieItmFpnFljKHDs-PV4KSNlo=.f4cbc0b5-0cb5-450f-a4a5-31d93c7ad7a5@github.com>

On Wed, 9 Feb 2022 06:34:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This is to fix `DomainKeyStore::engineAliases` to take into account that there may be empty keystore(s) within the collection of keystores of a domain keystore.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Testcase updated

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7386

From mullan at openjdk.java.net  Wed Feb  9 14:36:10 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 9 Feb 2022 14:36:10 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <RWG-jUQu_TY58O9CzlTeR9fbJtUZvE9f0A8igsterGs=.86828079-0ea0-4bc1-96a9-c432c38db50b@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
 <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>
 <VaoboQauDvyeErq1uQ2T9ZoYJfWdoBoConxHC5vfuJw=.cec74dd9-3e6e-4fb4-889e-aafbdcf96cf4@github.com>
 <yude3erR_j09o2sux8u5kGbMlTjt3f7ozrfZAnyEHlY=.a262f389-9735-474b-adda-750462285a2d@github.com>
 <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com>
 <sP989FQ1Wf2qqD5ci8lHpuPEr2dq0HQRlIn9oCb7r18=.015e7d27-0670-448c-9251-1224f27a9152@github.com>
 <RWG-jUQu_TY58O9CzlTeR9fbJtUZvE9f0A8igsterGs=.86828079-0ea0-4bc1-96a9-c432c38db50b@github.com>
Message-ID: <gpqTmDFpolnablnIMCv0b6MvkLlcLGtuIqV-jR7EFmk=.298be579-5a81-4e19-bc1d-3f6fcc2544a2@github.com>

On Tue, 8 Feb 2022 23:36:05 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Ok, I get it now, the API wins if both are set. But I could not discern that from the current text. I think it is ok to be more clear about this. I suggest adding something like the following:
>> 
>> "The set of signature schemes that will be used is determined in this order of preference: 1. explicitly set by application; 2. specified by system property; 3. specified by provider defaults. For example, setting the signature schemes in your application overrides settings specified in jdk.tls.client.SignatureSchemes or jdk.tls.server.SignatureSchemes, as well as JDK provider defaults."
>> 
>> Does that accurately capture the implementation behavior?
>
> Basically, the suggestion captures the implementation behaviors correctly.  To make it more accuracy, if we want to use it, we may need to consider more cases:
> 1. _explicitly set by application_, with null, empty or 1+ schemes.
> 2. _specified by system property_, with unset, empty or 1+ schemes.
> 
> I think the description could be in the following logic:
> A. the system properties are used to customize the provider default schemes.
> B. If the API set it to null, use the the provider default schemes (including system properties customized default schemes).
> C. If the API set it to empty, don't use any schemes.
> D. if the API set it to 1+ scheme, use the API set schemes.
> 
> With logic A, we don't have to describe both _system properties_ and the _provider default schemes_ each time when we talk about the interaction behaviors of them. And then we can simplify the 3 interactive factors into 2 factors.
> 
> Here is the general 3 interactive factors:
> 1. the API.
> 2. the System properties.
> 3. the provider default.
> 
> Here is set 1 of the 2 interactive factors:
> 1. The System properties;
> 2. the provider default.
> 
> Here is set 2 of the 2 interactive factors:
> 1. the API
> 2. the provider default.
> 
> Then, we could describe set 1 and set 2 individually.  I think it is easier to understand.
> 
> Then, we could have the sections accordingly.
> For A, we have (for set 1 of the 2 interactive factors):
> 
>      * @implNote
>      * Note that the underlying provider may define the default signature
>      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>      * customize the provider-specific default signature schemes.
> ``` 
> 
> For B, we have (for set 2 of the 2 interactive factors):
> 
>      * If the returned array is {@code null}, then the underlying
>      * provider-specific default signature schemes will be used over the
>      * SSL/TLS/DTLS connections.
> 
> 
> For C, we have (for set 2 of the 2 interactive factors):
> 
>      * If the returned array is empty (zero-length), then the signature scheme
>      * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
>      * the connections may not be able to be established if the negotiation
>      * mechanism is required by a certain SSL/TLS/DTLS protocol.
> 
> 
> For D, we have (for set 2 of the 2 interactive factors):
> 
>      * <p>
>      * If the returned array is not {@code null} or empty (zero-length),
>      * then the signature schemes in the returned array will be used over
>      * the SSL/TLS/DTLS connections.
> 
> 
> That's the current description we have.  That's, in order to explain behavior of the null, empty and 1+ schemes setting, I cut the sentence into 4 sections above.
> 
> I understand it could be confusing when multiple facts are involved.  It may be clear if re-org the description. What do you think of the following descriptions?
> 
> In the get method:
> 
>      * <p>
>      * Note that the underlying provider may define the default signature schemes for
>      * each SSL/TLS/DTLS connection.  Applications may also use the {@systemProperty
>      * jdk.tls.client.SignatureSchemes} and/or {@systemProperty 
>      * jdk.tls.server.SignatureSchemes} system properties to customize the
>      *  provider-specific default signature schemes.
>      * <p>
>      * The set of signature schemes that will be used over the SSL/TLS/DTLS
>      * connections is determined by the returned array of this method and the 
>      * underlying provider-specific default signature schemes.
>      * <p>
>      * If the returned array is {@code null}, then the underlying
>      * provider-specific default signature schemes will be used over the
>      * SSL/TLS/DTLS connections.
>      * <p>
>      * If the returned array is empty (zero-length), then the signature scheme
>      * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
>      * the connections may not be able to be established if the negotiation
>      * mechanism is required by a certain SSL/TLS/DTLS protocol.
>      * <p>
>      * If the returned array is not {@code null} or empty (zero-length),
>      * then the signature schemes in the returned array will be used over
>      * the SSL/TLS/DTLS connections.
> 
> 
> and similarly, in the set method:
> 
>      * <p>
>      * Note that the underlying provider may define the default signature
>      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>      * customize the provider-specific default signature schemes.
>      * <p>
>      * The set of signature schemes that will be used over the SSL/TLS/DTLS
>      * connections is determined by the input parameter {@code signatureSchemes} array
>      *  and the underlying provider-specific default signature schemes.
>      * <p>
>      * If the input parameter {@code signatureSchemes} array is {@code null},
>      * then the underlying provider-specific default signature schemes will
>      * be used over the SSL/TLS/DTLS connections.
>      * <p>
>      * If the input parameter {@code signatureSchemes} array is empty
>      * (zero-length), then the signature scheme negotiation mechanism is
>      * turned off for SSL/TLS/DTLS protocols, and the connections may not be
>      * able to be established if the negotiation mechanism is required by a
>      * certain SSL/TLS/DTLS protocol.
>      * <p>
>      * If the input parameter {@code signatureSchemes} array is not {@code null}
>      * or empty (zero-length), then the signature schemes specified in the
>      * {@code signatureSchemes} array will be used over the SSL/TLS/DTLS
>      * connections.

I see your points. Were you proposing that this text would all be normative text? If so, I don't think that is correct, as the system properties are implementation specific. What might work is if you take the first paragraph and move it to the end of the text above as an @implNote:

>      * @implNote
>      * Note that the underlying provider may define the default signature
>      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>      * customize the provider-specific default signature schemes.
     
I would probably use the word "override" instead of "customize". Customize sounds like you can change some of the defaults and leave others in place.

I think you should also consider adding this sentence to the end of each of the paragraphs when the input is an empty array or an array of 1+: "This parameter will override the underlying provider-specific default signature schemes."

Finally, to avoid duplication of text, I would only add this text to the `setSignatureSchemes` method, and in the `getSignatureSchemes` method, add something like: "See {@link setSignatureSchemes} for specific details on how the parameters are used in SSL/TLS/DTLS connections."

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From hchao at openjdk.java.net  Wed Feb  9 16:57:11 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 9 Feb 2022 16:57:11 GMT
Subject: Integrated: 8265765: DomainKeyStore may stop enumerating aliases if a
 constituting KeyStore is empty
In-Reply-To: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>
References: <AwIDO32Dk5XfAb4S-EuvTnsPbcFavPWKB4OKzikjims=.e6d31079-7ed6-49d3-9004-f7dbdfd38aef@github.com>
Message-ID: <uwYGkd06MnNWs0PG1XVGHXgzwL_gos4wHhzw_CGbnAo=.781540db-90f1-4dd6-b121-a30376af50f4@github.com>

On Tue, 8 Feb 2022 17:13:53 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This is to fix `DomainKeyStore::engineAliases` to take into account that there may be empty keystore(s) within the collection of keystores of a domain keystore.

This pull request has now been integrated.

Changeset: 178b962e
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/178b962e01cc6c150442bf41dc6bd199caff0042
Stats:     136 lines in 2 files changed: 129 ins; 2 del; 5 mod

8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/7386

From xuelei at openjdk.java.net  Wed Feb  9 18:24:56 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Feb 2022 18:24:56 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v15]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <Db_hqR1lG2BMF3Ckrr5X8shgDbimz7r6ujK6yg69X00=.3ec2e2c7-d051-4db2-a775-8f0edbde4726@github.com>

> 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:

  Spec update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/8302c592..c0018c67

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=13-14

  Stats: 31 lines in 1 file changed: 7 ins; 16 del; 8 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

From xuelei at openjdk.java.net  Wed Feb  9 18:33:15 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Feb 2022 18:33:15 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v13]
In-Reply-To: <gpqTmDFpolnablnIMCv0b6MvkLlcLGtuIqV-jR7EFmk=.298be579-5a81-4e19-bc1d-3f6fcc2544a2@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <rRs-ZBnJbSXxkTGZMsUqa0iinBYFbUgxwQnDG_9VQYE=.ddc1c5a8-f6ff-4e00-ba69-4f72fe0ac774@github.com>
 <Hk_bz1Js-47ZH3i6zEF-833ihF6AmP3NSeZPp938_TU=.7b1d0d65-4417-4083-be39-26d3484603da@github.com>
 <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com>
 <VaoboQauDvyeErq1uQ2T9ZoYJfWdoBoConxHC5vfuJw=.cec74dd9-3e6e-4fb4-889e-aafbdcf96cf4@github.com>
 <yude3erR_j09o2sux8u5kGbMlTjt3f7ozrfZAnyEHlY=.a262f389-9735-474b-adda-750462285a2d@github.com>
 <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com>
 <sP989FQ1Wf2qqD5ci8lHpuPEr2dq0HQRlIn9oCb7r18=.015e7d27-0670-448c-9251-1224f27a9152@github.com>
 <RWG-jUQu_TY58O9CzlTeR9fbJtUZvE9f0A8igsterGs=.86828079-0ea0-4bc1-96a9-c432c38db50b@github.com>
 <gpqTmDFpolnablnIMCv0b6MvkLlcLGtuIqV-jR7EFmk=.298be579-5a81-4e19-bc1d-3f6fcc2544a2@github.com>
Message-ID: <TMn5YnA0duwF3l1P7d7BbElVGQLt4OipaGrC0QihFxw=.9319a2b0-5ea0-47e5-b55f-5fc2ebdd7c9c@github.com>

On Wed, 9 Feb 2022 14:33:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Basically, the suggestion captures the implementation behaviors correctly.  To make it more accuracy, if we want to use it, we may need to consider more cases:
>> 1. _explicitly set by application_, with null, empty or 1+ schemes.
>> 2. _specified by system property_, with unset, empty or 1+ schemes.
>> 
>> I think the description could be in the following logic:
>> A. the system properties are used to customize the provider default schemes.
>> B. If the API set it to null, use the the provider default schemes (including system properties customized default schemes).
>> C. If the API set it to empty, don't use any schemes.
>> D. if the API set it to 1+ scheme, use the API set schemes.
>> 
>> With logic A, we don't have to describe both _system properties_ and the _provider default schemes_ each time when we talk about the interaction behaviors of them. And then we can simplify the 3 interactive factors into 2 factors.
>> 
>> Here is the general 3 interactive factors:
>> 1. the API.
>> 2. the System properties.
>> 3. the provider default.
>> 
>> Here is set 1 of the 2 interactive factors:
>> 1. The System properties;
>> 2. the provider default.
>> 
>> Here is set 2 of the 2 interactive factors:
>> 1. the API
>> 2. the provider default.
>> 
>> Then, we could describe set 1 and set 2 individually.  I think it is easier to understand.
>> 
>> Then, we could have the sections accordingly.
>> For A, we have (for set 1 of the 2 interactive factors):
>> 
>>      * @implNote
>>      * Note that the underlying provider may define the default signature
>>      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>>      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>>      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>>      * customize the provider-specific default signature schemes.
>> ``` 
>> 
>> For B, we have (for set 2 of the 2 interactive factors):
>> 
>>      * If the returned array is {@code null}, then the underlying
>>      * provider-specific default signature schemes will be used over the
>>      * SSL/TLS/DTLS connections.
>> 
>> 
>> For C, we have (for set 2 of the 2 interactive factors):
>> 
>>      * If the returned array is empty (zero-length), then the signature scheme
>>      * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
>>      * the connections may not be able to be established if the negotiation
>>      * mechanism is required by a certain SSL/TLS/DTLS protocol.
>> 
>> 
>> For D, we have (for set 2 of the 2 interactive factors):
>> 
>>      * <p>
>>      * If the returned array is not {@code null} or empty (zero-length),
>>      * then the signature schemes in the returned array will be used over
>>      * the SSL/TLS/DTLS connections.
>> 
>> 
>> That's the current description we have.  That's, in order to explain behavior of the null, empty and 1+ schemes setting, I cut the sentence into 4 sections above.
>> 
>> I understand it could be confusing when multiple facts are involved.  It may be clear if re-org the description. What do you think of the following descriptions?
>> 
>> In the get method:
>> 
>>      * <p>
>>      * Note that the underlying provider may define the default signature schemes for
>>      * each SSL/TLS/DTLS connection.  Applications may also use the {@systemProperty
>>      * jdk.tls.client.SignatureSchemes} and/or {@systemProperty 
>>      * jdk.tls.server.SignatureSchemes} system properties to customize the
>>      *  provider-specific default signature schemes.
>>      * <p>
>>      * The set of signature schemes that will be used over the SSL/TLS/DTLS
>>      * connections is determined by the returned array of this method and the 
>>      * underlying provider-specific default signature schemes.
>>      * <p>
>>      * If the returned array is {@code null}, then the underlying
>>      * provider-specific default signature schemes will be used over the
>>      * SSL/TLS/DTLS connections.
>>      * <p>
>>      * If the returned array is empty (zero-length), then the signature scheme
>>      * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
>>      * the connections may not be able to be established if the negotiation
>>      * mechanism is required by a certain SSL/TLS/DTLS protocol.
>>      * <p>
>>      * If the returned array is not {@code null} or empty (zero-length),
>>      * then the signature schemes in the returned array will be used over
>>      * the SSL/TLS/DTLS connections.
>> 
>> 
>> and similarly, in the set method:
>> 
>>      * <p>
>>      * Note that the underlying provider may define the default signature
>>      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>>      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>>      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>>      * customize the provider-specific default signature schemes.
>>      * <p>
>>      * The set of signature schemes that will be used over the SSL/TLS/DTLS
>>      * connections is determined by the input parameter {@code signatureSchemes} array
>>      *  and the underlying provider-specific default signature schemes.
>>      * <p>
>>      * If the input parameter {@code signatureSchemes} array is {@code null},
>>      * then the underlying provider-specific default signature schemes will
>>      * be used over the SSL/TLS/DTLS connections.
>>      * <p>
>>      * If the input parameter {@code signatureSchemes} array is empty
>>      * (zero-length), then the signature scheme negotiation mechanism is
>>      * turned off for SSL/TLS/DTLS protocols, and the connections may not be
>>      * able to be established if the negotiation mechanism is required by a
>>      * certain SSL/TLS/DTLS protocol.
>>      * <p>
>>      * If the input parameter {@code signatureSchemes} array is not {@code null}
>>      * or empty (zero-length), then the signature schemes specified in the
>>      * {@code signatureSchemes} array will be used over the SSL/TLS/DTLS
>>      * connections.
>
> I see your points. Were you proposing that this text would all be normative text? If so, I don't think that is correct, as the system properties are implementation specific. What might work is if you take the first paragraph and move it to the end of the text above as an @implNote:
> 
>>      * @implNote
>>      * Note that the underlying provider may define the default signature
>>      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
>>      * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>>      * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>>      * customize the provider-specific default signature schemes.
>      
> I would probably use the word "override" instead of "customize". Customize sounds like you can change some of the defaults and leave others in place.
> 
> I think you should also consider adding this sentence to the end of each of the paragraphs when the input is an empty array or an array of 1+: "This parameter will override the underlying provider-specific default signature schemes."
> 
> Finally, to avoid duplication of text, I would only add this text to the `setSignatureSchemes` method, and in the `getSignatureSchemes` method, add something like: "See {@link setSignatureSchemes} for specific details on how the parameters are used in SSL/TLS/DTLS connections."

Thank you for the word-smithing.

The use of signature schemes in the TLS implementation depends on the getSignatureSchemes() method.  In the getSignatureSchemes() methods, there are more cases described such as the signature schemes for populated objects and pre-populated objects.  So I have the text in the getSignatureSchemes(), and use the See-link in the setSignatureSchemes() instead.

Both the PR and CSR were updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From lancea at openjdk.java.net  Wed Feb  9 21:19:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 9 Feb 2022 21:19:05 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <FvpMWBZG79ZGdjZKlMqlAAM3nAMg1qS36E691xMjU5A=.0cecdc0c-cb71-4fd9-96bd-848adeb38016@github.com>
 <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com>
Message-ID: <zVAsfNnUsxk2grqu8_UB9Lijve5xaSG2o_TU7JopDVA=.c72bce72-4b20-4172-bbeb-3809656d83fb@github.com>

On Tue, 8 Feb 2022 18:06:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> ze can't be null here.
>> 
>> Actually it can be:  Consider the following:
>> 
>> 
>>         try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(), true)) {
>>             var ze = new ZipEntry("org/gotham/Batcave.class");
>>             var ex= expectThrows(ZipException.class,
>>                     () -> jf.getInputStream(ze) );
>>             // Validate that we receive the expected message from
>>             // JarFile::verifiableEntry when ZipEntry::getName returns null
>>             assertTrue( ex != null && ex.getMessage().equals("Error: ZipEntry should not be null!"));
>>         }
>> 
>> 
>> The above code does generate the error.
>
>> Nit, add space after "if"
> 
> will fix

So a bit more on this.  If the ZipEntry passed to `ZipFile::getInputStream` does not represent an entry within the current Zip/Jar,  `ZipFile::getInputStream` will return a null for the InputStream:


    @Test
    public static void ZipFileZipEntryNullGetInputStreamTest() throws Exception {
        try (ZipFile zf = new ZipFile(VALID_ENTRY_NAME_JAR.toFile())) {
            var ze = new ZipEntry("org/gotham/Batcave.class");
            var is = zf.getInputStream(ze);
            // As the ZipEntry cannot be found, the returned InpuStream is null
            assertNull(is);
        }
    }


  JarFile::getInputStream will also return null when the jar is not signed or we are not verifying the jar:


 @Test
    public static void JarFileZipEntryNullGetInputStreamTest() throws Exception {
        try (JarFile jf = new JarFile(VALID_ENTRY_NAME_JAR.toFile())) {
            var ze = new ZipEntry("org/gotham/Batcave.class");
            var is = jf.getInputStream(ze);
            // As the ZipEntry cannot be found, the returned InpuStream is null
            assertNull(is);
        }

        try (JarFile jf = new JarFile(SIGNED_INVALID_ENTRY_NAME_JAR.toFile(), false)) {
            var ze = new ZipEntry("org/gotham/Batcave.class");
            var is = jf.getInputStream(ze);
            // As the ZipEntry cannot be found, the returned InpuStream is null
            assertNull(is);
        }
    }



This behavior dates back to at least JDK 1.3

So I think we should return null  instead of throwing an Exception when the resulting ZipEntry is null that is returned from the call to`JarFile::getJarEntry` (which calls `ZipFile::getEntry`) for consistency with ZipFile and when the Jar is not signed or not verified.

I also noticed that `ZipFile::getInputStream` and `JarFile::getInputStream` do not mention that a null will be returned if the specified ZipEntry is not found within the Jar/Zip.  I guess I could open a CSR as part of this fix to clarify this 20+ year behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Wed Feb  9 21:46:16 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 9 Feb 2022 21:46:16 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v15]
In-Reply-To: <Db_hqR1lG2BMF3Ckrr5X8shgDbimz7r6ujK6yg69X00=.3ec2e2c7-d051-4db2-a775-8f0edbde4726@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <Db_hqR1lG2BMF3Ckrr5X8shgDbimz7r6ujK6yg69X00=.3ec2e2c7-d051-4db2-a775-8f0edbde4726@github.com>
Message-ID: <xGgq4ua6liSIdU_vVbNrRK78H0ktKwp2QcQKSNWgoOU=.c3ea652e-7e3e-4c3c-b746-7715a23bb183@github.com>

On Wed, 9 Feb 2022 18:24:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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:
> 
>   Spec update

If you agree with my last couple of comments, I think the API looks good now that you can finalize the CSR. I have not really reviewed the impl code and tests previously and may not have time to do a thorough review although I think Jamil may have done that - if he is ok with the rest of the code, then I think you can integrate once the CSR is approved. Thanks for the patience.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 749:

> 747:      * @implNote
> 748:      * Note that the underlying provider may define the default signature
> 749:      * schemes for each SSL/TLS/DTLS connection.  Applications may also use

I think you can remove the first sentence that starts with "Note ..." as you already talk about provider-specific defaults before this. Also @implNotes are usually about the JDK implementation and not any provider. In the second sentence I would be more specific that this applies to the SunJSSE provider (see changes in italics), ex: "Applications ... system properties _with the SunJSSE provider_ to ..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Wed Feb  9 22:12:10 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Feb 2022 22:12:10 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v4]
In-Reply-To: <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
 <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>
Message-ID: <sbQLdHaSnbI0UnSl7kWHFPxmJR3ypKDScvKrcGTCP10=.6b76fcf0-cb71-424c-899a-bc153c00a6f5@github.com>

On Wed, 3 Nov 2021 17:02:40 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the patch for JDK-8274524
>> 
>> The fix just adds locks around InputStream read and skip operations to prevent concurrent read from socket.
>> sun/security/ssl jtreg tests passed
>> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jcheck issues

With the patch, the readLock is placed in handshakeLock, and the handshake may require lock write lock.  These nested lock is pretty risk and will run into deadlocks.  That's the underlying reason why readHandshakeRecord() is not placed within read lock and write lock.

It looks like the problem is cause by close() method.  Maybe, improving the close() implementation could be an alternative solution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5760

From xuelei at openjdk.java.net  Wed Feb  9 22:58:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Feb 2022 22:58:16 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v15]
In-Reply-To: <xGgq4ua6liSIdU_vVbNrRK78H0ktKwp2QcQKSNWgoOU=.c3ea652e-7e3e-4c3c-b746-7715a23bb183@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <Db_hqR1lG2BMF3Ckrr5X8shgDbimz7r6ujK6yg69X00=.3ec2e2c7-d051-4db2-a775-8f0edbde4726@github.com>
 <xGgq4ua6liSIdU_vVbNrRK78H0ktKwp2QcQKSNWgoOU=.c3ea652e-7e3e-4c3c-b746-7715a23bb183@github.com>
Message-ID: <AVwc1wQtST-02nWPbxP3CN--Pui28enOiiHhWBw4VXs=.f6b9a3c6-8d0f-4160-8127-a31d80e75957@github.com>

On Wed, 9 Feb 2022 21:38:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spec update
>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 749:
> 
>> 747:      * @implNote
>> 748:      * Note that the underlying provider may define the default signature
>> 749:      * schemes for each SSL/TLS/DTLS connection.  Applications may also use
> 
> I think you can remove the first sentence that starts with "Note ..." as you already talk about provider-specific defaults before this. Also @implNotes are usually about the JDK implementation and not any provider. In the second sentence I would be more specific that this applies to the SunJSSE provider (see changes in italics), ex: "Applications ... system properties _with the SunJSSE provider_ to ..."

Sounds good to me.  Updated the CSR and PR.  Thank you for the review!

@jnimeh Jamil, do you have any comment about the spec and implementation?  Otherwise, I will finalize the CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Wed Feb  9 23:01:56 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Feb 2022 23:01:56 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v16]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <9R1rEVErOxfA5_uNu32S4jJorF9UVltpfCqt6zeDiPs=.a973dde6-2c8b-4d72-bca2-1c1bdcfb55cc@github.com>

> 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:

  spec re-wording

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/c0018c67..40163778

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=14-15

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 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

From jjiang at openjdk.java.net  Thu Feb 10 06:24:19 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Thu, 10 Feb 2022 06:24:19 GMT
Subject: RFR: 8281567: Remove @throws IOException from
 X509CRLImpl::getExtension docs
Message-ID: <p4jnTjMnTg_IODFGTRcDssd9rotZA3tqfGosSkfMeY0=.a1b00108-c631-462a-bcf1-cbcaba44715a@github.com>

In class sun.security.x509.X509CRLImpl, method getExtension(ObjectIdentifier) doesn't declare that IOException would be thrown, so the @throws IOException doc should be removed.

-------------

Commit messages:
 - 8281567: Remove @throws IOException from X509CRLImpl::getExtension docs

Changes: https://git.openjdk.java.net/jdk/pull/7419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7419&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281567
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7419/head:pull/7419

PR: https://git.openjdk.java.net/jdk/pull/7419

From xuelei at openjdk.java.net  Thu Feb 10 06:53:04 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 10 Feb 2022 06:53:04 GMT
Subject: RFR: 8281567: Remove @throws IOException from
 X509CRLImpl::getExtension docs
In-Reply-To: <p4jnTjMnTg_IODFGTRcDssd9rotZA3tqfGosSkfMeY0=.a1b00108-c631-462a-bcf1-cbcaba44715a@github.com>
References: <p4jnTjMnTg_IODFGTRcDssd9rotZA3tqfGosSkfMeY0=.a1b00108-c631-462a-bcf1-cbcaba44715a@github.com>
Message-ID: <F3RahyfEzmyC8OIdfWDrYsMH4yha-rs7N5ULqsc3Xkw=.7c594677-ad52-42d2-843c-b68e4c55b11d@github.com>

On Thu, 10 Feb 2022 06:18:28 GMT, John Jiang <jjiang at openjdk.org> wrote:

> In class sun.security.x509.X509CRLImpl, method getExtension(ObjectIdentifier) doesn't declare that IOException would be thrown, so the @throws IOException doc should be removed.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7419

From jiefu at openjdk.java.net  Thu Feb 10 06:53:04 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 10 Feb 2022 06:53:04 GMT
Subject: RFR: 8281567: Remove @throws IOException from
 X509CRLImpl::getExtension docs
In-Reply-To: <p4jnTjMnTg_IODFGTRcDssd9rotZA3tqfGosSkfMeY0=.a1b00108-c631-462a-bcf1-cbcaba44715a@github.com>
References: <p4jnTjMnTg_IODFGTRcDssd9rotZA3tqfGosSkfMeY0=.a1b00108-c631-462a-bcf1-cbcaba44715a@github.com>
Message-ID: <mxOiWOjr26QDoWs1Ft0UAxcbrgugCoXcgnrmaqhmnHg=.7c55ca12-4b5a-465e-889b-37999c736cec@github.com>

On Thu, 10 Feb 2022 06:18:28 GMT, John Jiang <jjiang at openjdk.org> wrote:

> In class sun.security.x509.X509CRLImpl, method getExtension(ObjectIdentifier) doesn't declare that IOException would be thrown, so the @throws IOException doc should be removed.

Looks good and trivial.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7419

From jjiang at openjdk.java.net  Thu Feb 10 08:16:10 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Thu, 10 Feb 2022 08:16:10 GMT
Subject: Integrated: 8281567: Remove @throws IOException from
 X509CRLImpl::getExtension docs
In-Reply-To: <p4jnTjMnTg_IODFGTRcDssd9rotZA3tqfGosSkfMeY0=.a1b00108-c631-462a-bcf1-cbcaba44715a@github.com>
References: <p4jnTjMnTg_IODFGTRcDssd9rotZA3tqfGosSkfMeY0=.a1b00108-c631-462a-bcf1-cbcaba44715a@github.com>
Message-ID: <FwRqfLxfoFvw1mwG0MBpoGZCwyXuBe7ubU2VFzs7XI8=.a5f0c8f5-f240-4548-8a37-87c5982696dd@github.com>

On Thu, 10 Feb 2022 06:18:28 GMT, John Jiang <jjiang at openjdk.org> wrote:

> In class sun.security.x509.X509CRLImpl, method getExtension(ObjectIdentifier) doesn't declare that IOException would be thrown, so the @throws IOException doc should be removed.

This pull request has now been integrated.

Changeset: 7218d844
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7218d8449bfaa3f121b66088a88a194f77f06753
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8281567: Remove @throws IOException from X509CRLImpl::getExtension docs

Reviewed-by: xuelei, jiefu

-------------

PR: https://git.openjdk.java.net/jdk/pull/7419

From mullan at openjdk.java.net  Thu Feb 10 13:48:05 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 10 Feb 2022 13:48:05 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate#getSubjectAlternativeNames() in otherName
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <AMtBZCGurWdUctn2J6sXODVr4MTKHDLWYsn0HwUT9w4=.82ca0635-c21c-4f9a-ad2b-08567410ccc4@github.com>

On Thu, 20 Jan 2022 19:42:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Looks good, but I think a CSR should also be filed.

src/java.base/share/classes/java/security/cert/X509Certificate.java line 590:

> 588:      * integers separated by periods. Directory names (distinguished names)
> 589:      * are returned in <a href="http://www.ietf.org/rfc/rfc2253.txt">
> 590:      * RFC 2253</a> string format. Othernames are returned as a byte array

Maybe "otherNames" since that is what we call it below.

test/jdk/sun/security/x509/OtherName/Parse.java line 54:

> 52: public class Parse {
> 53: 
> 54:     public static class MyDNSName extends DNSName {

What's the purpose of the MyDNSName class? You don't seem to do anything with it later in the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Thu Feb 10 14:45:14 2022
From: duke at openjdk.java.net (Martin Bonato)
Date: Thu, 10 Feb 2022 14:45:14 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v4]
In-Reply-To: <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
Message-ID: <YbEPYuD8WbZ2hr-t6LQXpyr9PUMTsDrhmUNt-zDCjuw=.f7d0f9cf-0bfb-4440-91bd-a75262a30d25@github.com>

On Fri, 22 Oct 2021 18:45:31 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified isPrivateKeyValid

Is there any chance to get this back-ported to 11u? I saw the instructions for fix approvals on https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u however I'm not a contributor/author. Is there any means of showing interest or upvoting etc.?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4887

From lkorinth at openjdk.java.net  Thu Feb 10 15:47:23 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Thu, 10 Feb 2022 15:47:23 GMT
Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc
Message-ID: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>

Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.

-------------

Commit messages:
 - 8281585: Remove unused imports under test/lib and jtreg/gc

Changes: https://git.openjdk.java.net/jdk/pull/7426/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281585
  Stats: 92 lines in 60 files changed: 0 ins; 92 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7426.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7426/head:pull/7426

PR: https://git.openjdk.java.net/jdk/pull/7426

From weijun at openjdk.java.net  Thu Feb 10 15:55:06 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Feb 2022 15:55:06 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate#getSubjectAlternativeNames() in otherName
In-Reply-To: <AMtBZCGurWdUctn2J6sXODVr4MTKHDLWYsn0HwUT9w4=.82ca0635-c21c-4f9a-ad2b-08567410ccc4@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <AMtBZCGurWdUctn2J6sXODVr4MTKHDLWYsn0HwUT9w4=.82ca0635-c21c-4f9a-ad2b-08567410ccc4@github.com>
Message-ID: <9w_gU0wbWuuLd_G424Yb1xhceMlRti1Z0UDDmq3r-Z4=.bc2c8ea9-f7ac-43e1-96c1-8a2e8b6dac33@github.com>

On Thu, 10 Feb 2022 13:45:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Looks good, but I think a CSR should also be filed.

Sure, I'll write one now. I've added the `csr` label so that I will not forget about it. Just want to delay the writing after we agree on the text.

> src/java.base/share/classes/java/security/cert/X509Certificate.java line 590:
> 
>> 588:      * integers separated by periods. Directory names (distinguished names)
>> 589:      * are returned in <a href="http://www.ietf.org/rfc/rfc2253.txt">
>> 590:      * RFC 2253</a> string format. Othernames are returned as a byte array
> 
> Maybe "otherNames" since that is what we call it below.

OK.

> test/jdk/sun/security/x509/OtherName/Parse.java line 54:
> 
>> 52: public class Parse {
>> 53: 
>> 54:     public static class MyDNSName extends DNSName {
> 
> What's the purpose of the MyDNSName class? You don't seem to do anything with it later in the test.

It's a kind of otherName (the assigned OID is 1.2.3.6) I used later. The `OtherName` class tries to parse the name inside (see the private `getGNI()` method) and it is used in `equals()`. I just want to confirm it works.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 10 16:47:55 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Feb 2022 16:47:55 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName [v2]
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  wording, title

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7167/files
  - new: https://git.openjdk.java.net/jdk/pull/7167/files/cd119c86..e6e5558b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 10 16:47:56 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Feb 2022 16:47:56 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <R3g9vsbPu4pkGsMIWAD36rGIWcH_RqbGjgTPEuYN0SA=.aff68681-9f78-473c-80e1-7351990fe910@github.com>

On Thu, 20 Jan 2022 19:42:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

No commit pushed. Please also review the CSR at https://bugs.openjdk.java.net/browse/JDK-8281606 and the release note at https://bugs.openjdk.java.net/browse/JDK-8281608. Thanks in advance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From abakhtin at openjdk.java.net  Thu Feb 10 18:23:09 2022
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 10 Feb 2022 18:23:09 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v4]
In-Reply-To: <sbQLdHaSnbI0UnSl7kWHFPxmJR3ypKDScvKrcGTCP10=.6b76fcf0-cb71-424c-899a-bc153c00a6f5@github.com>
References: <eghIZku3Ui3TOE6xGj4uSvEvq_TIJGb_tMVJjKau22Y=.a428c00e-6942-4c58-ab78-c92cb03b9789@github.com>
 <sD9QkMxO1JK3tS5e5XyKbAOHI-BCS2sKxl01GYfMYZ4=.39a949d5-6564-4ceb-b72f-264e4b6e97c2@github.com>
 <sbQLdHaSnbI0UnSl7kWHFPxmJR3ypKDScvKrcGTCP10=.6b76fcf0-cb71-424c-899a-bc153c00a6f5@github.com>
Message-ID: <OT6FAEzpT675SNoAsTXXiIfXEUEPc0oSVoR-AfdRy_Y=.b111c685-1913-47a4-90bb-cd11bf3d3e91@github.com>

On Wed, 9 Feb 2022 22:09:40 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix jcheck issues
>
> With the patch, the readLock is placed in handshakeLock, and the handshake may require lock write lock.  These nested lock is pretty risk and will run into deadlocks.  That's the underlying reason why readHandshakeRecord() is not placed within read lock and write lock.
> 
> It looks like the problem is cause by close() method.  Maybe, improving the close() implementation could be an alternative solution.  For example, give up the skip operation if no lock can be granted.

Hi @XueleiFan thank you for explanation and suggestions.
We already have code to give up the skip operation if appInput.readLock can no be granted. Unfortunately, read operation during handshake is not protected by appInput.readLock. So it does not help in this case.
I just found, that the issue happens in case of zero SO_TIMEOUT only. I suggest to force non-zero SO_TIMEOUT during the skip(). New pull request is submitted: https://github.com/openjdk/jdk/pull/7432

-------------

PR: https://git.openjdk.java.net/jdk/pull/5760

From abakhtin at openjdk.java.net  Thu Feb 10 18:26:30 2022
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Thu, 10 Feb 2022 18:26:30 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the ssl
 handshake
Message-ID: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>

Please review the patch for the JDK-8274524

SSLSocket.close() could cause an intermittent hang of the socket read operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
SSLSocket.close() reads from the socket as part of the skip() operation to prevent TCP Connection reset (see JDK-8268965). Socket reads are performed in a loop for small chunks. These read operations could cause a deadlock, in case of SO_TIMEOUT = 0
I suggest to force non-zero SO_TIMEOUT during the skip() operation to prevent such deadlock

This is a second iteration of review. Previous PR was closed without integration: https://github.com/openjdk/jdk/pull/5760

-------------

Commit messages:
 - Add read timeout for deplete
 - Fix jcheck issues
 - Add ClientSocketCloseHang jtreg test
 - Reimplemented readLock, added lock in readHandshakeRecord
 - 8274524: SSLSocket.close() hangs if it is called during the ssl handshake

Changes: https://git.openjdk.java.net/jdk/pull/7432/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7432&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274524
  Stats: 146 lines in 2 files changed: 146 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7432.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7432/head:pull/7432

PR: https://git.openjdk.java.net/jdk/pull/7432

From mullan at openjdk.java.net  Thu Feb 10 19:29:11 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 10 Feb 2022 19:29:11 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName [v2]
In-Reply-To: <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>
Message-ID: <QvsC8n3Y-MszWKlpiKozEh6Vm9fUtM037NjJkeyNTcs=.e658c95c-1dce-4c9e-bede-6e8e4fedfa5c@github.com>

On Thu, 10 Feb 2022 16:47:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wording, title

One issue with this change is that there is no guarantee when or if a 3rd party provider will support these additional elements for OtherNames. In a worst case scenario, code may get an IOOBException if they assume there will be a 3rd or fourth element and there isn't. There is no perfect solution for this. I would suggest rewording the new text with a "may", and adding an @implNote stating that the SUN provider supports this feature. Something like:


      * otherNames are returned as a byte array
      * containing the ASN.1 DER encoded form of the name, and
      * may also return a third entry in the list containing its {@code type-id} in string
      * format, and a fourth entry containing the ASN.1 DER encoding of
      * its {@code value} without the context-specific constructed tag
      * with number 0.
      *
      * @implNote The JDK SUN provider supports the third and fourth otherName elements.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From mullan at openjdk.java.net  Thu Feb 10 20:41:34 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 10 Feb 2022 20:41:34 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <zVAsfNnUsxk2grqu8_UB9Lijve5xaSG2o_TU7JopDVA=.c72bce72-4b20-4172-bbeb-3809656d83fb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <FvpMWBZG79ZGdjZKlMqlAAM3nAMg1qS36E691xMjU5A=.0cecdc0c-cb71-4fd9-96bd-848adeb38016@github.com>
 <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com>
 <zVAsfNnUsxk2grqu8_UB9Lijve5xaSG2o_TU7JopDVA=.c72bce72-4b20-4172-bbeb-3809656d83fb@github.com>
Message-ID: <HY8LGGX1XpvMIwqfOLhIeDS9qMhW0jiZ-DO03-X9I7M=.ce7b6d7a-d0a9-406c-86ff-f59e5e671145@github.com>

On Wed, 9 Feb 2022 21:16:08 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> Nit, add space after "if"
>> 
>> will fix
>
> So a bit more on this.  If the ZipEntry passed to `ZipFile::getInputStream` does not represent an entry within the current Zip/Jar,  `ZipFile::getInputStream` will return a null for the InputStream:
> 
> 
>     @Test
>     public static void ZipFileZipEntryNullGetInputStreamTest() throws Exception {
>         try (ZipFile zf = new ZipFile(VALID_ENTRY_NAME_JAR.toFile())) {
>             var ze = new ZipEntry("org/gotham/Batcave.class");
>             var is = zf.getInputStream(ze);
>             // As the ZipEntry cannot be found, the returned InpuStream is null
>             assertNull(is);
>         }
>     }
> 
> 
>   JarFile::getInputStream will also return null when the jar is not signed or we are not verifying the jar:
> 
> 
>  @Test
>     public static void JarFileZipEntryNullGetInputStreamTest() throws Exception {
>         try (JarFile jf = new JarFile(VALID_ENTRY_NAME_JAR.toFile())) {
>             var ze = new ZipEntry("org/gotham/Batcave.class");
>             var is = jf.getInputStream(ze);
>             // As the ZipEntry cannot be found, the returned InpuStream is null
>             assertNull(is);
>         }
> 
>         try (JarFile jf = new JarFile(SIGNED_INVALID_ENTRY_NAME_JAR.toFile(), false)) {
>             var ze = new ZipEntry("org/gotham/Batcave.class");
>             var is = jf.getInputStream(ze);
>             // As the ZipEntry cannot be found, the returned InpuStream is null
>             assertNull(is);
>         }
>     }
> 
> 
> 
> This behavior dates back to at least JDK 1.3
> 
> So I think we should return null  instead of throwing an Exception when the resulting ZipEntry is null that is returned from the call to`JarFile::getJarEntry` (which calls `ZipFile::getEntry`) for consistency with ZipFile and when the Jar is not signed or not verified.
> 
> I also noticed that `ZipFile::getInputStream` and `JarFile::getInputStream` do not mention that a null will be returned if the specified ZipEntry is not found within the Jar/Zip.  I guess I could open a CSR as part of this fix to clarify this 20+ year behavior.

Agree on returning null to maintain current behavior. I would also lean towards amending the specification to specify what has been long-standing behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Thu Feb 10 20:41:35 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 10 Feb 2022 20:41:35 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <HY8LGGX1XpvMIwqfOLhIeDS9qMhW0jiZ-DO03-X9I7M=.ce7b6d7a-d0a9-406c-86ff-f59e5e671145@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <FvpMWBZG79ZGdjZKlMqlAAM3nAMg1qS36E691xMjU5A=.0cecdc0c-cb71-4fd9-96bd-848adeb38016@github.com>
 <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com>
 <zVAsfNnUsxk2grqu8_UB9Lijve5xaSG2o_TU7JopDVA=.c72bce72-4b20-4172-bbeb-3809656d83fb@github.com>
 <HY8LGGX1XpvMIwqfOLhIeDS9qMhW0jiZ-DO03-X9I7M=.ce7b6d7a-d0a9-406c-86ff-f59e5e671145@github.com>
Message-ID: <NiAOT1qeCbPFgSC8hBlHpRt9NwknVP8pHt23D0BTNAA=.4e5eaac1-ab52-4ca8-b3f6-5e2515b8476d@github.com>

On Thu, 10 Feb 2022 20:35:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> So a bit more on this.  If the ZipEntry passed to `ZipFile::getInputStream` does not represent an entry within the current Zip/Jar,  `ZipFile::getInputStream` will return a null for the InputStream:
>> 
>> 
>>     @Test
>>     public static void ZipFileZipEntryNullGetInputStreamTest() throws Exception {
>>         try (ZipFile zf = new ZipFile(VALID_ENTRY_NAME_JAR.toFile())) {
>>             var ze = new ZipEntry("org/gotham/Batcave.class");
>>             var is = zf.getInputStream(ze);
>>             // As the ZipEntry cannot be found, the returned InpuStream is null
>>             assertNull(is);
>>         }
>>     }
>> 
>> 
>>   JarFile::getInputStream will also return null when the jar is not signed or we are not verifying the jar:
>> 
>> 
>>  @Test
>>     public static void JarFileZipEntryNullGetInputStreamTest() throws Exception {
>>         try (JarFile jf = new JarFile(VALID_ENTRY_NAME_JAR.toFile())) {
>>             var ze = new ZipEntry("org/gotham/Batcave.class");
>>             var is = jf.getInputStream(ze);
>>             // As the ZipEntry cannot be found, the returned InpuStream is null
>>             assertNull(is);
>>         }
>> 
>>         try (JarFile jf = new JarFile(SIGNED_INVALID_ENTRY_NAME_JAR.toFile(), false)) {
>>             var ze = new ZipEntry("org/gotham/Batcave.class");
>>             var is = jf.getInputStream(ze);
>>             // As the ZipEntry cannot be found, the returned InpuStream is null
>>             assertNull(is);
>>         }
>>     }
>> 
>> 
>> 
>> This behavior dates back to at least JDK 1.3
>> 
>> So I think we should return null  instead of throwing an Exception when the resulting ZipEntry is null that is returned from the call to`JarFile::getJarEntry` (which calls `ZipFile::getEntry`) for consistency with ZipFile and when the Jar is not signed or not verified.
>> 
>> I also noticed that `ZipFile::getInputStream` and `JarFile::getInputStream` do not mention that a null will be returned if the specified ZipEntry is not found within the Jar/Zip.  I guess I could open a CSR as part of this fix to clarify this 20+ year behavior.
>
> Agree on returning null to maintain current behavior. I would also lean towards amending the specification to specify what has been long-standing behavior.

If we had to do it over again, I do think throwing IAE is more appropriate because this case would probably be due to a bug in the application code. Now code has to defensively check for a null return value. I don't know, maybe we don't want to modify the specification at this point and leave this as undefined behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From weijun at openjdk.java.net  Thu Feb 10 21:14:17 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Feb 2022 21:14:17 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName [v3]
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <_iTerqtJkc7suwgbIF29UxeeFjfH521df3Xz9WvB6gA=.69b2efa4-23f2-4444-afbb-3a3053a956b6@github.com>

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more precise spec

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7167/files
  - new: https://git.openjdk.java.net/jdk/pull/7167/files/e6e5558b..11e8f6d1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=01-02

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 10 21:14:18 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Feb 2022 21:14:18 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName [v2]
In-Reply-To: <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>
Message-ID: <YCN0E4VULwKONmndkd1rqlFaR90zcCBGMlgvzXrmGoM=.82e5aa11-d1f4-41a9-9295-c947a4b6f7f9@github.com>

On Thu, 10 Feb 2022 16:47:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wording, title

Your words are more precise. A reader should check the size first. A new commit pushed and the CSR is also updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From lancea at openjdk.java.net  Thu Feb 10 21:35:56 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 10 Feb 2022 21:35:56 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v3]
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com>

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with two additional commits since the last revision:

 - Return a null InputStream when the ZipEntry is not found in the Jar
 - Address formatting and message feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7348/files
  - new: https://git.openjdk.java.net/jdk/pull/7348/files/6c75384a..32f6c284

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=01-02

  Stats: 95 lines in 3 files changed: 41 ins; 20 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Thu Feb 10 21:35:57 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 10 Feb 2022 21:35:57 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v2]
In-Reply-To: <NiAOT1qeCbPFgSC8hBlHpRt9NwknVP8pHt23D0BTNAA=.4e5eaac1-ab52-4ca8-b3f6-5e2515b8476d@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <jKlRl3rexi2SHgE8ClPiGD2XhZQGA5F7sZ4wiIodt7w=.de8f6576-15fe-4a93-8904-47572f9ecdbd@github.com>
 <w4NycSD16SmK31rXkwU2yoKJHFyAqhWMaPH_NGQqHfE=.5ff5b42c-4d81-4e0f-807e-26db495b679b@github.com>
 <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com>
 <FvpMWBZG79ZGdjZKlMqlAAM3nAMg1qS36E691xMjU5A=.0cecdc0c-cb71-4fd9-96bd-848adeb38016@github.com>
 <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com>
 <zVAsfNnUsxk2grqu8_UB9Lijve5xaSG2o_TU7JopDVA=.c72bce72-4b20-4172-bbeb-3809656d83fb@github.com>
 <HY8LGGX1XpvMIwqfOLhIeDS9qMhW0jiZ-DO03-X9I7M=.ce7b6d7a-d0a9-406c-86ff-f59e5e671145@github.com>
 <NiAOT1qeCbPFgSC8hBlHpRt9NwknVP8pHt23D0BTNAA=.4e5eaac1-ab52-4ca8-b3f6-5e2515b8476d@github.com>
Message-ID: <JsULvKiAIKFKdVcJjr60cNufzrkXrWd4xE-QPFb_7os=.36781d8e-e79e-4cb5-a8e8-940a4c3b12e1@github.com>

On Thu, 10 Feb 2022 20:37:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Agree on returning null to maintain current behavior. I would also lean towards amending the specification to specify what has been long-standing behavior.
>
> If we had to do it over again, I do think throwing IAE is more appropriate because this case would probably be due to a bug in the application code. Now code has to defensively check for a null return value. I don't know, maybe we don't want to modify the specification at this point and leave this as undefined behavior.

> Agree on returning null to maintain current behavior. I would also lean towards amending the specification to specify what has been long-standing behavior.

I just updated the PR to return null

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From dholmes at openjdk.java.net  Thu Feb 10 23:24:11 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Feb 2022 23:24:11 GMT
Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc
In-Reply-To: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
References: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
Message-ID: <gNCEsWHLoCaCXEcBoDBdbYwkOzaU0kfg6ETTiY3B6eo=.03139b10-04c8-4cfb-ba58-122f95ec9b78@github.com>

On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.

Looks fine. The proof of these changes is in compiling the files - how did you test the non-gc-test changes?

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7426

From dholmes at openjdk.java.net  Thu Feb 10 23:33:09 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Feb 2022 23:33:09 GMT
Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc
In-Reply-To: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
References: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
Message-ID: <bqegymgOsLLZC3MT1x8Jbj0nvCJUoAYz53h8_v1JD40=.ba7132c8-7bc2-4edf-b2cf-217a98a8b90e@github.com>

On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.

Forgot to mention copyright years need updating before integrating! Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7426

From xuelei at openjdk.java.net  Fri Feb 11 00:03:12 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 11 Feb 2022 00:03:12 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake
In-Reply-To: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
References: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
Message-ID: <Q7x5mhXtwXRktLCpDtsT2bk4N104PTnwBp2LPYzmo50=.24e1ae00-c5d8-4949-bd79-8757aa9265ed@github.com>

On Thu, 10 Feb 2022 18:19:41 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the patch for the JDK-8274524
> 
> SSLSocket.close() could cause an intermittent hang of the socket read operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
> SSLSocket.close() reads from the socket as part of the skip() operation to prevent TCP Connection reset (see JDK-8268965). Socket reads are performed in a loop for small chunks. These read operations could cause a deadlock, in case of SO_TIMEOUT = 0
> I suggest to force non-zero SO_TIMEOUT during the skip() operation to prevent such deadlock
> 
> This is a second iteration of review. Previous PR was closed without integration: https://github.com/openjdk/jdk/pull/5760

src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1792:

> 1790:                     try {
> 1791:                         if (soTimeout == 0)
> 1792:                             setSoTimeout(DEFAULT_SKIP_TIMEOUT);

This set will impact the socket overall behavior unexpectedly, not just the close() method.

Maybe, an input stream level synchronization is missed in the SSLSocketInputRecord method, so that logic of deplete could be interrupted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7432

From lkorinth at openjdk.java.net  Fri Feb 11 08:54:51 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Fri, 11 Feb 2022 08:54:51 GMT
Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc
 [v2]
In-Reply-To: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
References: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
Message-ID: <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>

> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  updating copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7426/files
  - new: https://git.openjdk.java.net/jdk/pull/7426/files/6aaa1a3a..7d3e7a1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=00-01

  Stats: 59 lines in 59 files changed: 0 ins; 0 del; 59 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7426.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7426/head:pull/7426

PR: https://git.openjdk.java.net/jdk/pull/7426

From lkorinth at openjdk.java.net  Fri Feb 11 09:01:06 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Fri, 11 Feb 2022 09:01:06 GMT
Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc
 [v2]
In-Reply-To: <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>
References: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
 <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>
Message-ID: <VVVpzoFDz5orsHkmEMALgrVU4bFR32pasfx0pbJ8r6s=.91156db9-c115-49bf-b131-a3031c307920@github.com>

On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating copyright

I have a maven project that compiles test/lib and jtreg/gc, so everything changed does compile, I should have mentioned that. I have updated copyright year on all files now as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7426

From abakhtin at openjdk.java.net  Fri Feb 11 09:30:08 2022
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 11 Feb 2022 09:30:08 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake
In-Reply-To: <Q7x5mhXtwXRktLCpDtsT2bk4N104PTnwBp2LPYzmo50=.24e1ae00-c5d8-4949-bd79-8757aa9265ed@github.com>
References: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
 <Q7x5mhXtwXRktLCpDtsT2bk4N104PTnwBp2LPYzmo50=.24e1ae00-c5d8-4949-bd79-8757aa9265ed@github.com>
Message-ID: <DRc35X_SkNGloXiW6-aNw6jXU6hIZ8WiH4eaOxzQ_3I=.88530f89-c0e1-4deb-b9af-b35a5ae652d2@github.com>

On Thu, 10 Feb 2022 23:59:40 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review the patch for the JDK-8274524
>> 
>> SSLSocket.close() could cause an intermittent hang of the socket read operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
>> SSLSocket.close() reads from the socket as part of the skip() operation to prevent TCP Connection reset (see JDK-8268965). Socket reads are performed in a loop for small chunks. These read operations could cause a deadlock, in case of SO_TIMEOUT = 0
>> I suggest to force non-zero SO_TIMEOUT during the skip() operation to prevent such deadlock
>> 
>> This is a second iteration of review. Previous PR was closed without integration: https://github.com/openjdk/jdk/pull/5760
>
> src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1792:
> 
>> 1790:                     try {
>> 1791:                         if (soTimeout == 0)
>> 1792:                             setSoTimeout(DEFAULT_SKIP_TIMEOUT);
> 
> This set will impact the socket overall behavior unexpectedly, not just the close() method.
> 
> Maybe, an input stream level synchronization is missed in the SSLSocketInputRecord method, so that logic of deplete could be interrupted.

Hi @XueleiFan,
Not quite sure What could be wrong with setting SO_TIMEOUT during the socketClose() operation. We still close the socket and SO_TIMEOUT will be restored just after skip() operation is completed. These changes could affect the parallel read of the handshake records (we hold appInput.readLock during the skip) but we still close the socket and interrupt connection in this case.
If you still think these changes are incorrect, What do you think about the most first version of the patch: https://github.com/openjdk/jdk/pull/7432/commits/d1c2a4fe23916ff0f1c38150bc0ea1c9c38fe39b
This version adds a new lock in the SSLSocketInputRecord and protects the parallel execution of the read and skip operations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7432

From sspitsyn at openjdk.java.net  Fri Feb 11 10:14:09 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 11 Feb 2022 10:14:09 GMT
Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc
 [v2]
In-Reply-To: <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>
References: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
 <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>
Message-ID: <t48vN2sCao318iQAU2AADAZvSsLLsqOs-NsKs9R26WU=.7868baf5-ca77-4808-9e34-8a52f452c6f2@github.com>

On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating copyright

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7426

From duke at openjdk.java.net  Fri Feb 11 11:15:56 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 11 Feb 2022 11:15:56 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v5]
In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
Message-ID: <Te1KpLONBYNa5TcUWRdG4uDaP1jxivPswy7NThUqOHA=.ad608cd8-d346-4668-9ac2-e892f584cf68@github.com>

> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
> JDK-8273142
> JDK-8268464
> JDK-8268133

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  1. Handled continuation line
  2. handled \r, \n, or \r\n
  3. Added the test for HttpHeaderParser class

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5937/files
  - new: https://git.openjdk.java.net/jdk/pull/5937/files/6f4b7d3a..70a37be9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=03-04

  Stats: 857 lines in 11 files changed: 812 ins; 10 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937

PR: https://git.openjdk.java.net/jdk/pull/5937

From dholmes at openjdk.java.net  Fri Feb 11 13:01:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Feb 2022 13:01:04 GMT
Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc
 [v2]
In-Reply-To: <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>
References: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
 <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>
Message-ID: <j_McUJTi9SjzQn5HR7wI1D65_B4Neet6gdKVHUX8Hq8=.65d4186a-b537-4b95-aef2-f02980a32a5e@github.com>

On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating copyright

Looks good.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7426

From alanb at openjdk.java.net  Fri Feb 11 13:49:09 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 11 Feb 2022 13:49:09 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v3]
In-Reply-To: <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com>
Message-ID: <Cjl5qGHuvSPFWwWf7Zm1FP44-qcS-sRopciQW4P-1ig=.64d57672-5adb-43b0-92bb-e78f3352fab7@github.com>

On Thu, 10 Feb 2022 21:35:56 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the attached patch to address
>> 
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
>> 
>> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Return a null InputStream when the ZipEntry is not found in the Jar
>  - Address formatting and message feedback

src/java.base/share/classes/java/util/jar/JarFile.java line 881:

> 879:             ze = getJarEntry(entryName);
> 880:         } else {
> 881:             throw new ZipException("ZipEntry::getName returned null");

Throwing ZipException when ZipEntry::getName returns null is still surprising but not terrible.  The spec for getInputStream specifies ZipException for when a zip file format occurs so we might have to extend that to add "or the zip entry name is null".

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From mullan at openjdk.java.net  Fri Feb 11 15:02:09 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 11 Feb 2022 15:02:09 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName [v3]
In-Reply-To: <_iTerqtJkc7suwgbIF29UxeeFjfH521df3Xz9WvB6gA=.69b2efa4-23f2-4444-afbb-3a3053a956b6@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_iTerqtJkc7suwgbIF29UxeeFjfH521df3Xz9WvB6gA=.69b2efa4-23f2-4444-afbb-3a3053a956b6@github.com>
Message-ID: <jAGSDjCZkJihq5hl2Fw7quq5JaL1UsQuwBHfFONhJ2U=.60a80e1e-7d11-4935-a064-8f1c6b78b5e3@github.com>

On Thu, 10 Feb 2022 21:14:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more precise spec

src/java.base/share/classes/java/security/cert/X509Certificate.java line 594:

> 592:      * a third entry in the list containing its {@code type-id} in string
> 593:      * format, and a fourth entry containing the ASN.1 DER encoding of
> 594:      * its {@code value} without the context-specific constructed tag

To be very specific, I would add that the 4th entry is a byte array, ex: "and a fourth entry as a byte array containing the ASN.1 DER encoding ..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Fri Feb 11 17:13:46 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 11 Feb 2022 17:13:46 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  specifies the type of the 4th element

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7167/files
  - new: https://git.openjdk.java.net/jdk/pull/7167/files/11e8f6d1..bca0b6d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Fri Feb 11 17:13:49 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 11 Feb 2022 17:13:49 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName [v3]
In-Reply-To: <jAGSDjCZkJihq5hl2Fw7quq5JaL1UsQuwBHfFONhJ2U=.60a80e1e-7d11-4935-a064-8f1c6b78b5e3@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_iTerqtJkc7suwgbIF29UxeeFjfH521df3Xz9WvB6gA=.69b2efa4-23f2-4444-afbb-3a3053a956b6@github.com>
 <jAGSDjCZkJihq5hl2Fw7quq5JaL1UsQuwBHfFONhJ2U=.60a80e1e-7d11-4935-a064-8f1c6b78b5e3@github.com>
Message-ID: <rksDCuz2420xySpE2Nk426Pa1RzIISXDwakq6FduB6o=.26ae9f57-6f21-488c-8a66-573e8012769f@github.com>

On Fri, 11 Feb 2022 14:58:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more precise spec
>
> src/java.base/share/classes/java/security/cert/X509Certificate.java line 594:
> 
>> 592:      * a third entry in the list containing its {@code type-id} in string
>> 593:      * format, and a fourth entry containing the ASN.1 DER encoding of
>> 594:      * its {@code value} without the context-specific constructed tag
> 
> To be very specific, I would add that the 4th entry is a byte array, ex: "and a fourth entry as a byte array containing the ASN.1 DER encoding ..."

Good idea. Fixed and updated the CSR as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From mullan at openjdk.java.net  Fri Feb 11 17:29:08 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 11 Feb 2022 17:29:08 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certiticate::getSubjectAlternativeNames and
 X509Certiticate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
Message-ID: <oSFlZkDrNPe27BXgTK7IeGOgjKVIZGEkiSf9ybPZOxQ=.d57950d7-1610-4316-88c8-d37704ecdd9f@github.com>

On Fri, 11 Feb 2022 17:13:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   specifies the type of the 4th element

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From lancea at openjdk.java.net  Fri Feb 11 17:50:09 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 11 Feb 2022 17:50:09 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v3]
In-Reply-To: <Cjl5qGHuvSPFWwWf7Zm1FP44-qcS-sRopciQW4P-1ig=.64d57672-5adb-43b0-92bb-e78f3352fab7@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com>
 <Cjl5qGHuvSPFWwWf7Zm1FP44-qcS-sRopciQW4P-1ig=.64d57672-5adb-43b0-92bb-e78f3352fab7@github.com>
Message-ID: <0COr36OwTtowa8BVOnS_ZSR7mhByee9jwWl6f-4ps3E=.1969f9d1-bbae-45bb-818f-cfa7864a802d@github.com>

On Fri, 11 Feb 2022 13:45:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Return a null InputStream when the ZipEntry is not found in the Jar
>>  - Address formatting and message feedback
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 881:
> 
>> 879:             ze = getJarEntry(entryName);
>> 880:         } else {
>> 881:             throw new ZipException("ZipEntry::getName returned null");
> 
> Throwing ZipException when ZipEntry::getName returns null is still surprising but not terrible.  The spec for getInputStream specifies ZipException for when a zip file format occurs so we might have to extend that to add "or the zip entry name is null".

If you  would like me to update the ZipException to clarify this I can.   The original issue was due to a format error in the CEN so the current wording covers that.  It does not cover the case where ZipEntry is subclassed and ZipEntry::getName() returns null which is what your suggested wording would address.

Please note the above change addresses the signed jar scenario.  I can add an additional check in JarFile::getInputStream to check for null from ZipEntry::getName so that it covers unsigned jars and signed jars not being verified.

The issue will not occur with ZipEntry::getInputStream given its use of ZipEntry.name which can never be null.

Please let me know your preference

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From xuelei at openjdk.java.net  Fri Feb 11 18:08:14 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 11 Feb 2022 18:08:14 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake
In-Reply-To: <DRc35X_SkNGloXiW6-aNw6jXU6hIZ8WiH4eaOxzQ_3I=.88530f89-c0e1-4deb-b9af-b35a5ae652d2@github.com>
References: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
 <Q7x5mhXtwXRktLCpDtsT2bk4N104PTnwBp2LPYzmo50=.24e1ae00-c5d8-4949-bd79-8757aa9265ed@github.com>
 <DRc35X_SkNGloXiW6-aNw6jXU6hIZ8WiH4eaOxzQ_3I=.88530f89-c0e1-4deb-b9af-b35a5ae652d2@github.com>
Message-ID: <O_aOUcX_0RcIH1AxI0cTHrClbZY3g41SaPaANZVC3ls=.35c2c30d-d9fa-45d5-bf20-831b55262676@github.com>

On Fri, 11 Feb 2022 09:27:11 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1792:
>> 
>>> 1790:                     try {
>>> 1791:                         if (soTimeout == 0)
>>> 1792:                             setSoTimeout(DEFAULT_SKIP_TIMEOUT);
>> 
>> This set will impact the socket overall behavior unexpectedly, not just the close() method.
>> 
>> Maybe, an input stream level synchronization is missed in the SSLSocketInputRecord method, so that logic of deplete could be interrupted.
>
> Hi @XueleiFan,
> Not quite sure What could be wrong with setting SO_TIMEOUT during the socketClose() operation. We still close the socket and SO_TIMEOUT will be restored just after skip() operation is completed. These changes could affect the parallel read of the handshake records (we hold appInput.readLock during the skip) but we still close the socket and interrupt connection in this case.
> If you still think these changes are incorrect, What do you think about the most first version of the patch: https://github.com/openjdk/jdk/pull/7432/commits/d1c2a4fe23916ff0f1c38150bc0ea1c9c38fe39b
> This version adds a new lock in the SSLSocketInputRecord and protects the parallel execution of the read and skip operations.

If I understand the issue correctly, the problem is about that the skip method cannot get the right length if the input stream could be accessed in another thread.

1. get the available input stream bytes length;
2. a third thread read the input stream, and the input stream get changed;
3. skip up to the bytes length in step 1.
4. the skip() method hangs on waiting for more bytes.

I think we could focus on on address the synchronization problem, because the problem could result in other weird behaviors we don't know yet.

For the SO_TIMEOUT, I think it is a good workaround.  But I'm not sure if it will impact other behaviors or not.  Besides, I know you are trying to use a small timeout, but it is still blocked and it not easy to find a number fit all situation that does not impact the performance.

As I commented in the 1st version, I'm not sure of the locks logic in the patch, which changes the behavior of SSLSocket.

I may suggest to an input stream level synchronization.  I know the update could take a while, and may not be able to  integrate in time.  If you want to fix the issue as soon as possible, I'm OK to move ahead with your current direction, but please set the SO_TIMEOUT to as minimal as possible, for example 1 ms; and have a comment that this is a temporary/workaround solution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7432

From abakhtin at openjdk.java.net  Fri Feb 11 20:00:05 2022
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 11 Feb 2022 20:00:05 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake
In-Reply-To: <O_aOUcX_0RcIH1AxI0cTHrClbZY3g41SaPaANZVC3ls=.35c2c30d-d9fa-45d5-bf20-831b55262676@github.com>
References: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
 <Q7x5mhXtwXRktLCpDtsT2bk4N104PTnwBp2LPYzmo50=.24e1ae00-c5d8-4949-bd79-8757aa9265ed@github.com>
 <DRc35X_SkNGloXiW6-aNw6jXU6hIZ8WiH4eaOxzQ_3I=.88530f89-c0e1-4deb-b9af-b35a5ae652d2@github.com>
 <O_aOUcX_0RcIH1AxI0cTHrClbZY3g41SaPaANZVC3ls=.35c2c30d-d9fa-45d5-bf20-831b55262676@github.com>
Message-ID: <ZblVp46KksZhkaN6sRzr5srnZwDtlw5vK7C5Tokca_A=.aac98d8b-7ec6-4f88-b4df-5f890b97c721@github.com>

On Fri, 11 Feb 2022 18:04:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi @XueleiFan,
>> Not quite sure What could be wrong with setting SO_TIMEOUT during the socketClose() operation. We still close the socket and SO_TIMEOUT will be restored just after skip() operation is completed. These changes could affect the parallel read of the handshake records (we hold appInput.readLock during the skip) but we still close the socket and interrupt connection in this case.
>> If you still think these changes are incorrect, What do you think about the most first version of the patch: https://github.com/openjdk/jdk/pull/7432/commits/d1c2a4fe23916ff0f1c38150bc0ea1c9c38fe39b
>> This version adds a new lock in the SSLSocketInputRecord and protects the parallel execution of the read and skip operations.
>
> If I understand the issue correctly, the problem is about that the skip method cannot get the right length if the input stream could be accessed in another thread.
> 
> 1. get the available input stream bytes length;
> 2. a third thread read the input stream, and the input stream get changed;
> 3. skip up to the bytes length in step 1.
> 4. the skip() method hangs on waiting for more bytes.
> 
> I think we could focus on on address the synchronization problem, because the problem could result in other weird behaviors we don't know yet.
> 
> For the SO_TIMEOUT, I think it is a good workaround.  But I'm not sure if it will impact other behaviors or not.  Besides, I know you are trying to use a small timeout, but it is still blocked and it not easy to find a number fit all situation that does not impact the performance.
> 
> As I commented in the 1st version, I'm not sure of the locks logic in the patch, which changes the behavior of SSLSocket.
> 
> I may suggest to an input stream level synchronization.  I know the update could take a while, and may not be able to  integrate in time.  If you want to fix the issue as soon as possible, I'm OK to move ahead with your current direction, but please set the SO_TIMEOUT to as minimal as possible, for example 1 ms; and have a comment that this is a temporary/workaround solution.

Thank you again for your detailed response and comments.
Your assumption about this issue is right and I think SO_TIMEOUT should be an acceptable solution.
I've changed DEFAULT_SKIP_TIMEOUT to 1 ms and added comments about a temporary workaround.
If you don't mind, I'd like to commit it asap because this patch should be backported to the early versions.

No regressions were found on the sun/security/ssl tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7432

From abakhtin at openjdk.java.net  Fri Feb 11 20:07:43 2022
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 11 Feb 2022 20:07:43 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v2]
In-Reply-To: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
References: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
Message-ID: <q7snffHxh3aL_b0MkVtCEuYH4Hm3ingGIbL7vpaOfPc=.d1e5becc-5392-444b-8642-3a72275f8677@github.com>

> Please review the patch for the JDK-8274524
> 
> SSLSocket.close() could cause an intermittent hang of the socket read operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
> SSLSocket.close() reads from the socket as part of the skip() operation to prevent TCP Connection reset (see JDK-8268965). Socket reads are performed in a loop for small chunks. These read operations could cause a deadlock, in case of SO_TIMEOUT = 0
> I suggest to force non-zero SO_TIMEOUT during the skip() operation to prevent such deadlock
> 
> This is a second iteration of review. Previous PR was closed without integration: https://github.com/openjdk/jdk/pull/5760

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Change read timeout value for skip

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7432/files
  - new: https://git.openjdk.java.net/jdk/pull/7432/files/7ac94818..6ea30075

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7432&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7432&range=00-01

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7432.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7432/head:pull/7432

PR: https://git.openjdk.java.net/jdk/pull/7432

From xuelei at openjdk.java.net  Fri Feb 11 21:12:05 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 11 Feb 2022 21:12:05 GMT
Subject: RFR: 8274524: SSLSocket.close() hangs if it is called during the
 ssl handshake [v2]
In-Reply-To: <q7snffHxh3aL_b0MkVtCEuYH4Hm3ingGIbL7vpaOfPc=.d1e5becc-5392-444b-8642-3a72275f8677@github.com>
References: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
 <q7snffHxh3aL_b0MkVtCEuYH4Hm3ingGIbL7vpaOfPc=.d1e5becc-5392-444b-8642-3a72275f8677@github.com>
Message-ID: <8IyynLt-snaeuJ2s3bGsMpNObVnQfmJUk0Kbo8bi6Wo=.cede3d39-d6fa-48e7-8c9a-127bd1e226e8@github.com>

On Fri, 11 Feb 2022 20:07:43 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the patch for the JDK-8274524
>> 
>> SSLSocket.close() could cause an intermittent hang of the socket read operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
>> SSLSocket.close() reads from the socket as part of the skip() operation to prevent TCP Connection reset (see JDK-8268965). Socket reads are performed in a loop for small chunks. These read operations could cause a deadlock, in case of SO_TIMEOUT = 0
>> I suggest to force non-zero SO_TIMEOUT during the skip() operation to prevent such deadlock
>> 
>> This is a second iteration of review. Previous PR was closed without integration: https://github.com/openjdk/jdk/pull/5760
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change read timeout value for skip

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7432

From abakhtin at openjdk.java.net  Sat Feb 12 11:58:12 2022
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Sat, 12 Feb 2022 11:58:12 GMT
Subject: Integrated: 8274524: SSLSocket.close() hangs if it is called during
 the ssl handshake
In-Reply-To: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
References: <8dNOEq3svSJUlEIHRFhRbxiHxFSNHi64XzP65XLbBQ8=.8a2ce62c-1bd5-473f-a99e-eb09c751c132@github.com>
Message-ID: <unO6Qt3Of_vHDNXt1ix_PIORjsfyMPzz4UmFWODNsl8=.c4d36db8-18e8-4562-b9c3-c07866820fd9@github.com>

On Thu, 10 Feb 2022 18:19:41 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the patch for the JDK-8274524
> 
> SSLSocket.close() could cause an intermittent hang of the socket read operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
> SSLSocket.close() reads from the socket as part of the skip() operation to prevent TCP Connection reset (see JDK-8268965). Socket reads are performed in a loop for small chunks. These read operations could cause a deadlock, in case of SO_TIMEOUT = 0
> I suggest to force non-zero SO_TIMEOUT during the skip() operation to prevent such deadlock
> 
> This is a second iteration of review. Previous PR was closed without integration: https://github.com/openjdk/jdk/pull/5760

This pull request has now been integrated.

Changeset: 58dae60d
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/58dae60da0711c4ae0cb23f8ce2328e051d603b2
Stats:     151 lines in 2 files changed: 151 ins; 0 del; 0 mod

8274524: SSLSocket.close() hangs if it is called during the ssl handshake

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/7432

From duke at openjdk.java.net  Mon Feb 14 06:48:13 2022
From: duke at openjdk.java.net (BenEfrati)
Date: Mon, 14 Feb 2022 06:48:13 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v4]
In-Reply-To: <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
Message-ID: <sAeprm6PO3YtT79LTSgpX_I9uQaUUV6HWliH_lbZkMI=.6d7781fa-2399-4429-9176-dbda8d8f335e@github.com>

On Fri, 22 Oct 2021 18:45:31 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the small patch for the issue described in JDK-8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key
>> 
>> I suggest updating the RSAPSSSignature.isValid() method to verify if provided key components can be applied to SunRSASign implementation. 
>> If not applied, implementation can try to select signer from other providers
>> 
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified isPrivateKeyValid

Hi, 
I see there is PR to backport to jdk1.
https://github.com/openjdk/jdk17u-dev/pull/157
@alexeybakhtin can it be backported to jdk8u?


Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/4887

From abakhtin at openjdk.java.net  Mon Feb 14 08:32:15 2022
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 14 Feb 2022 08:32:15 GMT
Subject: RFR: 8271199: Mutual TLS handshake fails signing client
 certificate with custom sensitive PKCS11 key [v4]
In-Reply-To: <YbEPYuD8WbZ2hr-t6LQXpyr9PUMTsDrhmUNt-zDCjuw=.f7d0f9cf-0bfb-4440-91bd-a75262a30d25@github.com>
References: <Ssgt0_fYuMZjsAIDK0r-1qgGtiB84AFVYPMfEmv_YgQ=.594c80ed-975d-4e5c-958d-a5bfcae9c58f@github.com>
 <g3_-0EXMT6FO5PyQT7IYU6Xwy9_Fyay52AnQ_flAVW4=.e114f2af-c921-4cd0-8fb4-44707a9c4ad8@github.com>
 <YbEPYuD8WbZ2hr-t6LQXpyr9PUMTsDrhmUNt-zDCjuw=.f7d0f9cf-0bfb-4440-91bd-a75262a30d25@github.com>
Message-ID: <cBK1cRvhD-_HKg8OgCr_8z6imnvyDQlYvrtzrYvFNmc=.58a083f8-f623-4102-81b8-d3187c103339@github.com>

On Thu, 10 Feb 2022 14:39:50 GMT, Martin Bonato <duke at openjdk.java.net> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified isPrivateKeyValid
>
> Is there any chance to get this back-ported to 11u? I saw the instructions for fix approvals on https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u however I'm not a contributor/author. Is there any means of showing interest or upvoting etc.?

Hi @mbonato @BenEfrati 
Yes, I have plans to backport it to jdk8u and jdk11u but it could take some time. Several other enhancements should be backported first to make a clean backport to JDK8 and 11.
By the way, this fix is already available in the latest Zulu8u release and will be available in the April Zulu11u release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4887

From lkorinth at openjdk.java.net  Mon Feb 14 12:08:12 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Mon, 14 Feb 2022 12:08:12 GMT
Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc
 [v2]
In-Reply-To: <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>
References: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
 <TI1tBVjplEhphoHzgP6aj2kT2tt_GlhCiCkcpSA1f6w=.84d16506-5ed6-48fd-86f2-b7321d831444@github.com>
Message-ID: <YrQZLmQ_E0CymQDNGWvrWvdf8HetQu_r4RPZ5-vg9CU=.056b5ea7-1e62-4794-87d3-45c0beb8fd88@github.com>

On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating copyright

Thanks David and Serguei!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7426

From lkorinth at openjdk.java.net  Mon Feb 14 12:08:13 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Mon, 14 Feb 2022 12:08:13 GMT
Subject: Integrated: 8281585: Remove unused imports under test/lib and jtreg/gc
In-Reply-To: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
References: <h90_aeouWu61wQWZosouJTUIwlE5rCP9fkXpjhdYSLk=.5e8ea5c8-6919-4451-97cc-9982f835d636@github.com>
Message-ID: <sWUohWI0UjvTZcEoutCYu2f-nmyo5fTH6iCyyy_jxEU=.3fc25386-6e28-4103-8595-7df504ae0544@github.com>

On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed.

This pull request has now been integrated.

Changeset: 2604a88f
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2604a88fbb6d0f9aec51c7d607ea275bc34a672c
Stats:     151 lines in 60 files changed: 0 ins; 92 del; 59 mod

8281585: Remove unused imports under test/lib and jtreg/gc

Reviewed-by: dholmes, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7426

From duke at openjdk.java.net  Mon Feb 14 18:03:16 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Mon, 14 Feb 2022 18:03:16 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v5]
In-Reply-To: <Te1KpLONBYNa5TcUWRdG4uDaP1jxivPswy7NThUqOHA=.ad608cd8-d346-4668-9ac2-e892f584cf68@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
 <Te1KpLONBYNa5TcUWRdG4uDaP1jxivPswy7NThUqOHA=.ad608cd8-d346-4668-9ac2-e892f584cf68@github.com>
Message-ID: <zC5pJIVthqr7Y2mYPMnmVDONqoOaXENMjJ9IpIM2PMY=.e60f8984-5070-41c7-a964-7964bc333720@github.com>

On Fri, 11 Feb 2022 11:15:56 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
>> JDK-8273142
>> JDK-8268464
>> JDK-8268133
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. Handled continuation line
>   2. handled \r, \n, or \r\n
>   3. Added the test for HttpHeaderParser class

Mach5 results : https://mach5.us.oracle.com/mdash/jobs/mahendrachhipa-jdk-20220210-1911-29009006

-------------

PR: https://git.openjdk.java.net/jdk/pull/5937

From duke at openjdk.java.net  Tue Feb 15 08:56:08 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 08:56:08 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v2]
In-Reply-To: <YCN0E4VULwKONmndkd1rqlFaR90zcCBGMlgvzXrmGoM=.82e5aa11-d1f4-41a9-9295-c947a4b6f7f9@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>
 <YCN0E4VULwKONmndkd1rqlFaR90zcCBGMlgvzXrmGoM=.82e5aa11-d1f4-41a9-9295-c947a4b6f7f9@github.com>
Message-ID: <Ts3ikO5YBqtIi2WgVSjszhwiAJHYPGYXCGdWv4JguLY=.26ab6559-06dd-4808-94af-cc8e1899683b@github.com>

On Thu, 10 Feb 2022 21:09:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   wording, title
>
> Your words are more precise. A reader should check the size first. A new commit pushed and the CSR is also updated.

@wangweij I would highly recommend to address this ticket first: https://bugs.openjdk.java.net/browse/JDK-6776681. It is partially related.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 09:13:12 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 09:13:12 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
Message-ID: <MtWZUyq6H7Mp-1ZHPfJHZK0t71Qr64mbO4W7zrOHG78=.1f5ec5ff-bf95-4495-9ddc-3deca7bb253e@github.com>

On Fri, 11 Feb 2022 17:13:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   specifies the type of the 4th element

src/java.base/share/classes/sun/security/x509/OtherName.java line 93:

> 91:         oid = in.getOID();
> 92:         DerValue derValue1 = in.getDerValue();
> 93:         if (!derValue1.isContextSpecific((byte)0)) {

Where do you check for constructed (0x20)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 09:19:09 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 09:19:09 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
Message-ID: <nsMD5l1puhQjSdZcnVQAvJnnj_bqyceryQV8K5ypuog=.7b05e2c1-02b5-4bc2-915f-a231b15da951@github.com>

On Fri, 11 Feb 2022 17:13:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   specifies the type of the 4th element

test/jdk/sun/security/x509/OtherName/Parse.java line 86:

> 84:         int found = 0;
> 85:         for (var san : x.getSubjectAlternativeNames()) {
> 86:             if (san.get(2).equals("1.2.3.5")

Would it make sense to explicitly test length for at least 4?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 09:29:13 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 09:29:13 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v2]
In-Reply-To: <YCN0E4VULwKONmndkd1rqlFaR90zcCBGMlgvzXrmGoM=.82e5aa11-d1f4-41a9-9295-c947a4b6f7f9@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>
 <YCN0E4VULwKONmndkd1rqlFaR90zcCBGMlgvzXrmGoM=.82e5aa11-d1f4-41a9-9295-c947a4b6f7f9@github.com>
Message-ID: <lDWLbs70HSFnlbxPJCWAUpgYwgvth3ekSzYkg211nIg=.ba5194c2-8094-426a-aeff-6e98b2fbbad9@github.com>

On Thu, 10 Feb 2022 21:09:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   wording, title
>
> Your words are more precise. A reader should check the size first. A new commit pushed and the CSR is also updated.

@wangweij Any chance to evaluate this comment from me: https://bugs.openjdk.java.net/browse/JDK-8277976?focusedCommentId=14462729&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14462729?
Automatic mapping of the value if it is a ASN.1 simple type to a Java type like done for the remaining general names? At least strings would be straight forward and cover many cases, e.g., MS UPN (1.3.6.1.4.1.311.20.2.3).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From dfuchs at openjdk.java.net  Tue Feb 15 13:15:06 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 15 Feb 2022 13:15:06 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v5]
In-Reply-To: <Te1KpLONBYNa5TcUWRdG4uDaP1jxivPswy7NThUqOHA=.ad608cd8-d346-4668-9ac2-e892f584cf68@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
 <Te1KpLONBYNa5TcUWRdG4uDaP1jxivPswy7NThUqOHA=.ad608cd8-d346-4668-9ac2-e892f584cf68@github.com>
Message-ID: <QLFmezE9aQUWu_3bCAXfOHZ5xT3eLV301WyEaUSnUq4=.bf7a71f0-5295-4d2a-a2f9-d987bd1b75bf@github.com>

On Fri, 11 Feb 2022 11:15:56 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
>> JDK-8273142
>> JDK-8268464
>> JDK-8268133
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. Handled continuation line
>   2. handled \r, \n, or \r\n
>   3. Added the test for HttpHeaderParser class

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 100:

> 98:     public List<String> getHeaderValue(String key) {
> 99:         if(headerMap.containsKey(key.toLowerCase())) {
> 100:             return headerMap.get(key.toLowerCase());

I'd suggest to use `key.toLowerCase(Locale.ROOT)` - even though it shouldn't really matter if it's guaranteed that keys have been syntactically checked for illegal characters.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 120:

> 118:      * ( when true is returned ), which may not be fully consumed.
> 119:      *
> 120:      * @param input the ( partial ) header data

It doesn't look like this is a accurate. There's no ByteBuffers anywhere...

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 148:

> 146:             case FINISHED -> false;
> 147:             case STATUS_LINE_FOUND_LF, STATUS_LINE_END_LF, HEADER_FOUND_LF -> true;
> 148:             default -> buffer.available() >= 0;

It's a bit chancy to use InputStream.available() - it would be better to have some `eof` variable that's set to true when EOF is reached, and return `!eof` here

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 162:

> 160:      * value from [0, 255] representing the character code.
> 161:      *
> 162:      * @param input a {@code ByteBuffer} containing a partial input

Input is not a ByteBuffer and it doesn't contain a partial input.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 171:

> 169:     private char get(InputStream input) throws IOException {
> 170:         return (char)(input.read() & 0xFF);
> 171:     }

That doesn't look right as it will prevent you to read EOF. Maybe it should be:

    boolean eof;
    ...
    private int get(InputStream input) throws IOException {
         int c = input.read();
         if (c < 0) eof = true;
         return c;
    }


And then you would have to check for EOF everywhere where `get(input)` is called too.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 175:

> 173:     private void readResumeStatusLine(InputStream input) throws IOException {
> 174:         char c = 0;
> 175:         while (input.available() > 0 && (c = get(input)) != CR) {

It's not a too good idea to depend on input.available() - the spec leaves too much room for odd behaviors.
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/InputStream.html#available()
An implementation may decide to return 0 always - as it is the amount of bytes that is guaranteed to be readable without blocking (and an implementation may not know how many bytes can be read without blocking).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5937

From weijun at openjdk.java.net  Tue Feb 15 14:40:18 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 14:40:18 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v2]
In-Reply-To: <YCN0E4VULwKONmndkd1rqlFaR90zcCBGMlgvzXrmGoM=.82e5aa11-d1f4-41a9-9295-c947a4b6f7f9@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>
 <YCN0E4VULwKONmndkd1rqlFaR90zcCBGMlgvzXrmGoM=.82e5aa11-d1f4-41a9-9295-c947a4b6f7f9@github.com>
Message-ID: <SVTthR43t_fhcWVY2xmlC9U8lPUn8oZ0-RKlKy2pKaw=.2e2592aa-fee3-4185-bd0f-200eeaafa290@github.com>

On Thu, 10 Feb 2022 21:09:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   wording, title
>
> Your words are more precise. A reader should check the size first. A new commit pushed and the CSR is also updated.

> @wangweij I would highly recommend to address this ticket first: https://bugs.openjdk.java.net/browse/JDK-6776681. It is partially related.

I noticed the problem and have fixed it in this code change. `nameValue` is the bytes inside.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 14:40:19 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 14:40:19 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <MtWZUyq6H7Mp-1ZHPfJHZK0t71Qr64mbO4W7zrOHG78=.1f5ec5ff-bf95-4495-9ddc-3deca7bb253e@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <MtWZUyq6H7Mp-1ZHPfJHZK0t71Qr64mbO4W7zrOHG78=.1f5ec5ff-bf95-4495-9ddc-3deca7bb253e@github.com>
Message-ID: <q0SaQZCqInZ-jtGFi-pvfgIv2uxJfN__5xeBkaQuBv0=.50107797-0dd5-4dc9-b0e0-038341d0ad11@github.com>

On Tue, 15 Feb 2022 09:10:22 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   specifies the type of the 4th element
>
> src/java.base/share/classes/sun/security/x509/OtherName.java line 93:
> 
>> 91:         oid = in.getOID();
>> 92:         DerValue derValue1 = in.getDerValue();
>> 93:         if (!derValue1.isContextSpecific((byte)0)) {
> 
> Where do you check for constructed (0x20)?
> E.g.:
> 
> byte tag = buf.get();
> if (!(((tag >> CONTEXT_SPECIFIC_BIT) & 1) != 0 && ((tag >> CONSTRUCTED_BIT) & 1) != 0))
> 	throw new CertificateParsingException("Value must be explicitly encoded");
> 
> int tagNumber = tag & 0xFF;
> tagNumber &= ~(1 << CONTEXT_SPECIFIC_BIT);
> tagNumber &= ~(1 << CONSTRUCTED_BIT);
> 
> if (tagNumber != 0)
> 	throw new CertificateParsingException("Value tag number must be 0, but is " + tagNumber);

Oops, I should add an `isConstructed()` check.

> test/jdk/sun/security/x509/OtherName/Parse.java line 86:
> 
>> 84:         int found = 0;
>> 85:         for (var san : x.getSubjectAlternativeNames()) {
>> 86:             if (san.get(2).equals("1.2.3.5")
> 
> Would it make sense to explicitly test length for at least 4?

Sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 14:43:07 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 14:43:07 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v2]
In-Reply-To: <SVTthR43t_fhcWVY2xmlC9U8lPUn8oZ0-RKlKy2pKaw=.2e2592aa-fee3-4185-bd0f-200eeaafa290@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <N7nxTxpj4xai_feApv8MPK9T2rXZLA772XMPY6YsN8o=.32b1bc0d-3cab-4f57-a832-38a9599a60b1@github.com>
 <YCN0E4VULwKONmndkd1rqlFaR90zcCBGMlgvzXrmGoM=.82e5aa11-d1f4-41a9-9295-c947a4b6f7f9@github.com>
 <SVTthR43t_fhcWVY2xmlC9U8lPUn8oZ0-RKlKy2pKaw=.2e2592aa-fee3-4185-bd0f-200eeaafa290@github.com>
Message-ID: <NJb-AahynMQyWO_Eaj2SaloJs5LKo4wEWA_iqH0Ex3U=.54e2f1b9-0556-4e0a-b390-cadcacacb2b9@github.com>

On Tue, 15 Feb 2022 14:36:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Your words are more precise. A reader should check the size first. A new commit pushed and the CSR is also updated.
>
>> @wangweij I would highly recommend to address this ticket first: https://bugs.openjdk.java.net/browse/JDK-6776681. It is partially related.
> 
> I noticed the problem and have fixed it in this code change. `nameValue` is the bytes inside.

> @wangweij Any chance to evaluate this comment from me: https://bugs.openjdk.java.net/browse/JDK-8277976?focusedCommentId=14462729&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14462729?
> Automatic mapping of the value if it is a ASN.1 simple type to a Java type like done for the remaining general names? At least strings would be straight forward and cover many cases, e.g., MS UPN (1.3.6.1.4.1.311.20.2.3).

I'll think about it. Strings (except for OCTET STRING and BIT STRING) are OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 15:16:58 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 15:16:58 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  string at 4th place

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7167/files
  - new: https://git.openjdk.java.net/jdk/pull/7167/files/bca0b6d3..1086d540

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=03-04

  Stats: 27 lines in 4 files changed: 13 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 15:20:11 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 15:20:11 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
Message-ID: <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>

On Fri, 11 Feb 2022 17:13:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   specifies the type of the 4th element

New commit pushed with a spec change and CSR is now in draft mode. Something worth mentioning:

1. I explicitly added "valid UTF8String..." to match the `catch (IOException)` line in the implementation, so if there's anything wrong parsing the value as a string then the byte array will still be there.
2. I feel a little uneasy of the new `if` and `otherwise` words inside parenthesis, especially the second one which seems out of nowhere. Please suggest better wording if possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 15:24:11 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 15:24:11 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
Message-ID: <2Am3LdCD3JN-DhxZa9UcGyVpVm_x5TyxEX8UacSAkq4=.8753543b-79ed-4a19-b79d-a5a9f44b1cc0@github.com>

On Tue, 15 Feb 2022 15:16:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   string at 4th place

test/jdk/sun/security/x509/OtherName/Parse.java line 89:

> 87:         int found = 0;
> 88:         for (var san : x.getSubjectAlternativeNames()) {
> 89:             if (san.size() == 4) {

Make it `>=` if this is going to change in the future..

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 15:32:21 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 15:32:21 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
Message-ID: <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>

On Tue, 15 Feb 2022 15:16:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   string at 4th place

src/java.base/share/classes/sun/security/x509/OtherName.java line 93:

> 91:         oid = in.getOID();
> 92:         DerValue derValue1 = in.getDerValue();
> 93:         if (!derValue1.isContextSpecific((byte)0) || !derValue1.isConstructed()) {

It might be purely a matter of taste, but isn't `!(isCSTag0 && isConst)` easier to read?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 15:32:21 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 15:32:21 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <2Am3LdCD3JN-DhxZa9UcGyVpVm_x5TyxEX8UacSAkq4=.8753543b-79ed-4a19-b79d-a5a9f44b1cc0@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <2Am3LdCD3JN-DhxZa9UcGyVpVm_x5TyxEX8UacSAkq4=.8753543b-79ed-4a19-b79d-a5a9f44b1cc0@github.com>
Message-ID: <cJtZi-iS_LYb1SYgNGpFUlZGeXh_j0Z8_IkQlWowO40=.c55f832e-8ae1-4508-8d87-0c44101af95c@github.com>

On Tue, 15 Feb 2022 15:21:08 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   string at 4th place
>
> test/jdk/sun/security/x509/OtherName/Parse.java line 89:
> 
>> 87:         int found = 0;
>> 88:         for (var san : x.getSubjectAlternativeNames()) {
>> 89:             if (san.size() == 4) {
> 
> Make it `>=` if this is going to change in the future..

OK, but this is always implementation-specific. Precisely, it's a "may" so I should not check the count.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 15:59:10 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 15:59:10 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
Message-ID: <-lGH0SOb8cxTu2MXG6pWaJI5TawfKmJSjagqpfS9tq0=.53c8254d-bfeb-44c5-8597-901f6ca641b9@github.com>

On Tue, 15 Feb 2022 15:16:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   specifies the type of the 4th element
>
> New commit pushed with a spec change and CSR is now in draft mode. Something worth mentioning:
> 
> 1. I explicitly added "valid UTF8String..." to match the `catch (IOException)` line in the implementation, so if there's anything wrong parsing the value as a string then the byte array will still be there.
> 2. I feel a little uneasy of the new `if` and `otherwise` words inside parentheses, especially the second one which seems out of nowhere. Please suggest better wording if possible.
> 3. The string types I listed is only what we supported inside JDK and not all "restricted character string types". Is it appropriate to list them out in a specification? If not, shall I just say "a valid character string"? This brings more explanation to what "valid" means.

> > @wangweij I would highly recommend to address this ticket first: https://bugs.openjdk.java.net/browse/JDK-6776681. It is partially related.
> 
> I noticed the problem and have fixed it in this code change. `nameValue` is the bytes inside.

Yes, looks good. Are you going to address this separately or document to be implicitly fixed by this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 15:59:10 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 15:59:10 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <-lGH0SOb8cxTu2MXG6pWaJI5TawfKmJSjagqpfS9tq0=.53c8254d-bfeb-44c5-8597-901f6ca641b9@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
 <-lGH0SOb8cxTu2MXG6pWaJI5TawfKmJSjagqpfS9tq0=.53c8254d-bfeb-44c5-8597-901f6ca641b9@github.com>
Message-ID: <Z8j1qnQBFd5d10DfD4waYtmwc4pdCGLimXpAbDhN0AM=.5bfb9b5c-80db-40e7-ba8b-a35e852ad338@github.com>

On Tue, 15 Feb 2022 15:50:07 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

> Are you going to address this separately or document to be implicitly fixed by this PR?

Normally we close the other one as a duplicate. I'll do it now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 15:59:10 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 15:59:10 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <Z8j1qnQBFd5d10DfD4waYtmwc4pdCGLimXpAbDhN0AM=.5bfb9b5c-80db-40e7-ba8b-a35e852ad338@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
 <-lGH0SOb8cxTu2MXG6pWaJI5TawfKmJSjagqpfS9tq0=.53c8254d-bfeb-44c5-8597-901f6ca641b9@github.com>
 <Z8j1qnQBFd5d10DfD4waYtmwc4pdCGLimXpAbDhN0AM=.5bfb9b5c-80db-40e7-ba8b-a35e852ad338@github.com>
Message-ID: <0_pJ7Hc7yz9O1J9RqtV1YEy6p_W229itA_4eNy1ZD20=.99aa5af6-ca13-43f1-a5d4-56e364d591e8@github.com>

On Tue, 15 Feb 2022 15:51:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > Are you going to address this separately or document to be implicitly fixed by this PR?
> 
> Normally we close the other one as a duplicate. I'll do it now.

Well, technically it is not a duplicate since both tickets address different problems...

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 15:59:11 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 15:59:11 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
Message-ID: <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>

On Tue, 15 Feb 2022 15:28:29 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   string at 4th place
>
> src/java.base/share/classes/sun/security/x509/OtherName.java line 93:
> 
>> 91:         oid = in.getOID();
>> 92:         DerValue derValue1 = in.getDerValue();
>> 93:         if (!derValue1.isContextSpecific((byte)0) || !derValue1.isConstructed()) {
> 
> It might be purely a matter of taste, but isn't `!(isCSTag0 && isConst)` easier to read?

I have difficulty describing `!(a && b)`. There is no parentheses in human language and `!` has higher order than `&&`.

I thought about completely reverse the block but that means everything after the throw will be inside a block and I don't want to move so many lines.

> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1594:
> 
>> 1592:                         String v = new DerValue(nameValue).getAsString();
>> 1593:                         nameEntry.add(v == null ? nameValue : v);
>> 1594:                     } catch (IOException ioe) {
> 
> Attention, this catch block will hide invalid ASN.1 encoding of the other name element from:
> * sun.security.util.DerValue.init(boolean, InputStream, boolean)
> * sun.security.util.DerValue.getIA5String()
> 
> Other blocks throw:
> 
> throw new CertificateException("Unable to parse DER value of SAN:otherName", ioe);
> 
> 
> Do you really intend to hide an encoding error int the cert from the user?

Up to debate. Other blocks in `makeAltNames` throw `RuntimeException`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 15:59:12 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 15:59:12 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
Message-ID: <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>

On Tue, 15 Feb 2022 15:46:10 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> I have difficulty describing `!(a && b)`. There is no parentheses in human language and `!` has higher order than `&&`.
>> 
>> I thought about completely reverse the block but that means everything after the throw will be inside a block and I don't want to move so many lines.
>
> My wording for the &&: If the tag is not a constructed and context-specific tag number 0, then an exception is thrown. The parens denote that both conditions need to apply:
> 
> !(isCSTag0 && isConst)
> 
> true, true = !(true && true) = !true = false
> true, false = !(true && false) = !false = true
> false, true = !(false && true) = !false = true
> false, false = !(false && false) = !false = true
> 
> 
> !isCSTag0 || !isConst
> 
> true, true = !true || !true = false || false = false
> true, false = !true || !false = false || true = true
> false, true = !false || !true = true || false = true
> false, false = !false || !false = true || true = true

If you really like it, I'll write

        if (derValue1.isContextSpecific((byte) 0) && derValue1.isConstructed()) {
            nameValue = derValue1.data.toByteArray();
        } else {
            throw new IOException("value is not [0]");
        }

Turns out I don't need to move all lines into the block.

>> Up to debate. Other blocks in `makeAltNames` throw `RuntimeException`.
>
> Correct, but they don't swallow at least.

But in this case, we still have a place to provide the raw bytes. Maybe that's better? Or you'd rather be guaranteed that one particular otherName should always have a string there and there's no need to do an `instanceof` check? What if the tag is already wrong and I don't know it should be a string?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 15:59:12 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 15:59:12 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
Message-ID: <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>

On Tue, 15 Feb 2022 15:40:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/OtherName.java line 93:
>> 
>>> 91:         oid = in.getOID();
>>> 92:         DerValue derValue1 = in.getDerValue();
>>> 93:         if (!derValue1.isContextSpecific((byte)0) || !derValue1.isConstructed()) {
>> 
>> It might be purely a matter of taste, but isn't `!(isCSTag0 && isConst)` easier to read?
>
> I have difficulty describing `!(a && b)`. There is no parentheses in human language and `!` has higher order than `&&`.
> 
> I thought about completely reverse the block but that means everything after the throw will be inside a block and I don't want to move so many lines.

My wording for the &&: If the tag is not a constructed and context-specific tag number 0, then an exception is thrown. The parens denote that both conditions need to apply:

!(isCSTag0 && isConst)

true, true = !(true && true) = !true = false
true, false = !(true && false) = !false = true
false, true = !(false && true) = !false = true
false, false = !(false && false) = !false = true


!isCSTag0 || !isConst

true, true = !true || !true = false || false = false
true, false = !true || !false = false || true = true
false, true = !false || !true = true || false = true
false, false = !false || !false = true || true = true

>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1594:
>> 
>>> 1592:                         String v = new DerValue(nameValue).getAsString();
>>> 1593:                         nameEntry.add(v == null ? nameValue : v);
>>> 1594:                     } catch (IOException ioe) {
>> 
>> Attention, this catch block will hide invalid ASN.1 encoding of the other name element from:
>> * sun.security.util.DerValue.init(boolean, InputStream, boolean)
>> * sun.security.util.DerValue.getIA5String()
>> 
>> Other blocks throw:
>> 
>> throw new CertificateException("Unable to parse DER value of SAN:otherName", ioe);
>> 
>> 
>> Do you really intend to hide an encoding error int the cert from the user?
>
> Up to debate. Other blocks in `makeAltNames` throw `RuntimeException`.

Correct, but they don't swallow at least.

>> test/jdk/sun/security/x509/OtherName/Parse.java line 89:
>> 
>>> 87:         int found = 0;
>>> 88:         for (var san : x.getSubjectAlternativeNames()) {
>>> 89:             if (san.size() == 4) {
>> 
>> Make it `>=` if this is going to change in the future..
>
> OK, but this is always implementation-specific. Precisely, it's a "may" so I should not check the count.

Right, let's leave as-is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 15:59:12 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 15:59:12 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
Message-ID: <73s4VMF7BeZhmggwYTdFIW5qNfJukSmYpL6UWb7OOm4=.c175cdc0-02fc-484c-a9e3-2cd9ffb9d83d@github.com>

On Tue, 15 Feb 2022 15:48:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> My wording for the &&: If the tag is not a constructed and context-specific tag number 0, then an exception is thrown. The parens denote that both conditions need to apply:
>> 
>> !(isCSTag0 && isConst)
>> 
>> true, true = !(true && true) = !true = false
>> true, false = !(true && false) = !false = true
>> false, true = !(false && true) = !false = true
>> false, false = !(false && false) = !false = true
>> 
>> 
>> !isCSTag0 || !isConst
>> 
>> true, true = !true || !true = false || false = false
>> true, false = !true || !false = false || true = true
>> false, true = !false || !true = true || false = true
>> false, false = !false || !false = true || true = true
>
> If you really like it, I'll write
> 
>         if (derValue1.isContextSpecific((byte) 0) && derValue1.isConstructed()) {
>             nameValue = derValue1.data.toByteArray();
>         } else {
>             throw new IOException("value is not [0]");
>         }
> 
> Turns out I don't need to move all lines into the block.

Yes, that is fine also!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 15:59:12 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 15:59:12 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
Message-ID: <_ftIBeqmR2jnLQKJojwAdsNh4LkCdtCWiESLPo7VeJI=.cc39ccf0-446d-4186-86db-369afed1af01@github.com>

On Tue, 15 Feb 2022 15:16:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   string at 4th place

src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1594:

> 1592:                         String v = new DerValue(nameValue).getAsString();
> 1593:                         nameEntry.add(v == null ? nameValue : v);
> 1594:                     } catch (IOException ioe) {

Attention, this catch block will hide invalid ASN.1 encoding of the other name element from:
* sun.security.util.DerValue.init(boolean, InputStream, boolean)
* sun.security.util.DerValue.getIA5String()

Other blocks throw:

throw new CertificateException("Unable to parse DER value of SAN:otherName", ioe);


Do you really intend to hide an encoding error int the cert from the user?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 16:03:11 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 16:03:11 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
Message-ID: <mpji1my4D56_paPN-xGGOmEkJnSpXsHkCfSEoMHXtQM=.07ee3fb1-23f5-4ed3-bb94-a2470d233a1a@github.com>

On Tue, 15 Feb 2022 15:16:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> New commit pushed with a spec change and CSR is now in draft mode. Something worth mentioning:
> 
>     1. I explicitly added "valid UTF8String..." to match the `catch (IOException)` line in the implementation, so if there's anything wrong parsing the value as a string then the byte array will still be there.

Good.
 
>     2. I feel a little uneasy of the new `if` and `otherwise` words inside parentheses, especially the second one which seems out of nowhere. Please suggest better wording if possible.

What about?

    and a fourth entry as either a string if {@code value} inside
    is a valid ASN.1 string (any of UTF8String, PrintableString, T61String, IA5String,
    UniversalString, BMPString, or GeneralString) or otherwise a byte array containing
    the ASN.1 DER encoding of {@code value} without the context-specific
    constructed tag with number 0. 

>     3. The string types I listed is only what we supported inside JDK and not all "restricted character string types". Is it appropriate to list them out in a specification? If not, shall I just say "a valid character string"? This brings more explanation to what "valid" means.

Yes, this makes it perfectly clear what is supported of out of the box.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 16:07:09 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 16:07:09 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <mpji1my4D56_paPN-xGGOmEkJnSpXsHkCfSEoMHXtQM=.07ee3fb1-23f5-4ed3-bb94-a2470d233a1a@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
 <mpji1my4D56_paPN-xGGOmEkJnSpXsHkCfSEoMHXtQM=.07ee3fb1-23f5-4ed3-bb94-a2470d233a1a@github.com>
Message-ID: <WJEQ-mrkBJDkJU-V8J8MCv2eo5Wiq1utEI4P6jNgmII=.03a8ad3d-4ed4-4382-a8b9-5c79eba8ff7c@github.com>

On Tue, 15 Feb 2022 15:59:42 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

> > ```
> > 2. I feel a little uneasy of the new `if` and `otherwise` words inside parentheses, especially the second one which seems out of nowhere. Please suggest better wording if possible.
> > ```
> 
> 
> What about?
> 
> 
> ```
> and a fourth entry as either a string if {@code value} inside
> is a valid ASN.1 string (any of UTF8String, PrintableString, T61String, IA5String,
> UniversalString, BMPString, or GeneralString) or otherwise a byte array containing
> the ASN.1 DER encoding of {@code value} without the context-specific
> constructed tag with number 0. 
> ```

Do not feel easy with the two `or`.
> 
> 
>      
>   
> 
> > ```
> > 3. The string types I listed is only what we supported inside JDK and not all "restricted character string types". Is it appropriate to list them out in a specification? If not, shall I just say "a valid character string"? This brings more explanation to what "valid" means.
> > ```
> 
> 
> Yes, this makes it perfectly clear what is supported of out of the box.

But this also means if the internal implementation deep inside `DerValue::getAsString` is updated then this spec must be updated as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 16:12:07 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 16:12:07 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
Message-ID: <PKrHPvMFrN_QsZsYozoFxHZ3zwh7J_19Wbla-olgatY=.f6c7aa29-fe02-4c57-99c4-1ca33aa71b0d@github.com>

On Tue, 15 Feb 2022 15:55:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Correct, but they don't swallow at least.
>
> But in this case, we still have a place to provide the raw bytes. Maybe that's better? Or you'd rather be guaranteed that one particular otherName should always have a string there and there's no need to do an `instanceof` check? What if the tag is already wrong and I don't know it should be a string?

I have thought about this actually. Now the parse is free of any semantics, which is naive. Actually, you need a list of wellknown OIDs to know the target tag type to perform the conversion. E.g., you know that MS UPN must be UTF8String, if not this is an error. If you don't know the OID, don't touch it.
OpenSSL knows the semantics and decodes it, otherwise don't touch it and leave it: https://github.com/openssl/openssl/blob/317acac5cc0a2cb31bc4b91353c2b752a3989d8a/crypto/x509/v3_san.c#L113-L120

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 16:15:15 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 16:15:15 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <WJEQ-mrkBJDkJU-V8J8MCv2eo5Wiq1utEI4P6jNgmII=.03a8ad3d-4ed4-4382-a8b9-5c79eba8ff7c@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
 <mpji1my4D56_paPN-xGGOmEkJnSpXsHkCfSEoMHXtQM=.07ee3fb1-23f5-4ed3-bb94-a2470d233a1a@github.com>
 <WJEQ-mrkBJDkJU-V8J8MCv2eo5Wiq1utEI4P6jNgmII=.03a8ad3d-4ed4-4382-a8b9-5c79eba8ff7c@github.com>
Message-ID: <9NP4yz30dUhJOkExAO7wy-1kO_ZGP9LZsQzvGFFNLlY=.baa34d7c-7411-4aef-bceb-a8b18f9310a6@github.com>

On Tue, 15 Feb 2022 16:04:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > > ```
> > > 2. I feel a little uneasy of the new `if` and `otherwise` words inside parentheses, especially the second one which seems out of nowhere. Please suggest better wording if possible.
> > > ```
> > 
> > 
> > What about?
> > ```
> > and a fourth entry as either a string if {@code value} inside
> > is a valid ASN.1 string (any of UTF8String, PrintableString, T61String, IA5String,
> > UniversalString, BMPString, or GeneralString) or otherwise a byte array containing
> > the ASN.1 DER encoding of {@code value} without the context-specific
> > constructed tag with number 0. 
> > ```
> 
> Do not feel easy with the two `or`.

Yes, then you need parens...

> > > ```
> > > 3. The string types I listed is only what we supported inside JDK and not all "restricted character string types". Is it appropriate to list them out in a specification? If not, shall I just say "a valid character string"? This brings more explanation to what "valid" means.
> > > ```
> > 
> > 
> > Yes, this makes it perfectly clear what is supported of out of the box.
> 
> But this also means if the internal implementation deep inside `DerValue::getAsString` is updated then this spec must be updated as well.

True, it creates an unnecessary dependency. Remove explicit mentioning. I don't expect any new ASN.1 string types to be added in the future, but of someone decides to create a public ASN.1 API in the JDK and rewrite all internal code this would be subject to it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 16:20:09 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 16:20:09 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <PKrHPvMFrN_QsZsYozoFxHZ3zwh7J_19Wbla-olgatY=.f6c7aa29-fe02-4c57-99c4-1ca33aa71b0d@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
 <PKrHPvMFrN_QsZsYozoFxHZ3zwh7J_19Wbla-olgatY=.f6c7aa29-fe02-4c57-99c4-1ca33aa71b0d@github.com>
Message-ID: <An5YTEaQEmmrQPQQui1zfXQ7wv5THQdUN8cAFEnCGZ4=.22a233bd-ad15-444e-be97-da1aab1fbb86@github.com>

On Tue, 15 Feb 2022 16:09:13 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> But in this case, we still have a place to provide the raw bytes. Maybe that's better? Or you'd rather be guaranteed that one particular otherName should always have a string there and there's no need to do an `instanceof` check? What if the tag is already wrong and I don't know it should be a string?
>
> I have thought about this actually. Now the parse is free of any semantics, which is naive. Actually, you need a list of wellknown OIDs to know the target tag type to perform the conversion. E.g., you know that MS UPN must be UTF8String, if not this is an error. If you don't know the OID, don't touch it.
> OpenSSL knows the semantics and decodes it, otherwise don't touch it and leave it: https://github.com/openssl/openssl/blob/317acac5cc0a2cb31bc4b91353c2b752a3989d8a/crypto/x509/v3_san.c#L113-L120

Maybe adopt the list of OpenSSL, otherwise return byte array?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 16:28:06 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 16:28:06 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
Message-ID: <QsJoY-XtyD6VzMrbC3nmAoO7OIxMAzK6c-JwYy0yUi8=.9152b02a-a2d7-42d7-92cf-ff288ab88880@github.com>

On Tue, 15 Feb 2022 15:16:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   string at 4th place

So my current opinion is to make it as vague as possible (Ex: `a valid supported character string`) so people always remember to check `instanceof String` first.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 16:28:06 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 16:28:06 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <QsJoY-XtyD6VzMrbC3nmAoO7OIxMAzK6c-JwYy0yUi8=.9152b02a-a2d7-42d7-92cf-ff288ab88880@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <QsJoY-XtyD6VzMrbC3nmAoO7OIxMAzK6c-JwYy0yUi8=.9152b02a-a2d7-42d7-92cf-ff288ab88880@github.com>
Message-ID: <vQcy0XsGqshN87T2WdK4nlht3_9z23yVMIYYsLDZXkE=.1313f3d0-1569-407d-a0a6-59a977d398a6@github.com>

On Tue, 15 Feb 2022 16:22:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> So my current opinion is to make it as vague as possible (Ex: `a valid supported character string`) so people always remember to check `instanceof String` first.

I agree with that, but consider https://github.com/openjdk/jdk/pull/7167#discussion_r807016503 also.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 17:17:17 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 17:17:17 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <9NP4yz30dUhJOkExAO7wy-1kO_ZGP9LZsQzvGFFNLlY=.baa34d7c-7411-4aef-bceb-a8b18f9310a6@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
 <mpji1my4D56_paPN-xGGOmEkJnSpXsHkCfSEoMHXtQM=.07ee3fb1-23f5-4ed3-bb94-a2470d233a1a@github.com>
 <WJEQ-mrkBJDkJU-V8J8MCv2eo5Wiq1utEI4P6jNgmII=.03a8ad3d-4ed4-4382-a8b9-5c79eba8ff7c@github.com>
 <9NP4yz30dUhJOkExAO7wy-1kO_ZGP9LZsQzvGFFNLlY=.baa34d7c-7411-4aef-bceb-a8b18f9310a6@github.com>
Message-ID: <QH5lsCidzNwg8Yf6ciUdKPBqRJEiUHO7XHCUghzoVhc=.6c045dba-71ec-42e7-a84e-d75fa3848a92@github.com>

On Tue, 15 Feb 2022 16:12:17 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

> I don't expect any new ASN.1 string types to be added in the future, but of someone decides to create a public ASN.1 

I've seen new string types that need 2 bytes tag, but don't know if they are used anywhere. 

Also, there are existing types we don't support also, like TeletexString.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 17:17:17 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 17:17:17 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <QH5lsCidzNwg8Yf6ciUdKPBqRJEiUHO7XHCUghzoVhc=.6c045dba-71ec-42e7-a84e-d75fa3848a92@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
 <mpji1my4D56_paPN-xGGOmEkJnSpXsHkCfSEoMHXtQM=.07ee3fb1-23f5-4ed3-bb94-a2470d233a1a@github.com>
 <WJEQ-mrkBJDkJU-V8J8MCv2eo5Wiq1utEI4P6jNgmII=.03a8ad3d-4ed4-4382-a8b9-5c79eba8ff7c@github.com>
 <9NP4yz30dUhJOkExAO7wy-1kO_ZGP9LZsQzvGFFNLlY=.baa34d7c-7411-4aef-bceb-a8b18f9310a6@github.com>
 <QH5lsCidzNwg8Yf6ciUdKPBqRJEiUHO7XHCUghzoVhc=.6c045dba-71ec-42e7-a84e-d75fa3848a92@github.com>
Message-ID: <aOsMOGxKVQdzU7i4Z2BSlcWJENqiBkB5UAKx5mZvAjM=.0b1f984c-c646-4186-a5b3-212a7177394f@github.com>

On Tue, 15 Feb 2022 17:11:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > I don't expect any new ASN.1 string types to be added in the future, but of someone decides to create a public ASN.1
> 
> I've seen new string types that need 2 bytes tag, but don't know if they are used anywhere.

Oh, can you reference? 

> Also, there are existing types we don't support also, like TeletexString.

That is dead, isn't it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From mullan at openjdk.java.net  Tue Feb 15 17:38:14 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 15 Feb 2022 17:38:14 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
Message-ID: <2zuKjmHnC4VGAmHXMYuejS2aZMUaRoKKtUgFjeW-Xks=.b06eec2d-55e3-4026-9284-df04bb1c9828@github.com>

On Tue, 15 Feb 2022 15:16:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   string at 4th place

src/java.base/share/classes/java/security/cert/X509Certificate.java line 600:

> 598:      * defined for otherNames, X.400 names, EDI party names, or any
> 599:      * other type of names. They are returned as byte arrays
> 600:      * containing the ASN.1 DER encoded form of the name.

I would move this sentence up before "otherNames ..." and remove the "otherNames" from it and the end of the sentence. So basically:

>      * No standard string format is
>      * defined for X.400 names or EDI party names. They are returned as byte arrays
>      * containing the ASN.1 DER encoded form of the name.
>      * otherNames are returned as a byte array ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 18:35:06 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 18:35:06 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v4]
In-Reply-To: <aOsMOGxKVQdzU7i4Z2BSlcWJENqiBkB5UAKx5mZvAjM=.0b1f984c-c646-4186-a5b3-212a7177394f@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <_KGkxMSQRtaOHobz4Scv4BlbGfCXiS5v_5oYX841F18=.7acf946e-9ccf-43d8-ae01-7f5cf4e5a44e@github.com>
 <h9J7Ix8a8cnrOSt7U0HXsEvaA27CTG1FS20Ch6eFQE0=.6774bd96-67fd-44f5-8c5c-33f3df6c6f8a@github.com>
 <mpji1my4D56_paPN-xGGOmEkJnSpXsHkCfSEoMHXtQM=.07ee3fb1-23f5-4ed3-bb94-a2470d233a1a@github.com>
 <WJEQ-mrkBJDkJU-V8J8MCv2eo5Wiq1utEI4P6jNgmII=.03a8ad3d-4ed4-4382-a8b9-5c79eba8ff7c@github.com>
 <9NP4yz30dUhJOkExAO7wy-1kO_ZGP9LZsQzvGFFNLlY=.baa34d7c-7411-4aef-bceb-a8b18f9310a6@github.com>
 <QH5lsCidzNwg8Yf6ciUdKPBqRJEiUHO7XHCUghzoVhc=.6c045dba-71ec-42e7-a84e-d75fa3848a92@github.com>
 <aOsMOGxKVQdzU7i4Z2BSlcWJENqiBkB5UAKx5mZvAjM=.0b1f984c-c646-4186-a5b3-212a7177394f@github.com>
Message-ID: <pE-xPpK1XeExbPxjtqpILp6ow1yUPhFE0eHVBsFDeKM=.3940aaa1-d9c4-4cfd-a675-9ef9c1fe8cb5@github.com>

On Tue, 15 Feb 2022 17:15:13 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

> Oh, can you reference?

Sorry, memory is incorrect, those are date time types (in https://www.oss.com/asn1/resources/reference/ASN.1-Reference-Card-format-USA.pdf). But here they do promote a VisibleString that we don't support.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 19:51:57 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 19:51:57 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  retell the formats

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7167/files
  - new: https://git.openjdk.java.net/jdk/pull/7167/files/1086d540..a610bc5d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=04-05

  Stats: 22 lines in 3 files changed: 2 ins; 5 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 20:03:09 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 20:03:09 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
Message-ID: <2OWhLCEwb7XlGYMMwCih6layetFPh3xH-rzwqILmLQw=.1e5b89d3-4f75-4936-9608-6e6388aa3834@github.com>

On Tue, 15 Feb 2022 19:51:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retell the formats

New commit pushed. For the openssl style suggestion, I think its major benefit is to provide a string format of the type (like `"othername: UPN:"`). In the `default` block, it still extracts either the IA5String or the UTF8String. I think it's not worth penalizing people putting an IA5String into a UPN. Right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Tue Feb 15 20:13:07 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Tue, 15 Feb 2022 20:13:07 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <2OWhLCEwb7XlGYMMwCih6layetFPh3xH-rzwqILmLQw=.1e5b89d3-4f75-4936-9608-6e6388aa3834@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
 <2OWhLCEwb7XlGYMMwCih6layetFPh3xH-rzwqILmLQw=.1e5b89d3-4f75-4936-9608-6e6388aa3834@github.com>
Message-ID: <-ld1RJQbUtpNT0tNgsxbaLc41S1326bLvnJw7CLZ6Hs=.b02f69fb-9d6e-4f5a-a47c-bc2a1de4cfe7@github.com>

On Tue, 15 Feb 2022 20:00:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> New commit pushed. For the openssl style suggestion, I think its major benefit is to provide a string format of the type (like `"othername: UPN:"`). In the `default` block, it still extracts either the IA5String or the UTF8String. I think it's not worth penalizing people putting an IA5String into a UPN. Right?

UPN is a DirectoryString from AD which is UTF-8 encoded. The default case from OPENSSL tries to cover OIDs it does not know. UPN it does know and its semantics is always UTF8String. Everything else is wrong. I5AString is rather email which is another general name. We have now two options: add well known and decode accordingly or do yhe default case. From a user's perspective the encoding is rather irrelevant because he wants Java types.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Tue Feb 15 21:37:10 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Feb 2022 21:37:10 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <-ld1RJQbUtpNT0tNgsxbaLc41S1326bLvnJw7CLZ6Hs=.b02f69fb-9d6e-4f5a-a47c-bc2a1de4cfe7@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
 <2OWhLCEwb7XlGYMMwCih6layetFPh3xH-rzwqILmLQw=.1e5b89d3-4f75-4936-9608-6e6388aa3834@github.com>
 <-ld1RJQbUtpNT0tNgsxbaLc41S1326bLvnJw7CLZ6Hs=.b02f69fb-9d6e-4f5a-a47c-bc2a1de4cfe7@github.com>
Message-ID: <y_5rWVOPVrm6tfHNOwVwpxhc1xvi33nkmFZEIGg007w=.be8804b9-1e0c-4876-8e30-97820d748bbb@github.com>

On Tue, 15 Feb 2022 20:09:27 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

> > New commit pushed. For the openssl style suggestion, I think its major benefit is to provide a string format of the type (like `"othername: UPN:"`). In the `default` block, it still extracts either the IA5String or the UTF8String. I think it's not worth penalizing people putting an IA5String into a UPN. Right?
> 
> UPN is a DirectoryString from AD which is UTF-8 encoded. The default case from OPENSSL tries to cover OIDs it does not know. UPN it does know and its semantics is always UTF8String. Everything else is wrong. I5AString is rather email which is another general name. We have now two options: add well known and decode accordingly or do yhe default case. From a user's perspective the encoding is rather irrelevant because he wants Java types.

I'll pick the 2nd option now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From xuelei.f at gmail.com  Wed Feb 16 05:47:37 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Tue, 15 Feb 2022 21:47:37 -0800
Subject: JEP Review Request: TLS Certificate Compression
Message-ID: <CAPJ=zzgFhid+tXPckmDTq7vh5y5NJx1KK3CeGFF=roiy4xq09A@mail.gmail.com>

<Resend as it looks like my work email has no subscription to this email
list>
Hi all,

The JDK Enhancement Proposal, TLS Certificate Compression, has been opened
for community review.  Detailed, please refer to the draft:

    https://bugs.openjdk.java.net/browse/JDK-8281710

Feel free to make comments and send your feedback to the alias.  I may
submit this JEP in the beginning of next week if I hear no objections by
the end of this week.

Thanks,
Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220215/36894bd9/attachment.htm>

From duke at openjdk.java.net  Wed Feb 16 13:55:43 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 16 Feb 2022 13:55:43 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v6]
In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
Message-ID: <Y0cGthk75vKmIO6ajmYSAtVTe_UJKLkUOphQ0zIy9uI=.c69cdd32-2dca-4c86-9460-32cc517b64bc@github.com>

> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
> JDK-8273142
> JDK-8268464
> JDK-8268133

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments :
  1. Use of Locale.ROOT
  2. Rewritten get(InputStream is) method as per comments.
  3. Corrected java doc comments.
  4. Removed use of is.available() method.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5937/files
  - new: https://git.openjdk.java.net/jdk/pull/5937/files/70a37be9..6820c0cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=04-05

  Stats: 112 lines in 1 file changed: 19 ins; 15 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937

PR: https://git.openjdk.java.net/jdk/pull/5937

From duke at openjdk.java.net  Wed Feb 16 14:37:07 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 16 Feb 2022 14:37:07 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v6]
In-Reply-To: <Y0cGthk75vKmIO6ajmYSAtVTe_UJKLkUOphQ0zIy9uI=.c69cdd32-2dca-4c86-9460-32cc517b64bc@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
 <Y0cGthk75vKmIO6ajmYSAtVTe_UJKLkUOphQ0zIy9uI=.c69cdd32-2dca-4c86-9460-32cc517b64bc@github.com>
Message-ID: <4Am85l8vDkYyDVHwNcHMDsd2xBp6AC4U1DPNkhYy9zs=.33422476-7064-4363-bb1e-0e2b6955a389@github.com>

On Wed, 16 Feb 2022 13:55:43 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
>> JDK-8273142
>> JDK-8268464
>> JDK-8268133
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments :
>   1. Use of Locale.ROOT
>   2. Rewritten get(InputStream is) method as per comments.
>   3. Corrected java doc comments.
>   4. Removed use of is.available() method.

Mach5 results https://mach5.us.oracle.com/mdash/jobs/mahendrachhipa-jdk-20220216-1342-29188746

-------------

PR: https://git.openjdk.java.net/jdk/pull/5937

From dfuchs at openjdk.java.net  Wed Feb 16 15:29:12 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 16 Feb 2022 15:29:12 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v6]
In-Reply-To: <Y0cGthk75vKmIO6ajmYSAtVTe_UJKLkUOphQ0zIy9uI=.c69cdd32-2dca-4c86-9460-32cc517b64bc@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
 <Y0cGthk75vKmIO6ajmYSAtVTe_UJKLkUOphQ0zIy9uI=.c69cdd32-2dca-4c86-9460-32cc517b64bc@github.com>
Message-ID: <8vP1xmQsYLKFlbLUCF3uyEmlpdMI3xAIdFx55WyQucE=.e13c30e6-b123-40d3-a1d1-6d9972fa8a10@github.com>

On Wed, 16 Feb 2022 13:55:43 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
>> JDK-8273142
>> JDK-8268464
>> JDK-8268133
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments :
>   1. Use of Locale.ROOT
>   2. Rewritten get(InputStream is) method as per comments.
>   3. Corrected java doc comments.
>   4. Removed use of is.available() method.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5937

From duke at openjdk.java.net  Wed Feb 16 16:48:14 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 16 Feb 2022 16:48:14 GMT
Subject: Integrated: JDK-8061729 : Update java/net tests to eliminate
 dependency on sun.net.www.MessageHeader and some other internal APIs
In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
Message-ID: <yr7FE3yJ8gRlRvPrJe0bCt9btwdo1CZ4tv4fJ5IHFlg=.94d027d9-140c-4a51-a3ef-80832ca569a4@github.com>

On Wed, 13 Oct 2021 22:04:23 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
> JDK-8273142
> JDK-8268464
> JDK-8268133

This pull request has now been integrated.

Changeset: 0f3d3ac3
Author:    Mahendra Chhipa <mahendra.chhipa at oracle.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f3d3ac32c9d163a5d91c6839d313111c72f1ad4
Stats:     978 lines in 11 files changed: 921 ins; 12 del; 45 mod

8061729: Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/5937

From xueleifan at tencent.com  Wed Feb 16 05:30:03 2022
From: xueleifan at tencent.com (xueleifan(XueleiFan))
Date: Wed, 16 Feb 2022 05:30:03 +0000
Subject: JEP Review Request: TLS Certificate Compression
Message-ID: <9D47E367-3214-46E9-A73D-5B8693C42BD2@Tencent.Com>

Hi all,

The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review.  Detailed, please refer to the draft:

    https://bugs.openjdk.java.net/browse/JDK-8281710

Feel free to make comment and send your feedback to the alias.  I may submit this JEP in the beginning of next week if I hear no objections by the end of this week.

Thanks,
Xuelei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220216/f0483a2b/attachment.htm>

From xuelei at openjdk.java.net  Wed Feb 16 19:21:58 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 16 Feb 2022 19:21:58 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v17]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <nKGIr2G5qx2Yuj3jo2ejYZjgF_MCX1HJJ91-z0tyP3E=.fe694e60-5276-43a6-a060-bf131f3f0ffe@github.com>

> 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:

  Add implSpec about existence of the new methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/40163778..bbc3bb8e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=15-16

  Stats: 15 lines in 1 file changed: 12 ins; 1 del; 2 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

From xuelei at openjdk.java.net  Wed Feb 16 19:27:10 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 16 Feb 2022 19:27:10 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v17]
In-Reply-To: <nKGIr2G5qx2Yuj3jo2ejYZjgF_MCX1HJJ91-z0tyP3E=.fe694e60-5276-43a6-a060-bf131f3f0ffe@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <nKGIr2G5qx2Yuj3jo2ejYZjgF_MCX1HJJ91-z0tyP3E=.fe694e60-5276-43a6-a060-bf131f3f0ffe@github.com>
Message-ID: <32Itvpr0Xo1s9gbqxdY54lXhuB8YUpWoyKdPuCGYYYo=.4161e44f-492f-48dd-9a70-d6b4f79ece1a@github.com>

On Wed, 16 Feb 2022 19:21:58 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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:
> 
>   Add implSpec about existence of the new methods

Joe had a good point in the CSR review for the existence of the new APIs in subclass SSLParameters.  It is suggested to add a implSpec tag accordingly.  May I have the CSR and SSLParameters spec update reviewed again?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252

From dfuchs at openjdk.java.net  Wed Feb 16 21:16:21 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 16 Feb 2022 21:16:21 GMT
Subject: RFR: 8282017:
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server"
In-Reply-To: <uHM5y4V6Oqlt5YKk_B4JtOFyK-jSkEKWYOYEkxLwUAU=.e2a285d1-4f39-4713-bba9-eb7db1b44cca@github.com>
References: <uHM5y4V6Oqlt5YKk_B4JtOFyK-jSkEKWYOYEkxLwUAU=.e2a285d1-4f39-4713-bba9-eb7db1b44cca@github.com>
Message-ID: <uKEW_h3jAu2AFVx5qbgWuuPRdLGfJStNKpAWDD782DY=.afdefab5-33fe-4f46-9bf3-97fc0b490a5c@github.com>

On Wed, 16 Feb 2022 21:10:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure.  The fix is to simply revert that small change.

I am currently running tier2 tests in the CI

-------------

PR: https://git.openjdk.java.net/jdk/pull/7503

From dfuchs at openjdk.java.net  Wed Feb 16 21:16:21 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 16 Feb 2022 21:16:21 GMT
Subject: RFR: 8282017:
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server"
Message-ID: <uHM5y4V6Oqlt5YKk_B4JtOFyK-jSkEKWYOYEkxLwUAU=.e2a285d1-4f39-4713-bba9-eb7db1b44cca@github.com>

A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure.  The fix is to simply revert that small change.

-------------

Commit messages:
 - 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server"

Changes: https://git.openjdk.java.net/jdk/pull/7503/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7503&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282017
  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7503.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7503/head:pull/7503

PR: https://git.openjdk.java.net/jdk/pull/7503

From dfuchs at openjdk.java.net  Wed Feb 16 21:49:47 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 16 Feb 2022 21:49:47 GMT
Subject: RFR: 8282017:
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server" [v2]
In-Reply-To: <uHM5y4V6Oqlt5YKk_B4JtOFyK-jSkEKWYOYEkxLwUAU=.e2a285d1-4f39-4713-bba9-eb7db1b44cca@github.com>
References: <uHM5y4V6Oqlt5YKk_B4JtOFyK-jSkEKWYOYEkxLwUAU=.e2a285d1-4f39-4713-bba9-eb7db1b44cca@github.com>
Message-ID: <urB122OIhzeAX1AcOFPAH6IUJ_ivXN8SGvzXLOc4DtU=.77ca1dba-cc5f-483d-9596-d2438e340046@github.com>

> A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure.  The fix is to simply revert that small change.

Daniel Fuchs 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 three additional commits since the last revision:

 - remove sun/net/www/protocol/https/HttpsURLConnection/B6216082.java from ProblemList
 - Merge branch 'master' into B6216082
 - 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server"

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7503/files
  - new: https://git.openjdk.java.net/jdk/pull/7503/files/671fc22b..4f7f9454

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7503&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7503&range=00-01

  Stats: 305 lines in 14 files changed: 286 ins; 14 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7503.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7503/head:pull/7503

PR: https://git.openjdk.java.net/jdk/pull/7503

From mullan at openjdk.java.net  Wed Feb 16 21:57:11 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 16 Feb 2022 21:57:11 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
Message-ID: <jomKLu2tl0JQC6WFpFKY_963deNqb6bZHQ9s4aNGRcI=.d3020f78-a973-42b1-b952-32a724db3252@github.com>

On Tue, 15 Feb 2022 19:51:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retell the formats

src/java.base/share/classes/java/security/cert/X509Certificate.java line 597:

> 595:      * in string form, and a fourth entry for their {@code value} as either
> 596:      * a string (if the value is a valid supported character string)
> 597:      * or (otherwise) a byte array containing the ASN.1 DER encoded from of

typo: s/from/form/

src/java.base/share/classes/java/security/cert/X509Certificate.java line 612:

> 610:      *
> 611:      * @implNote The JDK SUN provider supports the third and fourth
> 612:      * otherName elements.

I would probably use "entries" instead of "elements" to be consistent with the previous wording.

test/jdk/sun/security/x509/OtherName/Parse.java line 27:

> 25:  * @test
> 26:  * @bug 8277976
> 27:  * @summary Break up SEQUENCE in X509Certiticate::getSubjectAlternativeNames

Typo: s/X509Certiticate/X509Certificate/ 
(also on line 28)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From mullan at openjdk.java.net  Wed Feb 16 22:06:08 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 16 Feb 2022 22:06:08 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
Message-ID: <6WNgBgkFfxttmdkB6dnl4t_nGLdiMztSS5i_ckazv_E=.a8285f45-3a6a-4604-ab1e-ff935978f798@github.com>

On Tue, 15 Feb 2022 19:51:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retell the formats

src/java.base/share/classes/java/security/cert/X509Certificate.java line 595:

> 593:      * returned as byte arrays containing the ASN.1 DER encoded form of the
> 594:      * name. There may be a third entry in the list for their {@code type-id}
> 595:      * in string form, and a fourth entry for their {@code value} as either

I think "its" is more grammatically correct than "their".

src/java.base/share/classes/java/security/cert/X509Certificate.java line 597:

> 595:      * in string form, and a fourth entry for their {@code value} as either
> 596:      * a string (if the value is a valid supported character string)
> 597:      * or (otherwise) a byte array containing the ASN.1 DER encoded from of

I don't think you need "(otherwise)" - it is redundant since you already say "either ... or".

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 17 03:13:14 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Feb 2022 03:13:14 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <6WNgBgkFfxttmdkB6dnl4t_nGLdiMztSS5i_ckazv_E=.a8285f45-3a6a-4604-ab1e-ff935978f798@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
 <6WNgBgkFfxttmdkB6dnl4t_nGLdiMztSS5i_ckazv_E=.a8285f45-3a6a-4604-ab1e-ff935978f798@github.com>
Message-ID: <efefn0JI-1bUNqL1Fan9cl8RTNgEAGQFL3atZxVUWnY=.b3bbd282-52ee-4763-9252-1f881b844b42@github.com>

On Wed, 16 Feb 2022 21:56:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   retell the formats
>
> src/java.base/share/classes/java/security/cert/X509Certificate.java line 595:
> 
>> 593:      * returned as byte arrays containing the ASN.1 DER encoded form of the
>> 594:      * name. There may be a third entry in the list for their {@code type-id}
>> 595:      * in string form, and a fourth entry for their {@code value} as either
> 
> I think "its" is more grammatically correct than "their".

The whole paragraph uses plural forms like "IPv4 address names are" and "OID names are", so I also use "otherNames are" and "their". I admit I don't feel comfortable too.

> src/java.base/share/classes/java/security/cert/X509Certificate.java line 597:
> 
>> 595:      * in string form, and a fourth entry for their {@code value} as either
>> 596:      * a string (if the value is a valid supported character string)
>> 597:      * or (otherwise) a byte array containing the ASN.1 DER encoded from of
> 
> I don't think you need "(otherwise)" - it is redundant since you already say "either ... or".

OK.

> src/java.base/share/classes/java/security/cert/X509Certificate.java line 597:
> 
>> 595:      * in string form, and a fourth entry for their {@code value} as either
>> 596:      * a string (if the value is a valid supported character string)
>> 597:      * or (otherwise) a byte array containing the ASN.1 DER encoded from of
> 
> typo: s/from/form/

Oops.

> src/java.base/share/classes/java/security/cert/X509Certificate.java line 612:
> 
>> 610:      *
>> 611:      * @implNote The JDK SUN provider supports the third and fourth
>> 612:      * otherName elements.
> 
> I would probably use "entries" instead of "elements" to be consistent with the previous wording.

Good.

> test/jdk/sun/security/x509/OtherName/Parse.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8277976
>> 27:  * @summary Break up SEQUENCE in X509Certiticate::getSubjectAlternativeNames
> 
> Typo: s/X509Certiticate/X509Certificate/ 
> (also on line 28)

On no.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 17 03:13:15 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Feb 2022 03:13:15 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <efefn0JI-1bUNqL1Fan9cl8RTNgEAGQFL3atZxVUWnY=.b3bbd282-52ee-4763-9252-1f881b844b42@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
 <6WNgBgkFfxttmdkB6dnl4t_nGLdiMztSS5i_ckazv_E=.a8285f45-3a6a-4604-ab1e-ff935978f798@github.com>
 <efefn0JI-1bUNqL1Fan9cl8RTNgEAGQFL3atZxVUWnY=.b3bbd282-52ee-4763-9252-1f881b844b42@github.com>
Message-ID: <hrot9S27Xw2q35RXfYWQeK3J-GAAvkLRGtDZsVq2tCc=.6f006e05-cf00-42c6-9499-17fc8cd694d2@github.com>

On Thu, 17 Feb 2022 03:07:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/cert/X509Certificate.java line 595:
>> 
>>> 593:      * returned as byte arrays containing the ASN.1 DER encoded form of the
>>> 594:      * name. There may be a third entry in the list for their {@code type-id}
>>> 595:      * in string form, and a fourth entry for their {@code value} as either
>> 
>> I think "its" is more grammatically correct than "their".
>
> The whole paragraph uses plural forms like "IPv4 address names are" and "OID names are", so I also use "otherNames are" and "their". I admit I don't feel comfortable too.

I thought about "the", but it does not show the belong to relation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From arjan.tijms at gmail.com  Thu Feb 17 13:29:04 2022
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 17 Feb 2022 14:29:04 +0100
Subject: deprecation of SecurityManager JEP 411
In-Reply-To: <LNXP265MB0443D4A9AB4338B79BA3DE25F75D9@LNXP265MB0443.GBRP265.PROD.OUTLOOK.COM>
References: <LNXP265MB0443D4A9AB4338B79BA3DE25F75D9@LNXP265MB0443.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <CAE=-AhCEDoMjOmmr_crX62_sHqitPjvoKihsocoUMvy7MU_x_Q@mail.gmail.com>

Hi,

On Wed, Feb 16, 2022 at 6:24 PM Bowes, David <d.h.bowes at lancaster.ac.uk>
wrote:

> I used the SecurityManger with great success to protect against Log4JShell.
>
>
>
> [...]  I would suggest that the SecurityManager does protect me from
> singinficant threats.
>

While I don't disagree with you entirely, the problem is that seemingly
almost nobody actually uses the security manager to protect against things
like Log4JShell. The proof is in the pudding. If the security manager
indeed protected against that in practice to a sufficient degree, then
Log4JShell wouldn't have been a problem at all, would it? Yet it was, and
the security manager is still there at the moment.

I understand one could argue that without the security manager the impact
of Log4JShell would have been even bigger, but I've not seen any evidence
stating that.

Given the way Java is now predominantly used, I think a better choice might
be to have the Java applications run on virtual servers that restrict at
that virtual server level which domains and IPs outgoing traffic may
connect to.

Finally, I think nobody is saying there is no value at all in the security
manager, but just that the amount of work required to maintain it vs the
practical benefits are non-optimal, at least with the current way the
security manager and its permissions and policies work.

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220217/7637e4a2/attachment.htm>

From mullan at openjdk.java.net  Thu Feb 17 15:39:13 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 17 Feb 2022 15:39:13 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <hrot9S27Xw2q35RXfYWQeK3J-GAAvkLRGtDZsVq2tCc=.6f006e05-cf00-42c6-9499-17fc8cd694d2@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
 <6WNgBgkFfxttmdkB6dnl4t_nGLdiMztSS5i_ckazv_E=.a8285f45-3a6a-4604-ab1e-ff935978f798@github.com>
 <efefn0JI-1bUNqL1Fan9cl8RTNgEAGQFL3atZxVUWnY=.b3bbd282-52ee-4763-9252-1f881b844b42@github.com>
 <hrot9S27Xw2q35RXfYWQeK3J-GAAvkLRGtDZsVq2tCc=.6f006e05-cf00-42c6-9499-17fc8cd694d2@github.com>
Message-ID: <BLaIS9IFhWqrNpA7JFOnMrzF_j_MKtcL9jGVPB80W3Y=.d3d7da2a-680a-4c77-98ee-9d69c0a8cef0@github.com>

On Thu, 17 Feb 2022 03:07:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The whole paragraph uses plural forms like "IPv4 address names are" and "OID names are", so I also use "otherNames are" and "their". I admit I don't feel comfortable too.
>
> I thought about "the", but it does not show the belong to relation.

What you can do is reword the sentence by including `otherName` in it, ex: "A third entry may also be present in the list containing the {@code type-id} of the otherName in string form, and a fourth entry containing the {@code value} of the otherName as either ...".

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 17 15:53:57 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Feb 2022 15:53:57 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v7]
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <x_o0FpG_9BigRjGovUdUGpR0xsqHNe56zHiN4pzyLZY=.b010ea09-e211-4d1f-9b49-2dc1b5fb3681@github.com>

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  hopefully the final wording

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7167/files
  - new: https://git.openjdk.java.net/jdk/pull/7167/files/a610bc5d..550f14ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=05-06

  Stats: 9 lines in 2 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 17 16:00:46 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Feb 2022 16:00:46 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v8]
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <EaMO7CacEdc-tDs-7Iwp8WTpIkgGM3kAp6yvZGuxIMU=.6912b1ff-f783-43e0-be73-b78eb04ca5f2@github.com>

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  s/can/may/

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7167/files
  - new: https://git.openjdk.java.net/jdk/pull/7167/files/550f14ab..5043812c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 17 16:00:47 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Feb 2022 16:00:47 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v6]
In-Reply-To: <BLaIS9IFhWqrNpA7JFOnMrzF_j_MKtcL9jGVPB80W3Y=.d3d7da2a-680a-4c77-98ee-9d69c0a8cef0@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <WYeAi_tSogt4aColTLW_UF8yLwE0AU7QQDt6FYaPmnw=.b6fb23b8-06f7-49b9-bcf7-ce9e84ef14bd@github.com>
 <6WNgBgkFfxttmdkB6dnl4t_nGLdiMztSS5i_ckazv_E=.a8285f45-3a6a-4604-ab1e-ff935978f798@github.com>
 <efefn0JI-1bUNqL1Fan9cl8RTNgEAGQFL3atZxVUWnY=.b3bbd282-52ee-4763-9252-1f881b844b42@github.com>
 <hrot9S27Xw2q35RXfYWQeK3J-GAAvkLRGtDZsVq2tCc=.6f006e05-cf00-42c6-9499-17fc8cd694d2@github.com>
 <BLaIS9IFhWqrNpA7JFOnMrzF_j_MKtcL9jGVPB80W3Y=.d3d7da2a-680a-4c77-98ee-9d69c0a8cef0@github.com>
Message-ID: <Sgrt_35Z4OzeJXkjeCZ-hSyO6tgbxkz-CekN2cZaNsM=.ccdc8c1a-1c7e-44f0-b3e5-5ac7134d302b@github.com>

On Thu, 17 Feb 2022 15:36:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I thought about "the", but it does not show the belong to relation.
>
> What you can do is reword the sentence by including `otherName` in it, ex: "A third entry may also be present in the list containing the {@code type-id} of the otherName in string form, and a fourth entry containing the {@code value} of the otherName as either ...".

New commits pushed. CSR re-finalized.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Thu Feb 17 17:21:36 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Thu, 17 Feb 2022 17:21:36 GMT
Subject: RFR: JDK-8282017 :
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server"
Message-ID: <c-fL53s_j_R5gll4PKbKPNfWobwGyJkIzMKuybMgtLM=.1fa87293-c6df-4da8-a036-6f4e145b19f4@github.com>

Updated TunnelProxy to avoid twice read of Request line.

-------------

Commit messages:
 - JDK-8282017 : sun/net/www/protocol/https/HttpsURLConnection/B6216082.java

Changes: https://git.openjdk.java.net/jdk/pull/7519/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7519&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282017
  Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7519.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7519/head:pull/7519

PR: https://git.openjdk.java.net/jdk/pull/7519

From duke at openjdk.java.net  Thu Feb 17 17:35:12 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Thu, 17 Feb 2022 17:35:12 GMT
Subject: RFR: JDK-8282017 :
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server"
In-Reply-To: <c-fL53s_j_R5gll4PKbKPNfWobwGyJkIzMKuybMgtLM=.1fa87293-c6df-4da8-a036-6f4e145b19f4@github.com>
References: <c-fL53s_j_R5gll4PKbKPNfWobwGyJkIzMKuybMgtLM=.1fa87293-c6df-4da8-a036-6f4e145b19f4@github.com>
Message-ID: <SeMLno9WsLOi0RPZYkSqMwgTyOhNzBDayqzNHo_Meec=.b8bd4bd6-8dc7-4dd7-aabb-01d7d2c16fe3@github.com>

On Thu, 17 Feb 2022 17:13:38 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

> Updated TunnelProxy to avoid twice read of Request line.

tier 2 mach5 Job : https://mach5.us.oracle.com/mdash/jobs/mahendrachhipa-jdk-20220217-1608-29227569

-------------

PR: https://git.openjdk.java.net/jdk/pull/7519

From dfuchs at openjdk.java.net  Thu Feb 17 17:35:12 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Feb 2022 17:35:12 GMT
Subject: RFR: JDK-8282017 :
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server"
In-Reply-To: <c-fL53s_j_R5gll4PKbKPNfWobwGyJkIzMKuybMgtLM=.1fa87293-c6df-4da8-a036-6f4e145b19f4@github.com>
References: <c-fL53s_j_R5gll4PKbKPNfWobwGyJkIzMKuybMgtLM=.1fa87293-c6df-4da8-a036-6f4e145b19f4@github.com>
Message-ID: <1vlU0C37AbrMo-nnD2KW5pU5vje0zqxBS2iIyV3l_vw=.656d0f63-0c3c-4ba7-b945-5ef52e3ae3e5@github.com>

On Thu, 17 Feb 2022 17:13:38 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

> Updated TunnelProxy to avoid twice read of Request line.

Looks good to me Mahendra. I will withdraw my own PR. Just make sure to run the whole of tier2 :-)

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7519

From dfuchs at openjdk.java.net  Thu Feb 17 17:36:21 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Feb 2022 17:36:21 GMT
Subject: RFR: 8282017:
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server" [v2]
In-Reply-To: <urB122OIhzeAX1AcOFPAH6IUJ_ivXN8SGvzXLOc4DtU=.77ca1dba-cc5f-483d-9596-d2438e340046@github.com>
References: <uHM5y4V6Oqlt5YKk_B4JtOFyK-jSkEKWYOYEkxLwUAU=.e2a285d1-4f39-4713-bba9-eb7db1b44cca@github.com>
 <urB122OIhzeAX1AcOFPAH6IUJ_ivXN8SGvzXLOc4DtU=.77ca1dba-cc5f-483d-9596-d2438e340046@github.com>
Message-ID: <n2_4m8hgBXDojOI9QEFpRyzSkBWKa0ZZXmkYAdCU7AU=.e7a44463-ceac-4582-ad69-eb4f140734ef@github.com>

On Wed, 16 Feb 2022 21:49:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure.  The fix is to simply revert that small change.
>
> Daniel Fuchs 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 three additional commits since the last revision:
> 
>  - remove sun/net/www/protocol/https/HttpsURLConnection/B6216082.java from ProblemList
>  - Merge branch 'master' into B6216082
>  - 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server"

I talked with @mahendrachhipa who has suggested a better fix. Closing this PR as a result.
See https://github.com/openjdk/jdk/pull/7519

-------------

PR: https://git.openjdk.java.net/jdk/pull/7503

From dfuchs at openjdk.java.net  Thu Feb 17 17:36:21 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Feb 2022 17:36:21 GMT
Subject: Withdrawn: 8282017:
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server"
In-Reply-To: <uHM5y4V6Oqlt5YKk_B4JtOFyK-jSkEKWYOYEkxLwUAU=.e2a285d1-4f39-4713-bba9-eb7db1b44cca@github.com>
References: <uHM5y4V6Oqlt5YKk_B4JtOFyK-jSkEKWYOYEkxLwUAU=.e2a285d1-4f39-4713-bba9-eb7db1b44cca@github.com>
Message-ID: <o0wK0wpDDgP2A7nKAV44oUn3s970SXZlyPZ2FDC2L-s=.b8d21b7a-820d-49c8-8e8b-197b0dd49c74@github.com>

On Wed, 16 Feb 2022 21:10:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure.  The fix is to simply revert that small change.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7503

From duke at openjdk.java.net  Thu Feb 17 17:49:08 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Thu, 17 Feb 2022 17:49:08 GMT
Subject: Integrated: JDK-8282017 :
 sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
 "SocketException: Unexpected end of file from server"
In-Reply-To: <c-fL53s_j_R5gll4PKbKPNfWobwGyJkIzMKuybMgtLM=.1fa87293-c6df-4da8-a036-6f4e145b19f4@github.com>
References: <c-fL53s_j_R5gll4PKbKPNfWobwGyJkIzMKuybMgtLM=.1fa87293-c6df-4da8-a036-6f4e145b19f4@github.com>
Message-ID: <pcdjFsPzE8pY_kcynkKqr9C3lFirIEbv-c2aRXtZOnU=.db6819d2-b5d4-4e13-9411-6c9fec2837cf@github.com>

On Thu, 17 Feb 2022 17:13:38 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

> Updated TunnelProxy to avoid twice read of Request line.

This pull request has now been integrated.

Changeset: cd9a3cf0
Author:    Mahendra Chhipa <mahendra.chhipa at oracle.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cd9a3cf05b2c200709103e2e8596414a62a1c441
Stats:     5 lines in 2 files changed: 0 ins; 2 del; 3 mod

8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server"

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/7519

From xuelei at openjdk.java.net  Thu Feb 17 18:57:02 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 17 Feb 2022 18:57:02 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v18]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <ewHj78abz54Drk1YXj7HeUvqR5Y8WBqOOd5SvS3Tl8M=.dbb12bc6-72f2-474f-b7e3-a04efef3915b@github.com>

> 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:

  more spec update per CSR feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/bbc3bb8e..5a98c921

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=16-17

  Stats: 15 lines in 1 file changed: 1 ins; 12 del; 2 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

From lancea at openjdk.java.net  Thu Feb 17 19:00:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 17 Feb 2022 19:00:47 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Return null when ZipEntry::getName is null

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7348/files
  - new: https://git.openjdk.java.net/jdk/pull/7348/files/32f6c284..d5cf8db8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=02-03

  Stats: 201 lines in 2 files changed: 34 ins; 96 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Thu Feb 17 19:05:13 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 17 Feb 2022 19:05:13 GMT
Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing
 ze.getName() [v3]
In-Reply-To: <0COr36OwTtowa8BVOnS_ZSR7mhByee9jwWl6f-4ps3E=.1969f9d1-bbae-45bb-818f-cfa7864a802d@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com>
 <Cjl5qGHuvSPFWwWf7Zm1FP44-qcS-sRopciQW4P-1ig=.64d57672-5adb-43b0-92bb-e78f3352fab7@github.com>
 <0COr36OwTtowa8BVOnS_ZSR7mhByee9jwWl6f-4ps3E=.1969f9d1-bbae-45bb-818f-cfa7864a802d@github.com>
Message-ID: <nsyOf61YMw-a5PQRVUv_yTNiA_acpFoDw53DGuVw1QQ=.958e967f-6923-4667-b63d-71f54d400dfa@github.com>

On Fri, 11 Feb 2022 17:43:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarFile.java line 881:
>> 
>>> 879:             ze = getJarEntry(entryName);
>>> 880:         } else {
>>> 881:             throw new ZipException("ZipEntry::getName returned null");
>> 
>> Throwing ZipException when ZipEntry::getName returns null is still surprising but not terrible.  The spec for getInputStream specifies ZipException for when a zip file format occurs so we might have to extend that to add "or the zip entry name is null".
>
> If you  would like me to update the ZipException to clarify this I can.   The original issue was due to a format error in the CEN so the current wording covers that.  It does not cover the case where ZipEntry is subclassed and ZipEntry::getName() returns null which is what your suggested wording would address.
> 
> Please note the above change addresses the signed jar scenario.  I can add an additional check in JarFile::getInputStream to check for null from ZipEntry::getName so that it covers unsigned jars and signed jars not being verified.
> 
> The issue will not occur with ZipEFile::getInputStream given its use of ZipEntry.name which can never be null.
> 
> Another thought would be to return null for the InputStream similar to when the ZipEntry does not represent a file within the Jar
> 
> Please let me know your preference

Per a discussion with Sean and Alan,  we are now returning null for the InputStream to be consistent with ZipFile::getInputStream and how unsigned jars are handled

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From duke at openjdk.java.net  Thu Feb 17 19:46:19 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Thu, 17 Feb 2022 19:46:19 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
Message-ID: <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>

On Tue, 15 Feb 2022 15:55:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Correct, but they don't swallow at least.
>
> But in this case, we still have a place to provide the raw bytes. Maybe that's better? Or you'd rather be guaranteed that one particular otherName should always have a string there and there's no need to do an `instanceof` check? What if the tag is already wrong and I don't know it should be a string?

@wangweij So you have selected to really swallow the exception here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Thu Feb 17 20:45:12 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Feb 2022 20:45:12 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
 <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>
Message-ID: <V0MscxqmMpu2BEmwzured1JA6zS0aT2-t1vNmjTuG6U=.ea874ac4-0e10-4bf5-853d-072270b3d0dd@github.com>

On Thu, 17 Feb 2022 19:42:30 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> But in this case, we still have a place to provide the raw bytes. Maybe that's better? Or you'd rather be guaranteed that one particular otherName should always have a string there and there's no need to do an `instanceof` check? What if the tag is already wrong and I don't know it should be a string?
>
> @wangweij So you have selected to really swallow the exception here?

Yes. I don't want to let the method fail. Since `instanceof String` should be called anyway the caller can decide how to fail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From arjan.tijms at gmail.com  Thu Feb 17 20:49:13 2022
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 17 Feb 2022 21:49:13 +0100
Subject: [External] Re: deprecation of SecurityManager JEP 411
In-Reply-To: <LNXP265MB04431015CFBF091FC3DDEB57F7369@LNXP265MB0443.GBRP265.PROD.OUTLOOK.COM>
References: <LNXP265MB0443D4A9AB4338B79BA3DE25F75D9@LNXP265MB0443.GBRP265.PROD.OUTLOOK.COM>
 <CAE=-AhCEDoMjOmmr_crX62_sHqitPjvoKihsocoUMvy7MU_x_Q@mail.gmail.com>
 <LNXP265MB04431015CFBF091FC3DDEB57F7369@LNXP265MB0443.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <CAE=-AhBa0LQ8DgEtV6LfPZsaa8Xyj-XUuCkzNMV67Kwi3sfBgA@mail.gmail.com>

Hi,

On Thu, Feb 17, 2022 at 5:45 PM Bowes, David <d.h.bowes at lancaster.ac.uk>
wrote:

> Your  argument follows  ?10,000 lemmings can?t be wrong?....
>

I didn't mean to say that the 10k lemmings are right. What I was trying to
say is that the JDK team was making a tool that 10k-1 lemmings are not
using. So for the 1 lemming who is using the tool as intended, the costs of
maintaining it are seemingly too high.

Kind regards,
Arjan



>
>
> David
>
>
>
>
>
>
> ------------------------------
> *From:* arjan tijms <arjan.tijms at gmail.com>
> *Sent:* Thursday, February 17, 2022 1:29:04 PM
> *To:* Bowes, David <d.h.bowes at lancaster.ac.uk>
> *Cc:* security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> *Subject:* [External] Re: deprecation of SecurityManager JEP 411
>
>
> *This email originated outside the University. Check before clicking links
> or attachments.*
> Hi,
>
> On Wed, Feb 16, 2022 at 6:24 PM Bowes, David <d.h.bowes at lancaster.ac.uk>
> wrote:
>
> I used the SecurityManger with great success to protect against Log4JShell.
>
>
>
> [...]  I would suggest that the SecurityManager does protect me from
> singinficant threats.
>
>
> While I don't disagree with you entirely, the problem is that seemingly
> almost nobody actually uses the security manager to protect against things
> like Log4JShell. The proof is in the pudding. If the security manager
> indeed protected against that in practice to a sufficient degree, then
> Log4JShell wouldn't have been a problem at all, would it? Yet it was, and
> the security manager is still there at the moment.
>
> I understand one could argue that without the security manager the impact
> of Log4JShell would have been even bigger, but I've not seen any evidence
> stating that.
>
> Given the way Java is now predominantly used, I think a better choice
> might be to have the Java applications run on virtual servers that restrict
> at that virtual server level which domains and IPs outgoing traffic may
> connect to.
>
> Finally, I think nobody is saying there is no value at all in the security
> manager, but just that the amount of work required to maintain it vs the
> practical benefits are non-optimal, at least with the current way the
> security manager and its permissions and policies work.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220217/28d59d0a/attachment.htm>

From geertjan at apache.org  Thu Feb 17 21:04:43 2022
From: geertjan at apache.org (Geertjan Wielenga)
Date: Thu, 17 Feb 2022 22:04:43 +0100
Subject: [External] Re: deprecation of SecurityManager JEP 411
In-Reply-To: <CAE=-AhBa0LQ8DgEtV6LfPZsaa8Xyj-XUuCkzNMV67Kwi3sfBgA@mail.gmail.com>
References: <LNXP265MB0443D4A9AB4338B79BA3DE25F75D9@LNXP265MB0443.GBRP265.PROD.OUTLOOK.COM>
 <CAE=-AhCEDoMjOmmr_crX62_sHqitPjvoKihsocoUMvy7MU_x_Q@mail.gmail.com>
 <LNXP265MB04431015CFBF091FC3DDEB57F7369@LNXP265MB0443.GBRP265.PROD.OUTLOOK.COM>
 <CAE=-AhBa0LQ8DgEtV6LfPZsaa8Xyj-XUuCkzNMV67Kwi3sfBgA@mail.gmail.com>
Message-ID: <CACkjAxT_FBE_ZB4fZch3yzXCQrvskQsnhQE3ot0SkAtM3hxYoQ@mail.gmail.com>

Unless there is a phone home mechanism built into the SecurityManager,
nobody knows or can claim to know how widely the SecurityManager is being
used.

No, survey results don?t prove anything because people don?t fill in
surveys. No, calls for people to report on their usage don?t mean anything
in determining who and how many are using anything.

The assumption should be ? in the absence of proof otherwise ? that the
SecurityManager is very widely used, that where it is used it is mission
critical, and that unless there is a migration path to something at least
equivalent, deprecation should not be on the table.

Gj


On Thu, 17 Feb 2022 at 21:50, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> On Thu, Feb 17, 2022 at 5:45 PM Bowes, David <d.h.bowes at lancaster.ac.uk>
> wrote:
>
>> Your  argument follows  ?10,000 lemmings can?t be wrong?....
>>
>
> I didn't mean to say that the 10k lemmings are right. What I was trying to
> say is that the JDK team was making a tool that 10k-1 lemmings are not
> using. So for the 1 lemming who is using the tool as intended, the costs of
> maintaining it are seemingly too high.
>
> Kind regards,
> Arjan
>
>
>
>>
>>
>> David
>>
>>
>>
>>
>>
>>
>> ------------------------------
>> *From:* arjan tijms <arjan.tijms at gmail.com>
>> *Sent:* Thursday, February 17, 2022 1:29:04 PM
>> *To:* Bowes, David <d.h.bowes at lancaster.ac.uk>
>> *Cc:* security-dev at openjdk.java.net <security-dev at openjdk.java.net>
>> *Subject:* [External] Re: deprecation of SecurityManager JEP 411
>>
>>
>> *This email originated outside the University. Check before clicking
>> links or attachments.*
>>
> Hi,
>>
>> On Wed, Feb 16, 2022 at 6:24 PM Bowes, David <d.h.bowes at lancaster.ac.uk>
>> wrote:
>>
>> I used the SecurityManger with great success to protect against
>> Log4JShell.
>>
>>
>>
>> [...]  I would suggest that the SecurityManager does protect me from
>> singinficant threats.
>>
>>
>> While I don't disagree with you entirely, the problem is that seemingly
>> almost nobody actually uses the security manager to protect against things
>> like Log4JShell. The proof is in the pudding. If the security manager
>> indeed protected against that in practice to a sufficient degree, then
>> Log4JShell wouldn't have been a problem at all, would it? Yet it was, and
>> the security manager is still there at the moment.
>>
>> I understand one could argue that without the security manager the impact
>> of Log4JShell would have been even bigger, but I've not seen any evidence
>> stating that.
>>
>> Given the way Java is now predominantly used, I think a better choice
>> might be to have the Java applications run on virtual servers that restrict
>> at that virtual server level which domains and IPs outgoing traffic may
>> connect to.
>>
>> Finally, I think nobody is saying there is no value at all in the
>> security manager, but just that the amount of work required to maintain it
>> vs the practical benefits are non-optimal, at least with the current way
>> the security manager and its permissions and policies work.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220217/ce39f664/attachment-0001.htm>

From weijun at openjdk.java.net  Thu Feb 17 23:38:23 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Feb 2022 23:38:23 GMT
Subject: RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa
Message-ID: <uyCT3QLxXOhEjf7A3aIz2nbkH_vfyJzvOS_ohT82nb8=.66e09a4a-c37c-4c40-8784-1790fcea5374@github.com>

Updating to a recent release of PSL.

-------------

Commit messages:
 - 8255266: 2021-11-27 public suffix list update v 3c213aa

Changes: https://git.openjdk.java.net/jdk/pull/7526/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7526&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255266
  Stats: 1254 lines in 5 files changed: 887 ins; 215 del; 152 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7526/head:pull/7526

PR: https://git.openjdk.java.net/jdk/pull/7526

From xuelei at openjdk.java.net  Fri Feb 18 04:48:51 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Feb 2022 04:48:51 GMT
Subject: RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa
In-Reply-To: <uyCT3QLxXOhEjf7A3aIz2nbkH_vfyJzvOS_ohT82nb8=.66e09a4a-c37c-4c40-8784-1790fcea5374@github.com>
References: <uyCT3QLxXOhEjf7A3aIz2nbkH_vfyJzvOS_ohT82nb8=.66e09a4a-c37c-4c40-8784-1790fcea5374@github.com>
Message-ID: <LEzbKE1lzUvbF3bqBkxxpWt6wf1TiMJUgqB38BBvL3w=.93f514cd-98d7-4f5e-a9a4-f512adf71835@github.com>

On Thu, 17 Feb 2022 23:28:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Updating to a recent release of PSL.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7526

From duke at openjdk.java.net  Fri Feb 18 06:58:53 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Fri, 18 Feb 2022 06:58:53 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <V0MscxqmMpu2BEmwzured1JA6zS0aT2-t1vNmjTuG6U=.ea874ac4-0e10-4bf5-853d-072270b3d0dd@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
 <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>
 <V0MscxqmMpu2BEmwzured1JA6zS0aT2-t1vNmjTuG6U=.ea874ac4-0e10-4bf5-853d-072270b3d0dd@github.com>
Message-ID: <YSSE-oLT9s_CEuDvTxvNbeReMdlc2tBZSzA2ptgFxjI=.04c92822-e1da-41e3-9a81-7d4e0361c6a9@github.com>

On Thu, 17 Feb 2022 20:41:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> @wangweij So you have selected to really swallow the exception here?
>
> Yes. I don't want to let the method fail. Since `instanceof String` should be called anyway the caller can decide how to fail.

So you leave it to the user to read the ASN.1 value and fail if the encoding is incorrect instead of throwing a `Ceritificate..Exception` although other GeneralNames do?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Fri Feb 18 08:45:51 2022
From: duke at openjdk.java.net (Ahmad shabib)
Date: Fri, 18 Feb 2022 08:45:51 GMT
Subject: RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa
In-Reply-To: <uyCT3QLxXOhEjf7A3aIz2nbkH_vfyJzvOS_ohT82nb8=.66e09a4a-c37c-4c40-8784-1790fcea5374@github.com>
References: <uyCT3QLxXOhEjf7A3aIz2nbkH_vfyJzvOS_ohT82nb8=.66e09a4a-c37c-4c40-8784-1790fcea5374@github.com>
Message-ID: <iFJAqK7S5u3t1vzBkQ0yJFPSDZrYalcrDARSgwwhmNU=.b798021e-0c97-45f8-8543-a025488d93ce@github.com>

On Thu, 17 Feb 2022 23:28:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Updating to a recent release of PSL.

Marked as reviewed by ahmadshabib at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7526

From alanb at openjdk.java.net  Fri Feb 18 12:12:54 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 18 Feb 2022 12:12:54 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
Message-ID: <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>

On Thu, 17 Feb 2022 19:00:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the attached patch to address
>> 
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
>> 
>> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return null when ZipEntry::getName is null

The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From weijun at openjdk.java.net  Fri Feb 18 15:08:10 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 18 Feb 2022 15:08:10 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <YSSE-oLT9s_CEuDvTxvNbeReMdlc2tBZSzA2ptgFxjI=.04c92822-e1da-41e3-9a81-7d4e0361c6a9@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
 <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>
 <V0MscxqmMpu2BEmwzured1JA6zS0aT2-t1vNmjTuG6U=.ea874ac4-0e10-4bf5-853d-072270b3d0dd@github.com>
 <YSSE-oLT9s_CEuDvTxvNbeReMdlc2tBZSzA2ptgFxjI=.04c92822-e1da-41e3-9a81-7d4e0361c6a9@github.com>
Message-ID: <Ru5VRj7tj8Kht6PQvPc_VTUQN5kIrw2bNNFVDuNuZI8=.2ad0bf63-7b27-4d66-ba90-827ece1b73a1@github.com>

On Fri, 18 Feb 2022 06:56:04 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> Yes. I don't want to let the method fail. Since `instanceof String` should be called anyway the caller can decide how to fail.
>
> So you leave it to the user to read the ASN.1 value and fail if the encoding is incorrect instead of throwing a `Ceritificate..Exception` although other GeneralNames do?

I want to minimize behavior change and I'm leaving them to notice there's no string there and fail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From duke at openjdk.java.net  Fri Feb 18 15:21:02 2022
From: duke at openjdk.java.net (Michael Osipov)
Date: Fri, 18 Feb 2022 15:21:02 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <Ru5VRj7tj8Kht6PQvPc_VTUQN5kIrw2bNNFVDuNuZI8=.2ad0bf63-7b27-4d66-ba90-827ece1b73a1@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
 <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>
 <V0MscxqmMpu2BEmwzured1JA6zS0aT2-t1vNmjTuG6U=.ea874ac4-0e10-4bf5-853d-072270b3d0dd@github.com>
 <YSSE-oLT9s_CEuDvTxvNbeReMdlc2tBZSzA2ptgFxjI=.04c92822-e1da-41e3-9a81-7d4e0361c6a9@github.com>
 <Ru5VRj7tj8Kht6PQvPc_VTUQN5kIrw2bNNFVDuNuZI8=.2ad0bf63-7b27-4d66-ba90-827ece1b73a1@github.com>
Message-ID: <Ln5haQUjEdghujvspZVICAi4J6p9BoFy1B2mZeyXP2A=.5cfaa7a2-b304-4bab-b5ff-1145fe5e3f0a@github.com>

On Fri, 18 Feb 2022 15:06:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> So you leave it to the user to read the ASN.1 value and fail if the encoding is incorrect instead of throwing a `Ceritificate..Exception` although other GeneralNames do?
>
> I want to minimize behavior change and I'm leaving them to notice there's no string there and fail.

While I understand that, `new DerValue(byte[])` will be ignored and this will be inconsistent with the remaining general names. Looking at sun.security.x509.GeneralName.GeneralName(DerValue, boolean) they all throw `IOException`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From lancea at openjdk.java.net  Fri Feb 18 16:28:55 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 18 Feb 2022 16:28:55 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
 <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>
Message-ID: <riKR0vsWbUnHTGPDGrI3oJNiEeYWZynZfEMJXYI619U=.b034d397-20d0-406f-9eb6-d51ba58f5950@github.com>

On Fri, 18 Feb 2022 12:09:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array.

Those instructions are already in the comments for the constant `SIGNED_VALID_ENTRY_NAME`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From weijun at openjdk.java.net  Fri Feb 18 16:31:55 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 18 Feb 2022 16:31:55 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <Ln5haQUjEdghujvspZVICAi4J6p9BoFy1B2mZeyXP2A=.5cfaa7a2-b304-4bab-b5ff-1145fe5e3f0a@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
 <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>
 <V0MscxqmMpu2BEmwzured1JA6zS0aT2-t1vNmjTuG6U=.ea874ac4-0e10-4bf5-853d-072270b3d0dd@github.com>
 <YSSE-oLT9s_CEuDvTxvNbeReMdlc2tBZSzA2ptgFxjI=.04c92822-e1da-41e3-9a81-7d4e0361c6a9@github.com>
 <Ru5VRj7tj8Kht6PQvPc_VTUQN5kIrw2bNNFVDuNuZI8=.2ad0bf63-7b27-4d66-ba90-827ece1b73a1@github.com>
 <Ln5haQUjEdghujvspZVICAi4J6p9BoFy1B2
 mZeyXP2A=.5cfaa7a2-b304-4bab-b5ff-1145fe5e3f0a@github.com>
Message-ID: <CpDdi0wPl6q9gMRz1WmMR4NpDhjK1arRn9MxM_VvsZ0=.0b42c294-1ade-48dc-937a-69d794524614@github.com>

On Fri, 18 Feb 2022 15:17:30 GMT, Michael Osipov <duke at openjdk.java.net> wrote:

>> I want to minimize behavior change and I'm leaving them to notice there's no string there and fail.
>
> While I understand that, `new DerValue(byte[])` will be ignored and this will be also inconsistent with the remaining general names. Looking at sun.security.x509.GeneralName.GeneralName(DerValue, boolean) they all throw `IOException`.

For other known names, you either return a parsed name or fail. For `otherName`, you already have the raw data and this further parsed name is a bonus. I just don't like a problem in getting the bonus to ruin the original benefit. Also, I think the caller will have to check the length and the type anyway so this will not be an extra burden. Besides, I always feel that `otherName` could be freely extended and the quality of its encoding might not be as guaranteed as the other ones. @seanjmullan, any comment here?

Too many "other" used and hopefully no one get confused.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From mullan at openjdk.java.net  Fri Feb 18 16:37:57 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 18 Feb 2022 16:37:57 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <CpDdi0wPl6q9gMRz1WmMR4NpDhjK1arRn9MxM_VvsZ0=.0b42c294-1ade-48dc-937a-69d794524614@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <NZAENoKirwBcLivgoQ719ccx2hU1DikoNmJHp_p7k2c=.6554093b-bbee-44cc-8cc7-7ae74ce35faa@github.com>
 <xfo5ItmSD42uqk9CAyQ_9Px7FhnuRfoxca94jSZhVGA=.5c58fcc9-293c-4207-ba85-aca9ddb1ebff@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
 <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>
 <V0MscxqmMpu2BEmwzured1JA6zS0aT2-t1vNmjTuG6U=.ea874ac4-0e10-4bf5-853d-072270b3d0dd@github.com>
 <YSSE-oLT9s_CEuDvTxvNbeReMdlc2tBZSzA2ptgFxjI=.04c92822-e1da-41e3-9a81-7d4e0361c6a9@github.com>
 <Ru5VRj7tj8Kht6PQvPc_VTUQN5kIrw2bNNFVDuNuZI8=.2ad0bf63-7b27-4d66-ba90-827ece1b73a1@github.com>
 <Ln5haQUjEdghujvspZVICAi4J6p9BoFy1B2
 mZeyXP2A=.5cfaa7a2-b304-4bab-b5ff-1145fe5e3f0a@github.com>
 <CpDdi0wPl6q9gMRz1WmMR4NpDhjK1arRn9MxM_VvsZ0=.0b42c294-1ade-48dc-937a-69d794524614@github.com>
Message-ID: <Rxe5X5wjAnOReV9L-AO7XFgQRQqTtYCAUfT02odoydw=.e0063dcf-148f-4bb7-961a-05bf61ff1ca6@github.com>

On Fri, 18 Feb 2022 16:28:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> While I understand that, `new DerValue(byte[])` will be ignored and this will be also inconsistent with the remaining general names. Looking at sun.security.x509.GeneralName.GeneralName(DerValue, boolean) they all throw `IOException`.
>
> For other known names, you either return a parsed name or fail. For `otherName`, you already have the raw data and this further parsed name is a bonus. I just don't like a problem in getting the bonus to ruin the original benefit. Also, I think the caller will have to check the length and the type anyway so this will not be an extra burden. Besides, I always feel that `otherName` could be freely extended and the quality of its encoding might not be as guaranteed as the other ones. @seanjmullan, any comment here?
> 
> Too many "other" used and hopefully no one get confused.

This seems like a reasonable balance between preserving existing behavior and still providing the data for the application to inspect. To help debugging, you could log the exception.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Fri Feb 18 16:38:49 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 18 Feb 2022 16:38:49 GMT
Subject: Integrated: 8255266: Update Public Suffix List to 3c213aa
In-Reply-To: <uyCT3QLxXOhEjf7A3aIz2nbkH_vfyJzvOS_ohT82nb8=.66e09a4a-c37c-4c40-8784-1790fcea5374@github.com>
References: <uyCT3QLxXOhEjf7A3aIz2nbkH_vfyJzvOS_ohT82nb8=.66e09a4a-c37c-4c40-8784-1790fcea5374@github.com>
Message-ID: <uAeOKg9y_YXhzrOuThcTiLKo7plz3ca84OTa4BRU2xs=.c0ab5aa6-430a-48c7-813d-5e791e1f6d68@github.com>

On Thu, 17 Feb 2022 23:28:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Updating to a recent release of PSL.

This pull request has now been integrated.

Changeset: 7ce75afb
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ce75afbbcca7635356c7377be7ddff15335e563
Stats:     1254 lines in 5 files changed: 887 ins; 215 del; 152 mod

8255266: Update Public Suffix List to 3c213aa

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/7526

From alanb at openjdk.java.net  Fri Feb 18 17:08:55 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 18 Feb 2022 17:08:55 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <riKR0vsWbUnHTGPDGrI3oJNiEeYWZynZfEMJXYI619U=.b034d397-20d0-406f-9eb6-d51ba58f5950@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
 <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>
 <riKR0vsWbUnHTGPDGrI3oJNiEeYWZynZfEMJXYI619U=.b034d397-20d0-406f-9eb6-d51ba58f5950@github.com>
Message-ID: <PTEcgCoMTQRuvK2OJhzhAuMjCWDzYw9-dozemvUYqTQ=.8bf8b1e6-dde5-4f73-8cab-d8ddcba0b101@github.com>

On Fri, 18 Feb 2022 16:25:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array.
> 
> Those instructions are already in the comments for the constant `SIGNED_VALID_ENTRY_NAME`

That's the keytool command to sign the JAR. What I meant is the complete steps to create the JAR file, sign it, and then create the byte array.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Fri Feb 18 17:18:56 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 18 Feb 2022 17:18:56 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <PTEcgCoMTQRuvK2OJhzhAuMjCWDzYw9-dozemvUYqTQ=.8bf8b1e6-dde5-4f73-8cab-d8ddcba0b101@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
 <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>
 <riKR0vsWbUnHTGPDGrI3oJNiEeYWZynZfEMJXYI619U=.b034d397-20d0-406f-9eb6-d51ba58f5950@github.com>
 <PTEcgCoMTQRuvK2OJhzhAuMjCWDzYw9-dozemvUYqTQ=.8bf8b1e6-dde5-4f73-8cab-d8ddcba0b101@github.com>
Message-ID: <r6HlyQYnL6WhTChpepRH74Vnq-semPSJEirB5WjH88c=.bfbf816d-53bb-4f40-b30e-9481ed16a250@github.com>

On Fri, 18 Feb 2022 17:05:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array.
> > 
> > 
> > Those instructions are already in the comments for the constant `SIGNED_VALID_ENTRY_NAME`
> 
> That's the keytool command to sign the JAR. What I meant is the complete steps to create the JAR file, sign it, and then create the byte array.


The `createByteArray` method which is at the bottom of the test class documents how the byte array  can be made from a jar.

The signed jar is created using the steps defined in `SIGNED_VALID_ENTRY_NAME` from the jar   derived from `VALID_ENTRY_NAME`

If you feel there is still something lacking for documentation, I can certainly make another pass  clarify/add it, but I tried to cover the steps (but I also understand what might be obvious to me might not be as obvious as I thought).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From alanb at openjdk.java.net  Fri Feb 18 17:23:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 18 Feb 2022 17:23:49 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <r6HlyQYnL6WhTChpepRH74Vnq-semPSJEirB5WjH88c=.bfbf816d-53bb-4f40-b30e-9481ed16a250@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
 <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>
 <riKR0vsWbUnHTGPDGrI3oJNiEeYWZynZfEMJXYI619U=.b034d397-20d0-406f-9eb6-d51ba58f5950@github.com>
 <PTEcgCoMTQRuvK2OJhzhAuMjCWDzYw9-dozemvUYqTQ=.8bf8b1e6-dde5-4f73-8cab-d8ddcba0b101@github.com>
 <r6HlyQYnL6WhTChpepRH74Vnq-semPSJEirB5WjH88c=.bfbf816d-53bb-4f40-b30e-9481ed16a250@github.com>
Message-ID: <kjQ7UUfLWgpO4P34cQ7zKvEvKmiGuX83jO4XXrbou7k=.52a15078-d058-43d4-aa09-17f1f01fbfb4@github.com>

On Fri, 18 Feb 2022 17:15:17 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> If you feel there is still something lacking for documentation, I can certainly make another pass clarify/add it, but I tried to cover the steps (but I also understand what might be obvious to me might not be as obvious as I thought).

Yes, I think clear instructions are important to have for tests like this. It doesn't need much but what you know is scattered across a method and a comment on a byte array, just not clear/easy.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From rhalade at openjdk.java.net  Fri Feb 18 18:30:10 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 18 Feb 2022 18:30:10 GMT
Subject: RFR: 8277488: Add expiry exception for Digicert (geotrustglobalca)
 expiring in May 2022
Message-ID: <e_BmO3ge0iC_Z4nxYwXmNAa3zCavKqCcpoEqohx59LA=.57766123-383c-4058-8523-81f634be55ed@github.com>

We are checking with CA if root cert can be removed. Meanwhile, updated test to add expiry exception.

-------------

Commit messages:
 - 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022

Changes: https://git.openjdk.java.net/jdk/pull/7537/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7537&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277488
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7537.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7537/head:pull/7537

PR: https://git.openjdk.java.net/jdk/pull/7537

From mstjohns at comcast.net  Fri Feb 18 19:19:58 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Fri, 18 Feb 2022 14:19:58 -0500
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v5]
In-Reply-To: <CpDdi0wPl6q9gMRz1WmMR4NpDhjK1arRn9MxM_VvsZ0=.0b42c294-1ade-48dc-937a-69d794524614@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <RYiXHY5ZgrnwE-Pe3aP4ShvhPElKOl-XST8DcuJTSUc=.f279dc63-3eb6-4b11-8539-45a4946e5fdb@github.com>
 <cHGqH3bNH0S3dJlVbaW8mT77PqX31X0WcKwpcuxwYF4=.016523b8-4568-4711-a8e2-98051e83e892@github.com>
 <9QASaRxK59FdgEwqlC5jTqnZZvQbNTN7G6yA_62wGMU=.2663151e-966f-4b9b-98cc-a9b02cc916f9@github.com>
 <dCbeSGyh3TbwpUJnI9MMehsYyH_Kc3v9HJ_TRceWQBI=.2e4a3f78-7d5c-47d5-ba7e-5e3fd17c51f6@github.com>
 <V0MscxqmMpu2BEmwzured1JA6zS0aT2-t1vNmjTuG6U=.ea874ac4-0e10-4bf5-853d-072270b3d0dd@github.com>
 <YSSE-oLT9s_CEuDvTxvNbeReMdlc2tBZSzA2ptgFxjI=.04c92822-e1da-41e3-9a81-7d4e0361c6a9@github.com>
 <Ru5VRj7tj8Kht6PQvPc_VTUQN5kIrw2bNNFVDuNuZI8=.2ad0bf63-7b27-4d66-ba90-827ece1b73a1@github.com>
 <Ln5haQUjEdghujvspZVICAi4J6p9BoFy1B2
 mZeyXP2A=.5cfaa7a2-b304-4bab-b5ff-1145fe5e3f0a@github.com>
 <CpDdi0wPl6q9gMRz1WmMR4NpDhjK1arRn9MxM_VvsZ0=.0b42c294-1ade-48dc-937a-69d794524614@github.com>
Message-ID: <093a6f16-3701-4f03-e0eb-461e31a193a5@comcast.net>


OtherName.java @93,97

PR:https://git.openjdk.java.net/jdk/pull/7167

> ??????? if (derValue1.isContextSpecific((byte) 0) && 
> derValue1.isConstructed()) {
> ??????????? nameValue = derValue1.data.toByteArray();
> ??????? } else {
> ??????????? throw new IOException("value is not [0]");
> ??????? }
That exception string isn't correct (the value is usually not just the 
tag), nor very descriptive.? How about instead:

throw new IOException ("value is not EXPLICTly tagged [0]");

Also, the derValue1.data should be parseable into a DerValue itself. 
Should that be checked here as well and an error thrown if invalid?? 
I.e.,? add this after nameValue = ...

    try {
     ?? new DerValue (nameValue);
    } catch (IOException ex) {
     ?? throw new IOException ("Body of OtherName is not a valid BER or
    DER value", ex);
    }


Thanks - Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220218/095af108/attachment.htm>

From lancea at openjdk.java.net  Fri Feb 18 19:26:45 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 18 Feb 2022 19:26:45 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v5]
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <yIdfQRXEuM_IQrqqO5wBlWmtw_K-oW7dK1jrwWcsNn8=.f41de10e-deab-494c-ade6-b4195b1d9672@github.com>

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add additional comments describing how the jars are created

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7348/files
  - new: https://git.openjdk.java.net/jdk/pull/7348/files/d5cf8db8..490c986d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=03-04

  Stats: 29 lines in 1 file changed: 28 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Fri Feb 18 19:26:46 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 18 Feb 2022 19:26:46 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <kjQ7UUfLWgpO4P34cQ7zKvEvKmiGuX83jO4XXrbou7k=.52a15078-d058-43d4-aa09-17f1f01fbfb4@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
 <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>
 <riKR0vsWbUnHTGPDGrI3oJNiEeYWZynZfEMJXYI619U=.b034d397-20d0-406f-9eb6-d51ba58f5950@github.com>
 <PTEcgCoMTQRuvK2OJhzhAuMjCWDzYw9-dozemvUYqTQ=.8bf8b1e6-dde5-4f73-8cab-d8ddcba0b101@github.com>
 <r6HlyQYnL6WhTChpepRH74Vnq-semPSJEirB5WjH88c=.bfbf816d-53bb-4f40-b30e-9481ed16a250@github.com>
 <kjQ7UUfLWgpO4P34cQ7zKvEvKmiGuX83jO4XXrbou7k=.52a15078-d058-43d4-aa09-17f1f01fbfb4@github.com>
Message-ID: <Oc5Bf65ZwiKzAWKv5FNxJNnqAf4Pg98hDKCJrOFHjYc=.1d269d96-23ab-48b9-81ca-59b44d1677b9@github.com>

On Fri, 18 Feb 2022 17:20:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > If you feel there is still something lacking for documentation, I can certainly make another pass clarify/add it, but I tried to cover the steps (but I also understand what might be obvious to me might not be as obvious as I thought).
> 
> Yes, I think clear instructions are important to have for tests like this. It doesn't need much but what you know is scattered across a method and a comment on a byte array, just not clear/easy.

Ok, thank you for the feedback.  I just pushed a change with additional comments on the jar creation which hopefully will address your input above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Fri Feb 18 19:42:30 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 18 Feb 2022 19:42:30 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v6]
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <13Lmzuuv8WyY51hz-z3_N8Pk_8-r25lULVsVCnBfrWM=.c0124f95-234c-45d7-8855-917691e6bd86@github.com>

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  remove trailing space

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7348/files
  - new: https://git.openjdk.java.net/jdk/pull/7348/files/490c986d..818c2857

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Fri Feb 18 19:54:23 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 18 Feb 2022 19:54:23 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v7]
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <BZx3-Zm13uwnugr_aOJtmMJHqxKhbVx8v1YwMamiX60=.ee95f02f-b1d0-4cc2-8c31-5e2df476c640@github.com>

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  remove extra '}'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7348/files
  - new: https://git.openjdk.java.net/jdk/pull/7348/files/818c2857..839d99f7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348

PR: https://git.openjdk.java.net/jdk/pull/7348

From weijun at openjdk.java.net  Fri Feb 18 20:05:47 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 18 Feb 2022 20:05:47 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v8]
In-Reply-To: <EaMO7CacEdc-tDs-7Iwp8WTpIkgGM3kAp6yvZGuxIMU=.6912b1ff-f783-43e0-be73-b78eb04ca5f2@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <EaMO7CacEdc-tDs-7Iwp8WTpIkgGM3kAp6yvZGuxIMU=.6912b1ff-f783-43e0-be73-b78eb04ca5f2@github.com>
Message-ID: <3LQO1QnuLcn8PxL2SDPSuBOTJt7iZ693mQg1XJBXrjU=.a5a82b8e-a43d-4682-b878-7391e12f76d7@github.com>

On Thu, 17 Feb 2022 16:00:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s/can/may/

> _Mailing list message from Michael StJohns...

I'll use your exception message on not a `[0]`.

For dealing with the error while the parsing of `nameValue`, we've discussed it and my last comment is at https://github.com/openjdk/jdk/pull/7167#discussion_r810155556. I'd rather not fail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Fri Feb 18 20:05:46 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 18 Feb 2022 20:05:46 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v9]
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <9w5mTLPhqn9AcaYrbycNHfQfBi7r8BL0KJsGpK9kUpA=.b4dfcbf5-64c9-4d0d-838b-64dd9ef4947e@github.com>

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  make exception message clearer

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7167/files
  - new: https://git.openjdk.java.net/jdk/pull/7167/files/5043812c..96b6b7ea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7167&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Fri Feb 18 20:17:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 18 Feb 2022 20:17:52 GMT
Subject: RFR: 8277488: Add expiry exception for Digicert (geotrustglobalca)
 expiring in May 2022
In-Reply-To: <e_BmO3ge0iC_Z4nxYwXmNAa3zCavKqCcpoEqohx59LA=.57766123-383c-4058-8523-81f634be55ed@github.com>
References: <e_BmO3ge0iC_Z4nxYwXmNAa3zCavKqCcpoEqohx59LA=.57766123-383c-4058-8523-81f634be55ed@github.com>
Message-ID: <Dy5JlbMSSL8claAuATlq5nOP6IfW_y531Y4U9oZwwFQ=.ff39b788-ff0a-413a-b97d-73d3e3f4c812@github.com>

On Fri, 18 Feb 2022 18:24:46 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> We are checking with CA if root cert can be removed. Meanwhile, updated test to add expiry exception.

Looks fine to me.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7537

From rhalade at openjdk.java.net  Fri Feb 18 20:20:56 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 18 Feb 2022 20:20:56 GMT
Subject: Integrated: 8277488: Add expiry exception for Digicert
 (geotrustglobalca) expiring in May 2022
In-Reply-To: <e_BmO3ge0iC_Z4nxYwXmNAa3zCavKqCcpoEqohx59LA=.57766123-383c-4058-8523-81f634be55ed@github.com>
References: <e_BmO3ge0iC_Z4nxYwXmNAa3zCavKqCcpoEqohx59LA=.57766123-383c-4058-8523-81f634be55ed@github.com>
Message-ID: <MTttlMSx2qIdKRdI2DQoeGMVMkrGnu5sUnANpJ-FVFM=.eeb12648-e7de-45d2-a78e-4d8f4c8a66cc@github.com>

On Fri, 18 Feb 2022 18:24:46 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> We are checking with CA if root cert can be removed. Meanwhile, updated test to add expiry exception.

This pull request has now been integrated.

Changeset: d3749de4
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d3749de47832c6de4bcee9cf64a0b698e796b2f2
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/7537

From valeriep at openjdk.java.net  Fri Feb 18 22:00:13 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 18 Feb 2022 22:00:13 GMT
Subject: RFR: 8282077: PKCS11 provider C_sign() impl should handle
 CKR_BUFFER_TOO_SMALL error
Message-ID: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>

Could someone please help review this trivial change? This is to add an error handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). Since none of the supported signature algorithms trigger this error as the default buffer size is large enough, this is more for consistency sake. No new regression test for this and thus the @noreg-hard label.

Thanks,
Valerie

-------------

Commit messages:
 - 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error

Changes: https://git.openjdk.java.net/jdk/pull/7540/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7540&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282077
  Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7540.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7540/head:pull/7540

PR: https://git.openjdk.java.net/jdk/pull/7540

From mikael at openjdk.java.net  Fri Feb 18 22:13:49 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 18 Feb 2022 22:13:49 GMT
Subject: RFR: 8282077: PKCS11 provider C_sign() impl should handle
 CKR_BUFFER_TOO_SMALL error
In-Reply-To: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
References: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
Message-ID: <RfNFoOdcy_ASlFkg9a9UPFN_ep5aRTzNHKyi5kVqZHI=.2a2f89fd-7369-43b6-82e8-b28b8ffc6b1c@github.com>

On Fri, 18 Feb 2022 21:52:59 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this trivial change? This is to add an error handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). Since none of the supported signature algorithms trigger this error as the default buffer size is large enough, this is more for consistency sake. No new regression test for this and thus the @noreg-hard label.
> 
> Thanks,
> Valerie

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c line 151:

> 149:         if (bufP == NULL) {
> 150:             throwOutOfMemoryError(env, 0);
> 151:             return NULL;

Does ckpData need to be freed here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7540

From valeriep at openjdk.java.net  Fri Feb 18 23:35:51 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 18 Feb 2022 23:35:51 GMT
Subject: RFR: 8282077: PKCS11 provider C_sign() impl should handle
 CKR_BUFFER_TOO_SMALL error
In-Reply-To: <RfNFoOdcy_ASlFkg9a9UPFN_ep5aRTzNHKyi5kVqZHI=.2a2f89fd-7369-43b6-82e8-b28b8ffc6b1c@github.com>
References: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
 <RfNFoOdcy_ASlFkg9a9UPFN_ep5aRTzNHKyi5kVqZHI=.2a2f89fd-7369-43b6-82e8-b28b8ffc6b1c@github.com>
Message-ID: <s7o8ENRwOm8yWJH4DqHI0XTcY0qadP-NQ2wFBXa4nkg=.abfd3d22-017b-42e7-ba28-27648415fea7@github.com>

On Fri, 18 Feb 2022 22:10:17 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Could someone please help review this trivial change? This is to add an error handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). Since none of the supported signature algorithms trigger this error as the default buffer size is large enough, this is more for consistency sake. No new regression test for this and thus the @noreg-hard label.
>> 
>> Thanks,
>> Valerie
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c line 151:
> 
>> 149:         if (bufP == NULL) {
>> 150:             throwOutOfMemoryError(env, 0);
>> 151:             return NULL;
> 
> Does ckpData need to be freed here?

Yes, good catch. I will change it with a cleanup label and jump to the cleanup label as in other methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7540

From valeriep at openjdk.java.net  Sat Feb 19 00:07:34 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 19 Feb 2022 00:07:34 GMT
Subject: RFR: 8282077: PKCS11 provider C_sign() impl should handle
 CKR_BUFFER_TOO_SMALL error [v2]
In-Reply-To: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
References: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
Message-ID: <9MezUxk4IZ4feuNeTpvThJGtFAwyO3TjFlU3xEzVVW0=.aa1c837b-c020-4468-a497-e9ef253c1d07@github.com>

> Could someone please help review this trivial change? This is to add an error handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). Since none of the supported signature algorithms trigger this error as the default buffer size is large enough, this is more for consistency sake. No new regression test for this and thus the @noreg-hard label.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  free allocated 'ckpData' upon OOM.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7540/files
  - new: https://git.openjdk.java.net/jdk/pull/7540/files/19d1451a..67d70e9d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7540&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7540&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7540.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7540/head:pull/7540

PR: https://git.openjdk.java.net/jdk/pull/7540

From mikael at openjdk.java.net  Sat Feb 19 00:11:45 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Sat, 19 Feb 2022 00:11:45 GMT
Subject: RFR: 8282077: PKCS11 provider C_sign() impl should handle
 CKR_BUFFER_TOO_SMALL error [v2]
In-Reply-To: <9MezUxk4IZ4feuNeTpvThJGtFAwyO3TjFlU3xEzVVW0=.aa1c837b-c020-4468-a497-e9ef253c1d07@github.com>
References: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
 <9MezUxk4IZ4feuNeTpvThJGtFAwyO3TjFlU3xEzVVW0=.aa1c837b-c020-4468-a497-e9ef253c1d07@github.com>
Message-ID: <6MufeJjfIoDHMPb6ny3Rgz8znEqVoxmD2dER4qqBlss=.001fdfe9-efd7-43ac-9714-4f7170f19564@github.com>

On Sat, 19 Feb 2022 00:07:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Could someone please help review this trivial change? This is to add an error handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). Since none of the supported signature algorithms trigger this error as the default buffer size is large enough, this is more for consistency sake. No new regression test for this and thus the @noreg-hard label.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   free allocated 'ckpData' upon OOM.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7540

From valeriep at openjdk.java.net  Sat Feb 19 00:31:47 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 19 Feb 2022 00:31:47 GMT
Subject: RFR: 8282077: PKCS11 provider C_sign() impl should handle
 CKR_BUFFER_TOO_SMALL error [v2]
In-Reply-To: <9MezUxk4IZ4feuNeTpvThJGtFAwyO3TjFlU3xEzVVW0=.aa1c837b-c020-4468-a497-e9ef253c1d07@github.com>
References: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
 <9MezUxk4IZ4feuNeTpvThJGtFAwyO3TjFlU3xEzVVW0=.aa1c837b-c020-4468-a497-e9ef253c1d07@github.com>
Message-ID: <5idndC9LhXhJ83ChTWD1rEJSOlj7rkGmLVW9pXD1n3o=.9d31e96e-2594-422c-8cb1-3ef61219f5bf@github.com>

On Sat, 19 Feb 2022 00:07:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Could someone please help review this trivial change? This is to add an error handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). Since none of the supported signature algorithms trigger this error as the default buffer size is large enough, this is more for consistency sake. No new regression test for this and thus the @noreg-hard label.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   free allocated 'ckpData' upon OOM.

Thanks for the review! Will proceed with integration once the checks completed...

-------------

PR: https://git.openjdk.java.net/jdk/pull/7540

From mstjohns at comcast.net  Sat Feb 19 01:48:14 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Fri, 18 Feb 2022 20:48:14 -0500
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v8]
In-Reply-To: <3LQO1QnuLcn8PxL2SDPSuBOTJt7iZ693mQg1XJBXrjU=.a5a82b8e-a43d-4682-b878-7391e12f76d7@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <EaMO7CacEdc-tDs-7Iwp8WTpIkgGM3kAp6yvZGuxIMU=.6912b1ff-f783-43e0-be73-b78eb04ca5f2@github.com>
 <3LQO1QnuLcn8PxL2SDPSuBOTJt7iZ693mQg1XJBXrjU=.a5a82b8e-a43d-4682-b878-7391e12f76d7@github.com>
Message-ID: <d839380b-9f9b-100d-6f64-313dd29eb20f@comcast.net>

On 2/18/2022 3:05 PM, Weijun Wang wrote:
> On Thu, 17 Feb 2022 16:00:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:
>
>>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>>>
>>> It also fix several errors:
>>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    s/can/may/
>> _Mailing list message from Michael StJohns...
> I'll use your exception message on not a `[0]`.
>
> For dealing with the error while the parsing of `nameValue`, we've discussed it and my last comment is at https://github.com/openjdk/jdk/pull/7167#discussion_r810155556. I'd rather not fail.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/7167

Hi Weijun -

You're already adding an error condition for a badly encoded OtherName 
that wasn't there before.? Extending that error condition check to cover 
the wrapped ASN1 object doesn't seem to me to be much of a stretch.?? 
Looking at the OtherName specifications, there shouldn't be any 
ambiguity here - ANY is required to be a valid ASN1 encoded object.

Hmm... wouldn't these (both) errors be masked by the location in 
X509CertImpl you were discussing?? E.g. you're still going to have the 
raw bytes, but the IOException(s) will just be captured (and maybe 
logged per Sean's suggestion) and ignored.

Later, Mike






From weijun at openjdk.java.net  Sat Feb 19 04:11:56 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 19 Feb 2022 04:11:56 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v9]
In-Reply-To: <9w5mTLPhqn9AcaYrbycNHfQfBi7r8BL0KJsGpK9kUpA=.b4dfcbf5-64c9-4d0d-838b-64dd9ef4947e@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <9w5mTLPhqn9AcaYrbycNHfQfBi7r8BL0KJsGpK9kUpA=.b4dfcbf5-64c9-4d0d-838b-64dd9ef4947e@github.com>
Message-ID: <mSxTc2E0fVM_Ht7oGpPnO8dtqqlyh5mpBkDMt6IVV4k=.6d24f514-dc7e-4767-89d9-2f968f58345e@github.com>

On Fri, 18 Feb 2022 20:05:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make exception message clearer

That's my intent, as the (updated) spec says, only a "valid supported char string" is converted, otherwise the raw bytes. The original `makeAltNames` method could fail for several reasons, but I don't want the updated one to fail for more.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From valeriep at openjdk.java.net  Sat Feb 19 06:43:47 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 19 Feb 2022 06:43:47 GMT
Subject: Integrated: 8282077: PKCS11 provider C_sign() impl should handle
 CKR_BUFFER_TOO_SMALL error
In-Reply-To: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
References: <U6_hH8l0N2i--d-Q4EQP1IIIhXp3067WpH_6vkS0vow=.7a2a518c-76c3-40b6-af6a-e35679a3bff5@github.com>
Message-ID: <u9AL7jGHa0oyrXSnxB4PKI7mQTKIUZZivep8p5mtrng=.9bb74610-41a2-4c31-8f10-2d1477b2a5cd@github.com>

On Fri, 18 Feb 2022 21:52:59 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone please help review this trivial change? This is to add an error handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). Since none of the supported signature algorithms trigger this error as the default buffer size is large enough, this is more for consistency sake. No new regression test for this and thus the @noreg-hard label.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: d7f31d0d
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d7f31d0d53bfec627edc83ceb75fc6202891e186
Stats:     12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error

Reviewed-by: mikael

-------------

PR: https://git.openjdk.java.net/jdk/pull/7540

From alanb at openjdk.java.net  Sat Feb 19 11:02:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 19 Feb 2022 11:02:47 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <Oc5Bf65ZwiKzAWKv5FNxJNnqAf4Pg98hDKCJrOFHjYc=.1d269d96-23ab-48b9-81ca-59b44d1677b9@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
 <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>
 <riKR0vsWbUnHTGPDGrI3oJNiEeYWZynZfEMJXYI619U=.b034d397-20d0-406f-9eb6-d51ba58f5950@github.com>
 <PTEcgCoMTQRuvK2OJhzhAuMjCWDzYw9-dozemvUYqTQ=.8bf8b1e6-dde5-4f73-8cab-d8ddcba0b101@github.com>
 <r6HlyQYnL6WhTChpepRH74Vnq-semPSJEirB5WjH88c=.bfbf816d-53bb-4f40-b30e-9481ed16a250@github.com>
 <kjQ7UUfLWgpO4P34cQ7zKvEvKmiGuX83jO4XXrbou7k=.52a15078-d058-43d4-aa09-17f1f01fbfb4@github.com>
 <Oc5Bf65ZwiKzAWKv5FNxJNnqAf4Pg98hDKCJrOFHjYc=.1d269d96-23ab-48b9-81ca-59b44d1677b9@github.com>
Message-ID: <bSdYUkGs2FAqQZU2sKz5e4kEiLJZH6CXkvQ_k16kCCo=.e4cc50c4-9811-4974-afc1-af430a1a1a25@github.com>

On Fri, 18 Feb 2022 19:22:27 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Ok, thank you for the feedback. I just pushed a change with additional comments on the jar creation which hopefully will address your input above.

It's a bit better but I think it needs a clear step-by-step instructions in a comment before declaration of VALID_ENTRY_NAME to show how the JAR file is created, signed (move the instructions that have been placed on the TestNG setup method), and then converted to the byte array. Further maintainers will thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From jjiang at openjdk.java.net  Mon Feb 21 05:12:11 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Mon, 21 Feb 2022 05:12:11 GMT
Subject: RFR: 8282158: ECParameters InvalidParameterSpecException messages
 missed ECKeySizeParameterSpec
Message-ID: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>

sun.security.util.ECParameters class supports three AlgorithmParameterSpec types, exactly ECParameterSpec, ECGenParameterSpec and ECKeySizeParameterSpec, however the InvalidParameterSpecException messages missed ECKeySizeParameterSpec.

-------------

Commit messages:
 - 8282158: ECParameters InvalidParameterSpecException messages missed ECKeySizeParameterSpec

Changes: https://git.openjdk.java.net/jdk/pull/7550/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7550&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282158
  Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7550.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7550/head:pull/7550

PR: https://git.openjdk.java.net/jdk/pull/7550

From xuelei at openjdk.java.net  Mon Feb 21 07:06:50 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 21 Feb 2022 07:06:50 GMT
Subject: RFR: 8282158: ECParameters InvalidParameterSpecException messages
 missed ECKeySizeParameterSpec
In-Reply-To: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>
References: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>
Message-ID: <u3SCgkzkSvAAIA8MfGqsQNSOs7URyHoXWzOGJneMcoA=.23ba4bd9-c2b4-4639-80e2-fb20feb2e3ba@github.com>

On Mon, 21 Feb 2022 04:49:42 GMT, John Jiang <jjiang at openjdk.org> wrote:

> sun.security.util.ECParameters class supports three AlgorithmParameterSpec types, exactly ECParameterSpec, ECGenParameterSpec and ECKeySizeParameterSpec, however the InvalidParameterSpecException messages missed ECKeySizeParameterSpec.

Marked as reviewed by xuelei (Reviewer).

src/java.base/share/classes/sun/security/util/ECParameters.java line 127:

> 125:             throw new InvalidParameterSpecException
> 126:                 ("Only ECParameterSpec, ECGenParameterSpec " +
> 127:                         "and ECKeySizeParameterSpec supported");

Would you mind reducing the leading whitespaces of the 2nd line so that the two lines are aligned?  It would be nice to move the '9' to the previous line, as you are already there.

src/java.base/share/classes/sun/security/util/ECParameters.java line 218:

> 216:         throw new InvalidParameterSpecException(
> 217:             "Only ECParameterSpec, ECGenParameterSpec " +
> 218:                     "and ECKeySizeParameterSpec supported");

Would you mind reducing the leading whitespaces so that the two lines are aligned?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7550

From jjiang at openjdk.java.net  Mon Feb 21 07:50:22 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Mon, 21 Feb 2022 07:50:22 GMT
Subject: RFR: 8282158: ECParameters InvalidParameterSpecException messages
 missed ECKeySizeParameterSpec [v2]
In-Reply-To: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>
References: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>
Message-ID: <ujZMZGpvWvsWtpMUqMeVQb8fZ5UvS7xWBGa027pW5cI=.35983752-9f39-49e1-9789-248e34939bdf@github.com>

> sun.security.util.ECParameters class supports three AlgorithmParameterSpec types, exactly ECParameterSpec, ECGenParameterSpec and ECKeySizeParameterSpec, however the InvalidParameterSpecException messages missed ECKeySizeParameterSpec.

John Jiang has updated the pull request incrementally with one additional commit since the last revision:

  update format

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7550/files
  - new: https://git.openjdk.java.net/jdk/pull/7550/files/f661203a..ee8f0831

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7550&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7550&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7550.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7550/head:pull/7550

PR: https://git.openjdk.java.net/jdk/pull/7550

From jjiang at openjdk.java.net  Mon Feb 21 07:58:51 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Mon, 21 Feb 2022 07:58:51 GMT
Subject: Integrated: 8282158: ECParameters InvalidParameterSpecException
 messages missed ECKeySizeParameterSpec
In-Reply-To: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>
References: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>
Message-ID: <8X0AFo_TF6ab0uKdknoKdNIlkoPJ_UWm9wCh1lzcw58=.a6f4166c-feca-42f3-8ee4-3db63debaf3e@github.com>

On Mon, 21 Feb 2022 04:49:42 GMT, John Jiang <jjiang at openjdk.org> wrote:

> sun.security.util.ECParameters class supports three AlgorithmParameterSpec types, exactly ECParameterSpec, ECGenParameterSpec and ECKeySizeParameterSpec, however the InvalidParameterSpecException messages missed ECKeySizeParameterSpec.

This pull request has now been integrated.

Changeset: 52a85d80
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52a85d80483f7fefbe26bed6fe3a2ce4bd1bc9fc
Stats:     8 lines in 1 file changed: 2 ins; 1 del; 5 mod

8282158: ECParameters InvalidParameterSpecException messages missed ECKeySizeParameterSpec

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/7550

From jpai at openjdk.java.net  Mon Feb 21 08:09:53 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 21 Feb 2022 08:09:53 GMT
Subject: RFR: 8282158: ECParameters InvalidParameterSpecException messages
 missed ECKeySizeParameterSpec [v2]
In-Reply-To: <ujZMZGpvWvsWtpMUqMeVQb8fZ5UvS7xWBGa027pW5cI=.35983752-9f39-49e1-9789-248e34939bdf@github.com>
References: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>
 <ujZMZGpvWvsWtpMUqMeVQb8fZ5UvS7xWBGa027pW5cI=.35983752-9f39-49e1-9789-248e34939bdf@github.com>
Message-ID: <tvAbIPkLG8wA0Xh_4rx_aYmMgSFpxOdaIfDTLV74mwo=.fb1619ad-84ea-4815-baa1-1418ac8c1107@github.com>

On Mon, 21 Feb 2022 07:50:22 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> sun.security.util.ECParameters class supports three AlgorithmParameterSpec types, exactly ECParameterSpec, ECGenParameterSpec and ECKeySizeParameterSpec, however the InvalidParameterSpecException messages missed ECKeySizeParameterSpec.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update format

src/java.base/share/classes/sun/security/util/ECParameters.java line 26:

> 24:  */
> 25: 
> 26: package java.security;

Hello @johnshajiang, was this change to the package name intentional? Looking at the description in the JBS issue, this looks like an accidental change, isn't it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7550

From jjiang at openjdk.java.net  Mon Feb 21 08:18:55 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Mon, 21 Feb 2022 08:18:55 GMT
Subject: RFR: 8282158: ECParameters InvalidParameterSpecException messages
 missed ECKeySizeParameterSpec [v2]
In-Reply-To: <tvAbIPkLG8wA0Xh_4rx_aYmMgSFpxOdaIfDTLV74mwo=.fb1619ad-84ea-4815-baa1-1418ac8c1107@github.com>
References: <k0hxOh5uNajxA5_72YeQ68urNhaeLrOulcVqVfHbtyg=.0e3e6b0e-a3a0-4333-9bb6-f5b67835ac59@github.com>
 <ujZMZGpvWvsWtpMUqMeVQb8fZ5UvS7xWBGa027pW5cI=.35983752-9f39-49e1-9789-248e34939bdf@github.com>
 <tvAbIPkLG8wA0Xh_4rx_aYmMgSFpxOdaIfDTLV74mwo=.fb1619ad-84ea-4815-baa1-1418ac8c1107@github.com>
Message-ID: <oWFR2raxDxrCZBF6SkjX_Z6rZW_OyTzt_kkiqkgF-ZE=.48e2b0c9-ee06-4cd6-bac9-4178ff1895c3@github.com>

On Mon, 21 Feb 2022 08:06:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update format
>
> src/java.base/share/classes/sun/security/util/ECParameters.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package java.security;
> 
> Hello @johnshajiang, was this change to the package name intentional? Looking at the description in the JBS issue, this looks like an accidental change, isn't it?

My fault!
Already submitted another JBS for this issue
https://bugs.openjdk.java.net/browse/JDK-8282166

-------------

PR: https://git.openjdk.java.net/jdk/pull/7550

From jjiang at openjdk.java.net  Mon Feb 21 08:30:12 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Mon, 21 Feb 2022 08:30:12 GMT
Subject: Integrated: 8282166: JDK-8282158 changed ECParameters' package by
 accident
Message-ID: <IYWZn0-LPlLr2jDhVEvz8Vxz8557sOe2ZWfGwZur8B8=.acae1e48-0551-48c1-a698-f006308fda9b@github.com>

JDK-8282158 changed ECParameters' package from sun.security.util to java.security by accident.

So sorry for this trouble!

-------------

Commit messages:
 - 8282166: JDK-8282158 changed ECParameters' package by accident

Changes: https://git.openjdk.java.net/jdk/pull/7552/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7552&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282166
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7552.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7552/head:pull/7552

PR: https://git.openjdk.java.net/jdk/pull/7552

From xuelei at openjdk.java.net  Mon Feb 21 08:30:12 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 21 Feb 2022 08:30:12 GMT
Subject: Integrated: 8282166: JDK-8282158 changed ECParameters' package by
 accident
In-Reply-To: <IYWZn0-LPlLr2jDhVEvz8Vxz8557sOe2ZWfGwZur8B8=.acae1e48-0551-48c1-a698-f006308fda9b@github.com>
References: <IYWZn0-LPlLr2jDhVEvz8Vxz8557sOe2ZWfGwZur8B8=.acae1e48-0551-48c1-a698-f006308fda9b@github.com>
Message-ID: <0aXiRooXScLx0g2qcxsBDio5iO2mA1xaFFccvy7Wdz0=.29596cfa-630c-4dab-849f-794cde85ff29@github.com>

On Mon, 21 Feb 2022 08:13:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> JDK-8282158 changed ECParameters' package from sun.security.util to java.security by accident.
> 
> So sorry for this trouble!

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7552

From jpai at openjdk.java.net  Mon Feb 21 08:30:13 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 21 Feb 2022 08:30:13 GMT
Subject: Integrated: 8282166: JDK-8282158 changed ECParameters' package by
 accident
In-Reply-To: <IYWZn0-LPlLr2jDhVEvz8Vxz8557sOe2ZWfGwZur8B8=.acae1e48-0551-48c1-a698-f006308fda9b@github.com>
References: <IYWZn0-LPlLr2jDhVEvz8Vxz8557sOe2ZWfGwZur8B8=.acae1e48-0551-48c1-a698-f006308fda9b@github.com>
Message-ID: <IE9u8eE-1XFhNjnIaOBEELV12wGlntIDUxhZd2BfYsk=.c46ecfe4-07a3-43b7-9db5-de01b8b48016@github.com>

On Mon, 21 Feb 2022 08:13:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> JDK-8282158 changed ECParameters' package from sun.security.util to java.security by accident.
> 
> So sorry for this trouble!

I'm not a Reviewer, but this change looks fine in context of the accidental change introduced in https://github.com/openjdk/jdk/pull/7550.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7552

From jjiang at openjdk.java.net  Mon Feb 21 08:30:15 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Mon, 21 Feb 2022 08:30:15 GMT
Subject: Integrated: 8282166: JDK-8282158 changed ECParameters' package by
 accident
In-Reply-To: <IYWZn0-LPlLr2jDhVEvz8Vxz8557sOe2ZWfGwZur8B8=.acae1e48-0551-48c1-a698-f006308fda9b@github.com>
References: <IYWZn0-LPlLr2jDhVEvz8Vxz8557sOe2ZWfGwZur8B8=.acae1e48-0551-48c1-a698-f006308fda9b@github.com>
Message-ID: <cM2kECEKS8kQOX2zHxGcFgY8m9iUhgLsKb1NEXNu0n0=.d2c4de0a-c0b3-493d-a122-f51a19fd8f60@github.com>

On Mon, 21 Feb 2022 08:13:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> JDK-8282158 changed ECParameters' package from sun.security.util to java.security by accident.
> 
> So sorry for this trouble!

This pull request has now been integrated.

Changeset: 34aae32d
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/34aae32de6c1eeaf268d62f20152f831cca5cd29
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8282166: JDK-8282158 changed ECParameters' package by accident

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/7552

From jjiang at openjdk.java.net  Tue Feb 22 06:09:07 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Tue, 22 Feb 2022 06:09:07 GMT
Subject: RFR: 8282220: contentType should not be a PKCS7's member
Message-ID: <dGyC-OVD04TDA_Ik3FdLvPkJOi1tipB0a-n4pCMmd7E=.50982069-7c3f-4c3f-9df1-36c2892f6645@github.com>

`contentType` should be a local variable because it is only used in method `parse(DerInputStream derin, boolean oldStyle)`.
This change also improves some exception catch blocks.

-------------

Commit messages:
 - 8282220: contentType should not be a PKCS7's member

Changes: https://git.openjdk.java.net/jdk/pull/7568/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7568&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282220
  Stats: 19 lines in 1 file changed: 0 ins; 14 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7568/head:pull/7568

PR: https://git.openjdk.java.net/jdk/pull/7568

From xuelei at openjdk.java.net  Tue Feb 22 06:39:47 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Feb 2022 06:39:47 GMT
Subject: RFR: 8282220: contentType should not be a PKCS7's member
In-Reply-To: <dGyC-OVD04TDA_Ik3FdLvPkJOi1tipB0a-n4pCMmd7E=.50982069-7c3f-4c3f-9df1-36c2892f6645@github.com>
References: <dGyC-OVD04TDA_Ik3FdLvPkJOi1tipB0a-n4pCMmd7E=.50982069-7c3f-4c3f-9df1-36c2892f6645@github.com>
Message-ID: <aY7T6yNi6iZQkwA_cynXJkojnUPAFYqvfYXZCaeE5Eg=.cb98214b-8162-4330-af66-1da439700137@github.com>

On Tue, 22 Feb 2022 06:03:33 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `contentType` should be a local variable because it is only used in method `parse(DerInputStream derin, boolean oldStyle)`.
> This change also improves some exception catch blocks.

Looks like a trivial update, but please make sure to pass security tests before integration.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7568

From djelinski at openjdk.java.net  Tue Feb 22 07:16:13 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 07:16:13 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
Message-ID: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>

Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.

This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).

The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.

I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

-------------

Commit messages:
 - Strict strings

Changes: https://git.openjdk.java.net/jdk/pull/7565/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281525
  Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7565.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7565/head:pull/7565

PR: https://git.openjdk.java.net/jdk/pull/7565

From jjiang at openjdk.java.net  Tue Feb 22 07:30:57 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Tue, 22 Feb 2022 07:30:57 GMT
Subject: RFR: 8282220: contentType should not be a PKCS7's member
In-Reply-To: <aY7T6yNi6iZQkwA_cynXJkojnUPAFYqvfYXZCaeE5Eg=.cb98214b-8162-4330-af66-1da439700137@github.com>
References: <dGyC-OVD04TDA_Ik3FdLvPkJOi1tipB0a-n4pCMmd7E=.50982069-7c3f-4c3f-9df1-36c2892f6645@github.com>
 <aY7T6yNi6iZQkwA_cynXJkojnUPAFYqvfYXZCaeE5Eg=.cb98214b-8162-4330-af66-1da439700137@github.com>
Message-ID: <L3513hV8BaxAqZEGSN7mkF7QrRA2LiDIid_SjDxV4bY=.e697662b-ef4b-451c-a347-a4ab5e2b7d0b@github.com>

On Tue, 22 Feb 2022 06:36:58 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> `contentType` should be a local variable because it is only used in method `parse(DerInputStream derin, boolean oldStyle)`.
>> This change also improves some exception catch blocks.
>
> Looks like a trivial update, but please make sure to pass security tests before integration.

@XueleiFan Thanks for your review.
I run the tests in javax/net/ssl, sun/security/pkcs and sun/security/ssl, and I am waiting for the pre-submit testing results.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7568

From jjiang at openjdk.java.net  Tue Feb 22 09:39:54 2022
From: jjiang at openjdk.java.net (John Jiang)
Date: Tue, 22 Feb 2022 09:39:54 GMT
Subject: Integrated: 8282220: contentType should not be a PKCS7's member
In-Reply-To: <dGyC-OVD04TDA_Ik3FdLvPkJOi1tipB0a-n4pCMmd7E=.50982069-7c3f-4c3f-9df1-36c2892f6645@github.com>
References: <dGyC-OVD04TDA_Ik3FdLvPkJOi1tipB0a-n4pCMmd7E=.50982069-7c3f-4c3f-9df1-36c2892f6645@github.com>
Message-ID: <fw4XjpMSEzu_QXEorYFwh_IPZHeqz_yMtLPVC7mAm7U=.c3a0b5fa-bed9-4fad-b397-613cc3d3374c@github.com>

On Tue, 22 Feb 2022 06:03:33 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `contentType` should be a local variable because it is only used in method `parse(DerInputStream derin, boolean oldStyle)`.
> This change also improves some exception catch blocks.

This pull request has now been integrated.

Changeset: b95310b0
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b95310b0908037c6743b937ae43d7bc97e1fb770
Stats:     19 lines in 1 file changed: 0 ins; 14 del; 5 mod

8282220: contentType should not be a PKCS7's member

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/7568

From ihse at openjdk.java.net  Tue Feb 22 11:36:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 11:36:52 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

make/autoconf/flags-cflags.m4 line 136:

> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
> 135: 
> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"

This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7565

From dholmes at openjdk.java.net  Tue Feb 22 12:26:52 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Feb 2022 12:26:52 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <A8KEg03nvghZ-WFGi41gJfE7cU85FxVY8Kiw7Gfw7YQ=.bd064695-e381-4933-a274-6e9751ea63c9@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

Hi Daniel,

Hotspot changes look fine.

Some of the casts in other code look odd to me, but I'll leave that for the security-libs folk to comment on.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7565

From djelinski at openjdk.java.net  Tue Feb 22 14:16:49 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 14:16:49 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
Message-ID: <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>

On Tue, 22 Feb 2022 11:33:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> make/autoconf/flags-cflags.m4 line 136:
> 
>> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
>> 135: 
>> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"
> 
> This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/7565

From djelinski at openjdk.java.net  Tue Feb 22 16:43:28 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 16:43:28 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Move strictStrings to toolchain_cflags

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7565/files
  - new: https://git.openjdk.java.net/jdk/pull/7565/files/fe18b41d..0cfbb165

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7565.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7565/head:pull/7565

PR: https://git.openjdk.java.net/jdk/pull/7565

From ihse at openjdk.java.net  Tue Feb 22 16:43:30 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 16:43:30 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
 <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
Message-ID: <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>

On Tue, 22 Feb 2022 14:13:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 136:
>> 
>>> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
>>> 135: 
>>> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"
>> 
>> This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.
>
> Done

Did you forget to push the fix?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7565

From djelinski at openjdk.java.net  Tue Feb 22 16:43:31 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 16:43:31 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
 <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
 <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>
Message-ID: <2SOr0Aam68G8M26cjL1kFsz9YEWRr2lNfIsu_9rq-i8=.94d1aba2-a323-4e2d-9916-253dce6c98e7@github.com>

On Tue, 22 Feb 2022 16:35:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Done
>
> Did you forget to push the fix?

Push works better when connected... this time it's pushed for real.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7565

From ihse at openjdk.java.net  Tue Feb 22 17:16:51 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 17:16:51 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <eMkXSbGRNHp_sQ1TsvgmlRGbI2YXvI74nE2HAFEqwrE=.b2d6048e-3557-4933-8302-bcb466ae6079@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

Now the build changes look good. Thanks!

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7565

From hchao at openjdk.java.net  Tue Feb 22 20:27:22 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 22 Feb 2022 20:27:22 GMT
Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are
 disabled
Message-ID: <mkhEn9Jgvl78arz0_BZYU1a50q2boR0e1qNHmge0aXk=.b63d4fb3-732e-4f2f-a665-98ca53c5ef94@github.com>

This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned.

-------------

Commit messages:
 - 8277474: jarsigner does not check if algorithm parameters are disabled
 - Testcase updated
 - 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty

Changes: https://git.openjdk.java.net/jdk/pull/7580/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7580&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277474
  Stats: 256 lines in 5 files changed: 240 ins; 3 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7580.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7580/head:pull/7580

PR: https://git.openjdk.java.net/jdk/pull/7580

From hchao at openjdk.java.net  Tue Feb 22 20:31:50 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 22 Feb 2022 20:31:50 GMT
Subject: Withdrawn: 8277474: jarsigner does not check if algorithm parameters
 are disabled
In-Reply-To: <mkhEn9Jgvl78arz0_BZYU1a50q2boR0e1qNHmge0aXk=.b63d4fb3-732e-4f2f-a665-98ca53c5ef94@github.com>
References: <mkhEn9Jgvl78arz0_BZYU1a50q2boR0e1qNHmge0aXk=.b63d4fb3-732e-4f2f-a665-98ca53c5ef94@github.com>
Message-ID: <GTXqYSCuBAjkrjcLy46kOpeB0jbEYTVVfDknbduj6oE=.f033b89f-6d87-41db-85cc-c2399b7c2dd0@github.com>

On Tue, 22 Feb 2022 20:18:19 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7580

From lancea at openjdk.java.net  Tue Feb 22 22:05:32 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 22 Feb 2022 22:05:32 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v8]
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <ESL1CUYbDeZh5KrD6leJB7NaQSD-1qqDUK7geclbh94=.d5a1657b-cafc-4f8a-a419-7ddbb0e6f9ca@github.com>

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Modified and clarified test comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7348/files
  - new: https://git.openjdk.java.net/jdk/pull/7348/files/839d99f7..e540a3a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=06-07

  Stats: 64 lines in 1 file changed: 34 ins; 18 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348

PR: https://git.openjdk.java.net/jdk/pull/7348

From lancea at openjdk.java.net  Tue Feb 22 22:05:34 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 22 Feb 2022 22:05:34 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v4]
In-Reply-To: <bSdYUkGs2FAqQZU2sKz5e4kEiLJZH6CXkvQ_k16kCCo=.e4cc50c4-9811-4974-afc1-af430a1a1a25@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <j3qxg3x5qG2zFABHN-M3OJD-mO52GK3x9Li1P-GcHPI=.c6e26501-985b-4f1e-ab0a-b99102a17229@github.com>
 <AAfI8Yc12YhHBDLk-YTsGnFChTonIAjMsnhZBQHwIDQ=.f1bb5978-f3d4-4e1a-a518-8f95be8a5883@github.com>
 <riKR0vsWbUnHTGPDGrI3oJNiEeYWZynZfEMJXYI619U=.b034d397-20d0-406f-9eb6-d51ba58f5950@github.com>
 <PTEcgCoMTQRuvK2OJhzhAuMjCWDzYw9-dozemvUYqTQ=.8bf8b1e6-dde5-4f73-8cab-d8ddcba0b101@github.com>
 <r6HlyQYnL6WhTChpepRH74Vnq-semPSJEirB5WjH88c=.bfbf816d-53bb-4f40-b30e-9481ed16a250@github.com>
 <kjQ7UUfLWgpO4P34cQ7zKvEvKmiGuX83jO4XXrbou7k=.52a15078-d058-43d4-aa09-17f1f01fbfb4@github.com>
 <Oc5Bf65ZwiKzAWKv5FNxJNnqAf4Pg98hDKCJrOFHjYc=.1d269d96-23ab-48b9-81ca-59b44d1677b9@github.com>
 <bSdYUkGs2FAqQZU2sKz5e4kEiLJZH6CXkvQ_k16kCCo=.e4cc50c4-9811-4974-afc1-af430a1a1a25@github.com>
Message-ID: <7uC177dheUsm1Ky2Tav8-L4BObpjR-0IKzmA455PIjA=.9096eff8-c318-4eb6-999d-0901f8ebb078@github.com>

On Sat, 19 Feb 2022 10:59:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Ok, thank you for the feedback. I just pushed a change with additional comments on the jar creation which hopefully will address your input above.
> 
> It's a bit better but I think it needs a clear step-by-step instructions in a comment before declaration of VALID_ENTRY_NAME to show how the JAR file is created, signed (move the instructions that have been placed on the TestNG setup method), and then converted to the byte array. Further maintainers will thank you.

Just pushed a revised set of comments.  Hopefully this will get us across the goal line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From hchao at openjdk.java.net  Tue Feb 22 22:11:19 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 22 Feb 2022 22:11:19 GMT
Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are
 disabled
Message-ID: <mIbAGB343qImxcA2I1lU7xrGyoMYc-tjcoGl01huYfM=.25eed20c-b25b-424b-ac62-1a4349a8cb59@github.com>

This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned.

-------------

Commit messages:
 - 8277474: jarsigner does not check if algorithm parameters are disabled

Changes: https://git.openjdk.java.net/jdk/pull/7582/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277474
  Stats: 120 lines in 3 files changed: 111 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7582.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7582/head:pull/7582

PR: https://git.openjdk.java.net/jdk/pull/7582

From xuelei at openjdk.java.net  Wed Feb 23 00:12:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 00:12:16 GMT
Subject: RFR: 8282279: Interpret case-insensitive string locale independently
Message-ID: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>

The String.toUpperCase() or String.toLowerCase() method is locale sensitive, and may produce unexpected results if used for strings that are intended to be interpreted locale independently.  The use of the two methods had been cleaned before, but there are a few new introduced laterly.

See https://www.ivi.co/java/2011/07/07/4878.html for examples.

-------------

Commit messages:
 - 8282279: Interpret case-insensitive string locale independently

Changes: https://git.openjdk.java.net/jdk/pull/7583/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7583&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282279
  Stats: 18 lines in 5 files changed: 5 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7583.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7583/head:pull/7583

PR: https://git.openjdk.java.net/jdk/pull/7583

From ecki at zusammenkunft.net  Wed Feb 23 08:52:04 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 23 Feb 2022 08:52:04 +0000
Subject: RFR: 8282279: Interpret case-insensitive string locale
 independently
In-Reply-To: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
References: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
Message-ID: <AM9P193MB1142149E524624C1A52C2057FF3C9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

The last replace seems a bit strange, I would expect it should first normalize the case and then the hyphen, otherwise it won?t match the replace?

Looks to me like not using toUpperCase in the trace messages would be more efficient and produces shorter code.

Isn?t it customary to use the ROOT locale instead of ENGLISH?
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Xue-Lei Andrew Fan <xuelei at openjdk.java.net>
Gesendet: Wednesday, February 23, 2022 1:12:16 AM
An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: RFR: 8282279: Interpret case-insensitive string locale independently

The String.toUpperCase() or String.toLowerCase() method is locale sensitive, and may produce unexpected results if used for strings that are intended to be interpreted locale independently.  The use of the two methods had been cleaned before, but there are a few new introduced laterly.

See https://www.ivi.co/java/2011/07/07/4878.html for examples.

-------------

Commit messages:
 - 8282279: Interpret case-insensitive string locale independently

Changes: https://git.openjdk.java.net/jdk/pull/7583/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7583&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282279
  Stats: 18 lines in 5 files changed: 5 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7583.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7583/head:pull/7583

PR: https://git.openjdk.java.net/jdk/pull/7583
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220223/6c7a1851/attachment-0001.htm>

From alanb at openjdk.java.net  Wed Feb 23 10:38:56 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Feb 2022 10:38:56 GMT
Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing
 ze.getName() [v8]
In-Reply-To: <ESL1CUYbDeZh5KrD6leJB7NaQSD-1qqDUK7geclbh94=.d5a1657b-cafc-4f8a-a419-7ddbb0e6f9ca@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
 <ESL1CUYbDeZh5KrD6leJB7NaQSD-1qqDUK7geclbh94=.d5a1657b-cafc-4f8a-a419-7ddbb0e6f9ca@github.com>
Message-ID: <ks-v5uCyxAFOjZEldGXhuKOgTwlD3iLtVB2jnKRGJyQ=.cb547f2d-5fcd-410d-ae48-75ae8ab7da04@github.com>

On Tue, 22 Feb 2022 22:05:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the attached patch to address
>> 
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
>> 
>> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified and clarified test comments

Thanks for the update to the test to provide instructions on how to re-create the JAR and sign it.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7348

From weijun at openjdk.java.net  Wed Feb 23 14:35:50 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 23 Feb 2022 14:35:50 GMT
Subject: RFR: 8282279: Interpret case-insensitive string locale
 independently
In-Reply-To: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
References: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
Message-ID: <Pkdqmwg9L6MFaoVc-W54J_5KiX1n0wuBPIkCdtjdda8=.d128aef1-a399-44c9-a17a-22e0f80861f7@github.com>

On Wed, 23 Feb 2022 00:05:58 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The String.toUpperCase() or String.toLowerCase() method is locale sensitive, and may produce unexpected results if used for strings that are intended to be interpreted locale independently.  The use of the two methods had been cleaned before, but there are a few new introduced laterly.
> 
> See https://www.ivi.co/java/2011/07/07/4878.html for examples.

Well done. Thanks for taking care of this.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7583

From rriggs at openjdk.java.net  Wed Feb 23 14:54:48 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 23 Feb 2022 14:54:48 GMT
Subject: RFR: 8282279: Interpret case-insensitive string locale
 independently
In-Reply-To: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
References: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
Message-ID: <s9baz8K3tHPGEa2y4M_HnQrWLQmPC0at2VdDLjO6qVw=.18739322-9e56-4fc8-9618-3b9308e108f8@github.com>

On Wed, 23 Feb 2022 00:05:58 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The String.toUpperCase() or String.toLowerCase() method is locale sensitive, and may produce unexpected results if used for strings that are intended to be interpreted locale independently.  The use of the two methods had been cleaned before, but there are a few new introduced laterly.
> 
> See https://www.ivi.co/java/2011/07/07/4878.html for examples.

Locale.ROOT is preferred for locale independent uppercase and lowercase().

BTW, for the strings written to the SSLLogger, I would have kept the original case intact.
Yes, they are equivalent but it slightly obscures the original data and uses a bit of cpu.

-------------

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7583

From xuelei at openjdk.java.net  Wed Feb 23 15:43:51 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 15:43:51 GMT
Subject: RFR: 8282279: Interpret case-insensitive string locale
 independently
In-Reply-To: <s9baz8K3tHPGEa2y4M_HnQrWLQmPC0at2VdDLjO6qVw=.18739322-9e56-4fc8-9618-3b9308e108f8@github.com>
References: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
 <s9baz8K3tHPGEa2y4M_HnQrWLQmPC0at2VdDLjO6qVw=.18739322-9e56-4fc8-9618-3b9308e108f8@github.com>
Message-ID: <VybtSzalA6a-vgEfvs-KA7nA-Ms9Dwa7zNQodgV6aVQ=.8cf2d452-e238-414c-b4be-0c20fde79583@github.com>

On Wed, 23 Feb 2022 14:51:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Locale.ROOT is preferred for locale independent uppercase and lowercase().

Yes, as the Locale.English has been used a lot.  It may worthy another enhancement to use Locale.ROOT in a separate PR.

> BTW, for the strings written to the SSLLogger, I would have kept the original case intact.

and

> Looks to me like not using toUpperCase in the trace messages would be more efficient and produces shorter code.

Agreed.  I will search for similar code and see if I could have a fix in a separate PR.

> The last replace seems a bit strange, I would expect it should first normalize the case and then the hyphen, otherwise it won?t match the replace?

It looks like a bug to me. I would like to keep this PR focus on case issues, and may file another PR for this bug.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7583

From xuelei at openjdk.java.net  Wed Feb 23 15:46:54 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 15:46:54 GMT
Subject: Integrated: 8282279: Interpret case-insensitive string locale
 independently
In-Reply-To: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
References: <WNrWyy_s-946GgkoAM8IVk0KZYoaJAoezOcWtqiF_Os=.29dd4fe2-e49a-41f5-a56f-1c685a78984e@github.com>
Message-ID: <cgVPHm1DoGSCZNElz1jRSse5d7YCoCaQL4l9YOSJINo=.e63fe39e-abef-436f-a002-e09ef5b7bdd5@github.com>

On Wed, 23 Feb 2022 00:05:58 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The String.toUpperCase() or String.toLowerCase() method is locale sensitive, and may produce unexpected results if used for strings that are intended to be interpreted locale independently.  The use of the two methods had been cleaned before, but there are a few new introduced laterly.
> 
> See https://www.ivi.co/java/2011/07/07/4878.html for examples.

This pull request has now been integrated.

Changeset: 340a35d8
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/340a35d8358456620954ae0c668cf3d1d617bb88
Stats:     18 lines in 5 files changed: 5 ins; 0 del; 13 mod

8282279: Interpret case-insensitive string locale independently

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/7583

From xuelei at openjdk.java.net  Wed Feb 23 16:15:19 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 16:15:19 GMT
Subject: RFR: 8282309: Operation before upper case conversion
Message-ID: <jTJkg8mjpEbOGWEi66cS3TlF0SmZ3pAPM0UpUL7GGSg=.58eb3261-1a3a-4074-84d0-7ade59fcc106@github.com>

In the TlsChannelBinding.java implementation, the string operation is placed before the case conversion. The behavior may be not expected.


        String hashAlg = serverCertificate.getSigAlgName().
-          replace("SHA", "SHA-").toUpperCase(Locale.ENGLISH);
+         toUpperCase(Locale.ENGLISH).replace("SHA", "SHA-");


See also [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) comment in [PR 7583](https://github.com/openjdk/jdk/pull/7583)

-------------

Commit messages:
 - 8282309: Operation before upper case conversion

Changes: https://git.openjdk.java.net/jdk/pull/7592/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7592&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282309
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7592.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7592/head:pull/7592

PR: https://git.openjdk.java.net/jdk/pull/7592

From lancea at openjdk.java.net  Wed Feb 23 17:01:01 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 23 Feb 2022 17:01:01 GMT
Subject: Integrated: 8280409: JarFile::getInputStream can fail with NPE
 accessing ze.getName()
In-Reply-To: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
References: <hMvvKqbAvs9tsMAwcjE2t0b9Lp1qFXQI7NNYTf-owpc=.bc967983-8767-42cb-a95a-4ad5d7f077bb@github.com>
Message-ID: <s_uUorpZG2HhZvmv_OnpH9deEwZIag06csXvTrF1PQU=.b1967948-abfb-41a1-8fb5-9be24eb1cbeb@github.com>

On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review the attached patch to address
> 
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs
> 
> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: a020b6ba
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a020b6ba8f38fe85fb26972a51e4c1068408b1c1
Stats:     1103 lines in 3 files changed: 1071 ins; 0 del; 32 mod

8280409: JarFile::getInputStream can fail with NPE accessing ze.getName()

Reviewed-by: mullan, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7348

From valeriep at openjdk.java.net  Wed Feb 23 17:57:47 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Feb 2022 17:57:47 GMT
Subject: RFR: 8282309: Operation before upper case conversion
In-Reply-To: <jTJkg8mjpEbOGWEi66cS3TlF0SmZ3pAPM0UpUL7GGSg=.58eb3261-1a3a-4074-84d0-7ade59fcc106@github.com>
References: <jTJkg8mjpEbOGWEi66cS3TlF0SmZ3pAPM0UpUL7GGSg=.58eb3261-1a3a-4074-84d0-7ade59fcc106@github.com>
Message-ID: <ZC1iBdBMwf8APLoEtNBIbcrBXg2ZuGNjPw_QlQAI-K8=.bd83c419-583b-4b02-9234-91f03a37ab23@github.com>

On Wed, 23 Feb 2022 16:08:49 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the TlsChannelBinding.java implementation, the string operation is placed before the case conversion. The behavior may be not expected.
> 
> 
>         String hashAlg = serverCertificate.getSigAlgName().
> -          replace("SHA", "SHA-").toUpperCase(Locale.ENGLISH);
> +         toUpperCase(Locale.ENGLISH).replace("SHA", "SHA-");
> 
> 
> See also [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) comment in [PR 7583](https://github.com/openjdk/jdk/pull/7583)

This change looks good. Just wondering, have other JSSE source code been checked for same problem?

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7592

From xuelei at openjdk.java.net  Wed Feb 23 18:22:53 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 18:22:53 GMT
Subject: RFR: 8282309: Operation before upper case conversion
In-Reply-To: <ZC1iBdBMwf8APLoEtNBIbcrBXg2ZuGNjPw_QlQAI-K8=.bd83c419-583b-4b02-9234-91f03a37ab23@github.com>
References: <jTJkg8mjpEbOGWEi66cS3TlF0SmZ3pAPM0UpUL7GGSg=.58eb3261-1a3a-4074-84d0-7ade59fcc106@github.com>
 <ZC1iBdBMwf8APLoEtNBIbcrBXg2ZuGNjPw_QlQAI-K8=.bd83c419-583b-4b02-9234-91f03a37ab23@github.com>
Message-ID: <4XhN-bC8peVQcOz8Bf01-5UlwCJ740FtJLljTtKTRyM=.4b3b0c41-8f39-480d-ba1a-6addb02b9921@github.com>

On Wed, 23 Feb 2022 17:54:35 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Just wondering, have other JSSE source code been checked for same problem?

Thank you for the review.

I checked the JSSE implementation code, this is the only one I found so far.  I will check other components, and see if there is anything similar.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7592

From wetmore at openjdk.java.net  Wed Feb 23 18:31:02 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 23 Feb 2022 18:31:02 GMT
Subject: RFR: 8282309: Operation before upper case conversion
In-Reply-To: <jTJkg8mjpEbOGWEi66cS3TlF0SmZ3pAPM0UpUL7GGSg=.58eb3261-1a3a-4074-84d0-7ade59fcc106@github.com>
References: <jTJkg8mjpEbOGWEi66cS3TlF0SmZ3pAPM0UpUL7GGSg=.58eb3261-1a3a-4074-84d0-7ade59fcc106@github.com>
Message-ID: <X2RFI0Yz4IBFovrXzb4Oid53e3qi8A0O3VOU5ds_Cu4=.4415e01e-ae3c-4adb-b736-3ef179ae6e28@github.com>

On Wed, 23 Feb 2022 16:08:49 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the TlsChannelBinding.java implementation, the string operation is placed before the case conversion. The behavior may be not expected.
> 
> 
>         String hashAlg = serverCertificate.getSigAlgName().
> -          replace("SHA", "SHA-").toUpperCase(Locale.ENGLISH);
> +         toUpperCase(Locale.ENGLISH).replace("SHA", "SHA-");
> 
> 
> See also [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) comment in [PR 7583](https://github.com/openjdk/jdk/pull/7583)

Checking other java.security.*/sun.security.* components outside JSSE would be a good idea, but this particular change looks good to me also.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7592

From xuelei at openjdk.java.net  Wed Feb 23 18:36:51 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 18:36:51 GMT
Subject: Integrated: 8282309: Operation before upper case conversion
In-Reply-To: <jTJkg8mjpEbOGWEi66cS3TlF0SmZ3pAPM0UpUL7GGSg=.58eb3261-1a3a-4074-84d0-7ade59fcc106@github.com>
References: <jTJkg8mjpEbOGWEi66cS3TlF0SmZ3pAPM0UpUL7GGSg=.58eb3261-1a3a-4074-84d0-7ade59fcc106@github.com>
Message-ID: <Xv0WlwXGODWPBbuI4E404q5jae5qjv94fKmyOQUaKqE=.90be1014-e3cc-446e-b1c7-65338b9a58f5@github.com>

On Wed, 23 Feb 2022 16:08:49 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the TlsChannelBinding.java implementation, the string operation is placed before the case conversion. The behavior may be not expected.
> 
> 
>         String hashAlg = serverCertificate.getSigAlgName().
> -          replace("SHA", "SHA-").toUpperCase(Locale.ENGLISH);
> +         toUpperCase(Locale.ENGLISH).replace("SHA", "SHA-");
> 
> 
> See also [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) comment in [PR 7583](https://github.com/openjdk/jdk/pull/7583)

This pull request has now been integrated.

Changeset: 7dc7184c
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7dc7184c10fc8f7a02113056da979a9846a14cd4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8282309: Operation before upper case conversion

Reviewed-by: valeriep, wetmore

-------------

PR: https://git.openjdk.java.net/jdk/pull/7592

From xuelei at openjdk.java.net  Wed Feb 23 19:31:18 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 19:31:18 GMT
Subject: RFR: 8282316: Operation before String case conversion
Message-ID: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>

In the SignatureUtil implementation, the checkName() requires case-insensitive input for "OID".  However, the method is called before the case conversion, for example: 

            sigName = checkName(sigName).toUpperCase(Locale.ENGLISH); 

This update also clean up redundant calls to the checkName() method.

-------------

Commit messages:
 - 8282316: Operation before String case conversion

Changes: https://git.openjdk.java.net/jdk/pull/7598/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7598&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282316
  Stats: 21 lines in 1 file changed: 10 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7598.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7598/head:pull/7598

PR: https://git.openjdk.java.net/jdk/pull/7598

From xuelei at openjdk.java.net  Wed Feb 23 20:23:12 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 20:23:12 GMT
Subject: RFR: 8273042: TLS Certificate Compression
Message-ID: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>

Hi,

Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK.  The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections.  More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal.

The JEP was submitted, and it may take time for the final approval.  But let me know you ideas and concerns about the proposal and implementation.

JEP: https://bugs.openjdk.java.net/browse/JDK-8281710

-------------

Commit messages:
 - Merge
 - Describe public APIs
 - test and httpclient
 - 8273042: TLS Certificate Compression
 - Merge
 - Merge
 - Merge
 - 8273042: TLS Certificate Compression

Changes: https://git.openjdk.java.net/jdk/pull/7599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7599&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273042
  Stats: 1822 lines in 17 files changed: 1796 ins; 16 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7599/head:pull/7599

PR: https://git.openjdk.java.net/jdk/pull/7599

From xuelei at openjdk.java.net  Wed Feb 23 22:22:40 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 22:22:40 GMT
Subject: RFR: 8282320: Remove case conversion for debugging log in SSLCipher
Message-ID: <GCZ9x1COesa6OtvCHYyyeGSm68oOP-PFNCnOV7XEQcI=.397b548d-1360-4b60-a26c-6c84affc06dd@github.com>

String.toUpperCase() is used in SSLCipher.java for debugging logging, which is not necessary. See also comment in [this PR](https://github.com/openjdk/jdk/pull/7583).

-------------

Commit messages:
 - 8282320: Remove case conversion for debugging log in SSLCipher

Changes: https://git.openjdk.java.net/jdk/pull/7600/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7600&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282320
  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7600/head:pull/7600

PR: https://git.openjdk.java.net/jdk/pull/7600

From valeriep at openjdk.java.net  Wed Feb 23 22:46:24 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Feb 2022 22:46:24 GMT
Subject: RFR: 8282316: Operation before String case conversion
In-Reply-To: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
References: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
Message-ID: <IfHIMMMpPfYH7ikc77oV_9ulv7GzBgMt5elpul14eEc=.66e1b96f-2f59-4a76-8d26-8fd8f27da828@github.com>

On Wed, 23 Feb 2022 19:25:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the SignatureUtil implementation, the checkName() requires case-insensitive input for "OID".  However, the method is called before the case conversion, for example: 
> 
>             sigName = checkName(sigName).toUpperCase(Locale.ENGLISH); 
> 
> This update also clean up redundant calls to the checkName() method.

Looks good. Thanks~

src/java.base/share/classes/sun/security/util/SignatureUtil.java line 54:

> 52:      *
> 53:      * @param algName input, could be in any form
> 54:      * @return the matching stdName, or {@code algName} if it is not in the

nit: simplify this return description and emphasize upper case here also? E.g. the matching stdName or the OID string in upper case.

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7598

From xuelei at openjdk.java.net  Wed Feb 23 23:34:05 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 23:34:05 GMT
Subject: RFR: 8282316: Operation before String case conversion
In-Reply-To: <IfHIMMMpPfYH7ikc77oV_9ulv7GzBgMt5elpul14eEc=.66e1b96f-2f59-4a76-8d26-8fd8f27da828@github.com>
References: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
 <IfHIMMMpPfYH7ikc77oV_9ulv7GzBgMt5elpul14eEc=.66e1b96f-2f59-4a76-8d26-8fd8f27da828@github.com>
Message-ID: <EnjkUCUWgygcyaAY6_HMtrcQl-EgQ2gbFds81WeIko4=.0a6204a2-2579-49dd-96b2-ab87e28efaa2@github.com>

On Wed, 23 Feb 2022 22:41:10 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> In the SignatureUtil implementation, the checkName() requires case-insensitive input for "OID".  However, the method is called before the case conversion, for example: 
>> 
>>             sigName = checkName(sigName).toUpperCase(Locale.ENGLISH); 
>> 
>> This update also clean up redundant calls to the checkName() method.
>
> src/java.base/share/classes/sun/security/util/SignatureUtil.java line 54:
> 
>> 52:      *
>> 53:      * @param algName input, could be in any form
>> 54:      * @return the matching stdName, or {@code algName} if it is not in the
> 
> nit: simplify this return description and emphasize upper case here also? E.g. the matching stdName or the OID string in upper case.

Good point!  I will make this update in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7598

From xuelei at openjdk.java.net  Wed Feb 23 23:41:36 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 23 Feb 2022 23:41:36 GMT
Subject: RFR: 8282316: Operation before String case conversion [v2]
In-Reply-To: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
References: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
Message-ID: <wE3DVpCVSeqCNw6HZZtFgd5ZlqyPaecKHaEWudW0T3o=.528ce907-1c34-423f-82b3-1b21dbbbcf3d@github.com>

> In the SignatureUtil implementation, the checkName() requires case-insensitive input for "OID".  However, the method is called before the case conversion, for example: 
> 
>             sigName = checkName(sigName).toUpperCase(Locale.ENGLISH); 
> 
> This update also clean up redundant calls to the checkName() method.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  udpate return state as well

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7598/files
  - new: https://git.openjdk.java.net/jdk/pull/7598/files/e90b7305..4faf3da7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7598&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7598&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7598.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7598/head:pull/7598

PR: https://git.openjdk.java.net/jdk/pull/7598

From weijun at openjdk.java.net  Wed Feb 23 23:57:04 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 23 Feb 2022 23:57:04 GMT
Subject: RFR: 8282316: Operation before String case conversion [v2]
In-Reply-To: <wE3DVpCVSeqCNw6HZZtFgd5ZlqyPaecKHaEWudW0T3o=.528ce907-1c34-423f-82b3-1b21dbbbcf3d@github.com>
References: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
 <wE3DVpCVSeqCNw6HZZtFgd5ZlqyPaecKHaEWudW0T3o=.528ce907-1c34-423f-82b3-1b21dbbbcf3d@github.com>
Message-ID: <Hhz9vi-Ikxb3k3gE0nuq6FuTLx9wDvdHvfwiqdk_bLc=.b3337a55-66af-4a1d-9e58-3a18ccb3c3a9@github.com>

On Wed, 23 Feb 2022 23:41:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> In the SignatureUtil implementation, the checkName() requires case-insensitive input for "OID".  However, the method is called before the case conversion, for example: 
>> 
>>             sigName = checkName(sigName).toUpperCase(Locale.ENGLISH); 
>> 
>> This update also clean up redundant calls to the checkName() method.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   udpate return state as well

src/java.base/share/classes/sun/security/util/SignatureUtil.java line 51:

> 49:     /**
> 50:      * Convert OID.1.2.3.4 or 1.2.3.4 to its matching stdName, and literal
> 51:      * name to upper case.

It sounds like you only convert literal name to upper case and return stdName for OIDs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7598

From xuelei at openjdk.java.net  Thu Feb 24 00:46:50 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 24 Feb 2022 00:46:50 GMT
Subject: RFR: 8282316: Operation before String case conversion [v2]
In-Reply-To: <Hhz9vi-Ikxb3k3gE0nuq6FuTLx9wDvdHvfwiqdk_bLc=.b3337a55-66af-4a1d-9e58-3a18ccb3c3a9@github.com>
References: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
 <wE3DVpCVSeqCNw6HZZtFgd5ZlqyPaecKHaEWudW0T3o=.528ce907-1c34-423f-82b3-1b21dbbbcf3d@github.com>
 <Hhz9vi-Ikxb3k3gE0nuq6FuTLx9wDvdHvfwiqdk_bLc=.b3337a55-66af-4a1d-9e58-3a18ccb3c3a9@github.com>
Message-ID: <LcGimy4-J6sZoFV0I86dpaTcP3qQJ3XV1fVzUw28np8=.7ab9992f-5df0-4c90-8334-9c0c915db5bf@github.com>

On Wed, 23 Feb 2022 23:53:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   udpate return state as well
>
> src/java.base/share/classes/sun/security/util/SignatureUtil.java line 51:
> 
>> 49:     /**
>> 50:      * Convert OID.1.2.3.4 or 1.2.3.4 to its matching stdName, and literal
>> 51:      * name to upper case.
> 
> It sounds like you only convert literal name to upper case and return stdName for OIDs.

Hm, it makes sense to me.  Updated in the next commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7598

From xuelei at openjdk.java.net  Thu Feb 24 00:46:50 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 24 Feb 2022 00:46:50 GMT
Subject: RFR: 8282316: Operation before String case conversion [v3]
In-Reply-To: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
References: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
Message-ID: <cZzb47iax0E-Khc83DlW12q_X9_19isYYJS4_r1Hhto=.7ca4f2c8-1601-46a0-bcf3-42aeba7cf1dc@github.com>

> In the SignatureUtil implementation, the checkName() requires case-insensitive input for "OID".  However, the method is called before the case conversion, for example: 
> 
>             sigName = checkName(sigName).toUpperCase(Locale.ENGLISH); 
> 
> This update also clean up redundant calls to the checkName() method.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  udpate summary spec of checkName

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7598/files
  - new: https://git.openjdk.java.net/jdk/pull/7598/files/4faf3da7..5c6e4275

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7598&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7598&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7598.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7598/head:pull/7598

PR: https://git.openjdk.java.net/jdk/pull/7598

From xuelei at openjdk.java.net  Thu Feb 24 16:29:05 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 24 Feb 2022 16:29:05 GMT
Subject: Integrated: 8282316: Operation before String case conversion
In-Reply-To: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
References: <xfL3vizZSLIHlQi2_worJpq0LanET2ncXNCLlKXNyHo=.bc319af2-be43-41e5-ae4d-bd7aecf96bf2@github.com>
Message-ID: <ZQFLjj61rPKCf3c2D9CLsFSFEEO2SkTb3iibH4Xqfpc=.c7b55677-0dbe-41b7-b82f-e582e0762e53@github.com>

On Wed, 23 Feb 2022 19:25:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> In the SignatureUtil implementation, the checkName() requires case-insensitive input for "OID".  However, the method is called before the case conversion, for example: 
> 
>             sigName = checkName(sigName).toUpperCase(Locale.ENGLISH); 
> 
> This update also clean up redundant calls to the checkName() method.

This pull request has now been integrated.

Changeset: abc0ce11
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/abc0ce11dfa0a751a12925763cb168d1d3b4f44a
Stats:     23 lines in 1 file changed: 10 ins; 3 del; 10 mod

8282316: Operation before String case conversion

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk/pull/7598

From weijun at openjdk.java.net  Thu Feb 24 17:51:07 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 24 Feb 2022 17:51:07 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <xvKE6mKQqjoRcQ2vEzfSEZ9GAmuzYDaoSnkylfTno-c=.f32adddb-5b97-4f42-8c80-583db1f2cdd5@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

I'm the original author of `sspi.cpp`. All changes look fine to me. Thanks a lot for the enhancement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7565

From djelinski at openjdk.java.net  Thu Feb 24 17:56:05 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Feb 2022 17:56:05 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <dT9-STWdBmnXf6mFXNslesrmFvyLrLZMflRbNWjslIM=.a2d6dc98-41e4-4fce-a198-293bbb4ae650@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

Great, thanks all for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7565

From djelinski at openjdk.java.net  Thu Feb 24 18:23:06 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Feb 2022 18:23:06 GMT
Subject: Integrated: 8281525: Enable Zc:strictStrings flag in Visual Studio
 build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <MF2IUkKV8ihC_zd8yRpJJPfPJ_Idc0_QU4crXs_1Zng=.fa781f16-8c29-4e73-9412-dfe7ec2e2aaa@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

This pull request has now been integrated.

Changeset: 23995f82
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23995f822e540d799eb4bbc969229422257fbb08
Stats:     23 lines in 6 files changed: 0 ins; 0 del; 23 mod

8281525: Enable Zc:strictStrings flag in Visual Studio build

Reviewed-by: dholmes, ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/7565

From hchao at openjdk.java.net  Thu Feb 24 20:35:00 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 24 Feb 2022 20:35:00 GMT
Subject: RFR: 8281234: The -protected option is not always checked in
 keytool and jarsigner [v2]
In-Reply-To: <GG1iYptIpwueW-PnWJu97qjVYkGMWP2wv7AX7WKyCIA=.ff612811-17d7-4deb-a0fb-54d238862049@github.com>
References: <myBBDTONMJ5D3z2WZ5zjbnNdWGAuVvjwmrezvu_LZhw=.808f9c00-e41e-4e6a-a301-de2b5b2acf2a@github.com>
 <GG1iYptIpwueW-PnWJu97qjVYkGMWP2wv7AX7WKyCIA=.ff612811-17d7-4deb-a0fb-54d238862049@github.com>
Message-ID: <64AiYGjI9psELlvepZ266VuRRJbG9tc-Jt3aEp6Jsoc=.1d11cc23-6c7a-4bae-8cb6-4551c1db5b44@github.com>

On Fri, 4 Feb 2022 01:19:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The option means there is no need to provide a password when loading a keystore. In some places in jarsigner and keytool, even with the option specified, password is still prompted for or warnings are still shown.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only expand system property if it has a name

Looks good to me.

-------------

Marked as reviewed by hchao (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7339

From rhalade at openjdk.java.net  Fri Feb 25 21:50:19 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 25 Feb 2022 21:50:19 GMT
Subject: RFR: 8282398: EndingDotHostname.java test fails because SSL cert
 expired
Message-ID: <bFYDR-Ug-p-NqFHCZ3w_fsB9OYBTh-8eEXTi6LZA1QI=.7b2c0c6c-e874-4a03-8d6d-f2285a143a59@github.com>

Updated test certificates with 20 years of validity

-------------

Commit messages:
 - 8065422: remove unwanted change
 - 8282398: EndingDotHostname.java test fails because SSL cert expired

Changes: https://git.openjdk.java.net/jdk/pull/7626/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7626&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282398
  Stats: 205 lines in 2 files changed: 30 ins; 1 del; 174 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7626.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7626/head:pull/7626

PR: https://git.openjdk.java.net/jdk/pull/7626

From rhalade at openjdk.java.net  Sat Feb 26 02:32:26 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Sat, 26 Feb 2022 02:32:26 GMT
Subject: RFR: 8282398: EndingDotHostname.java test fails because SSL cert
 expired [v2]
In-Reply-To: <bFYDR-Ug-p-NqFHCZ3w_fsB9OYBTh-8eEXTi6LZA1QI=.7b2c0c6c-e874-4a03-8d6d-f2285a143a59@github.com>
References: <bFYDR-Ug-p-NqFHCZ3w_fsB9OYBTh-8eEXTi6LZA1QI=.7b2c0c6c-e874-4a03-8d6d-f2285a143a59@github.com>
Message-ID: <vYz17tDkveU-YUd1Mnbov22dM05zLgCKGqadI8hWtso=.01616daa-b733-422b-85c2-873b191ae1ab@github.com>

> Updated test certificates with 20 years of validity

Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:

  8065422: update formatting

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7626/files
  - new: https://git.openjdk.java.net/jdk/pull/7626/files/669e3524..e2529520

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7626&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7626&range=00-01

  Stats: 31 lines in 2 files changed: 0 ins; 1 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7626.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7626/head:pull/7626

PR: https://git.openjdk.java.net/jdk/pull/7626

From xuelei at openjdk.java.net  Sat Feb 26 05:56:53 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 26 Feb 2022 05:56:53 GMT
Subject: RFR: 8282398: EndingDotHostname.java test fails because SSL cert
 expired [v2]
In-Reply-To: <vYz17tDkveU-YUd1Mnbov22dM05zLgCKGqadI8hWtso=.01616daa-b733-422b-85c2-873b191ae1ab@github.com>
References: <bFYDR-Ug-p-NqFHCZ3w_fsB9OYBTh-8eEXTi6LZA1QI=.7b2c0c6c-e874-4a03-8d6d-f2285a143a59@github.com>
 <vYz17tDkveU-YUd1Mnbov22dM05zLgCKGqadI8hWtso=.01616daa-b733-422b-85c2-873b191ae1ab@github.com>
Message-ID: <EocgWPnImwFJDFzBdIvh5ucQWUaaXL1GQk3F61-ZFxA=.5dece0ef-1d34-4aa3-81f4-337f7fca9cfe@github.com>

On Sat, 26 Feb 2022 02:32:26 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Updated test certificates with 20 years of validity
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8065422: update formatting

Looks good to me.  Thanks!

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7626

From rhalade at openjdk.java.net  Sat Feb 26 17:14:47 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Sat, 26 Feb 2022 17:14:47 GMT
Subject: Integrated: 8282398: EndingDotHostname.java test fails because SSL
 cert expired
In-Reply-To: <bFYDR-Ug-p-NqFHCZ3w_fsB9OYBTh-8eEXTi6LZA1QI=.7b2c0c6c-e874-4a03-8d6d-f2285a143a59@github.com>
References: <bFYDR-Ug-p-NqFHCZ3w_fsB9OYBTh-8eEXTi6LZA1QI=.7b2c0c6c-e874-4a03-8d6d-f2285a143a59@github.com>
Message-ID: <fVXrjrSDRu5LvhKPytbokeWLoFsRgtnDqGdw6wVjn5o=.a52c2bf1-817f-4d86-8e5a-20ef3e809ab2@github.com>

On Fri, 25 Feb 2022 21:41:52 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated test certificates with 20 years of validity

This pull request has now been integrated.

Changeset: afd4bcbc
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/afd4bcbc1d1b2a8a1c29005878c8e06c662a1f6e
Stats:     202 lines in 2 files changed: 30 ins; 2 del; 170 mod

8282398: EndingDotHostname.java test fails because SSL cert expired

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/7626

From weijun at openjdk.java.net  Mon Feb 28 17:03:59 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Feb 2022 17:03:59 GMT
Subject: RFR: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName [v9]
In-Reply-To: <9w5mTLPhqn9AcaYrbycNHfQfBi7r8BL0KJsGpK9kUpA=.b4dfcbf5-64c9-4d0d-838b-64dd9ef4947e@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
 <9w5mTLPhqn9AcaYrbycNHfQfBi7r8BL0KJsGpK9kUpA=.b4dfcbf5-64c9-4d0d-838b-64dd9ef4947e@github.com>
Message-ID: <rS3l69w82qcBopPR-5-jWU_9e6RcGYZG9oG709MBK5w=.7821e7a2-2a6b-4f84-8ffc-ba7f09a68db0@github.com>

On Fri, 18 Feb 2022 20:05:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
>> 
>> It also fix several errors:
>> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
>> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make exception message clearer

I haven't logged the IOException. When this (otherName with a char string value but 4th entry is not string) happens, this is the only reason.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From weijun at openjdk.java.net  Mon Feb 28 17:04:00 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Feb 2022 17:04:00 GMT
Subject: Integrated: 8277976: Break up SEQUENCE in
 X509Certificate::getSubjectAlternativeNames and
 X509Certificate::getIssuerAlternativeNames in otherName
In-Reply-To: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
References: <Jghf5bAa1ZaZsa0dItssnYVhiEbPl2zHuysBUM8ICzo=.eb0fe3c5-c8cb-45be-ae8b-9c941e145919@github.com>
Message-ID: <oUSWiit3OAEu6o5AKbmP8jeqTjNxRcYy_FoCC3MQyzA=.f1f51ef5-c042-443e-95ac-74f8019214e7@github.com>

On Thu, 20 Jan 2022 19:42:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName.
> 
> It also fix several errors:
> 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes.
> 2. The argument in constructor `extClass.getConstructor(Object.class)` is suspicious. Maybe it meant `byte[]`.

This pull request has now been integrated.

Changeset: 59b3ecc5
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/59b3ecc591ef6407d6b3f5532ecf889bf61339f0
Stats:     154 lines in 4 files changed: 132 ins; 0 del; 22 mod

8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName
6776681: Invalid encoding of an OtherName in X509Certificate.getAlternativeNames()

Reviewed-by: mullan

-------------

PR: https://git.openjdk.java.net/jdk/pull/7167

From xueleifan at tencent.com  Mon Feb 28 18:57:57 2022
From: xueleifan at tencent.com (xueleifan(XueleiFan))
Date: Mon, 28 Feb 2022 18:57:57 +0000
Subject: JEP Review Request: TLS Certificate Compression
In-Reply-To: <9D47E367-3214-46E9-A73D-5B8693C42BD2@Tencent.Com>
References: <9D47E367-3214-46E9-A73D-5B8693C42BD2@Tencent.Com>
Message-ID: <E00B7163-6ACF-4AFB-A449-28A9339A7BAD@Tencent.Com>

Hi,

Could I have this JEP reviewed?  One or more qualified Committers review is required to move it forward.

Here is the PR if you want to have a further look at the implementation and test:
    https://github.com/openjdk/jdk/pull/7599

Thanks,
Xuelei

On Feb 15, 2022, at 9:30 PM, xueleifan(XueleiFan) <xueleifan at tencent.com<mailto:xueleifan at tencent.com>> wrote:

Hi all,

The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review.  Detailed, please refer to the draft:

    https://bugs.openjdk.java.net/browse/JDK-8281710

Feel free to make comment and send your feedback to the alias.  I may submit this JEP in the beginning of next week if I hear no objections by the end of this week.

Thanks,
Xuelei


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220228/dee192d5/attachment.htm>

From jnimeh at openjdk.java.net  Mon Feb 28 19:47:35 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 28 Feb 2022 19:47:35 GMT
Subject: RFR: 8273042: TLS Certificate Compression
In-Reply-To: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>
References: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>
Message-ID: <8aulg1Sv0Lu9Yv0MznJceizD4krTUHmIHLyzrYKK-8Q=.16c8990e-230a-4b7c-8372-57fe1d5955a2@github.com>

On Wed, 23 Feb 2022 20:15:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK.  The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections.  More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal.
> 
> The JEP was submitted, and it may take time for the final approval.  But let me know you ideas and concerns about the proposal and implementation.
> 
> JEP: https://bugs.openjdk.java.net/browse/JDK-8281710

src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 49:

> 47:     }
> 48: 
> 49:     static CompressionAlgorithm nameOf(String name) {

Shouldn't this be valueOf?  We're not consistent in the method name across all our sun.security.ssl enumerations, but more often than not when we return the enumeration object it's via a valueOf call.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7599

From jnimeh at openjdk.java.net  Mon Feb 28 19:47:35 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 28 Feb 2022 19:47:35 GMT
Subject: RFR: 8273042: TLS Certificate Compression
In-Reply-To: <8aulg1Sv0Lu9Yv0MznJceizD4krTUHmIHLyzrYKK-8Q=.16c8990e-230a-4b7c-8372-57fe1d5955a2@github.com>
References: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>
 <8aulg1Sv0Lu9Yv0MznJceizD4krTUHmIHLyzrYKK-8Q=.16c8990e-230a-4b7c-8372-57fe1d5955a2@github.com>
Message-ID: <hn2TWrx0NLD_sDXac9IqmZXg_KRnUeTnF1m_wZdlvWM=.523df7c2-a89b-458e-98ea-18ae3f8e29c8@github.com>

On Mon, 28 Feb 2022 19:41:59 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK.  The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections.  More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal.
>> 
>> The JEP was submitted, and it may take time for the final approval.  But let me know you ideas and concerns about the proposal and implementation.
>> 
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8281710
>
> src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 49:
> 
>> 47:     }
>> 48: 
>> 49:     static CompressionAlgorithm nameOf(String name) {
> 
> Shouldn't this be valueOf?  We're not consistent in the method name across all our sun.security.ssl enumerations, but more often than not when we return the enumeration object it's via a valueOf call.

Hmmm...I take that back.  Seems like when the input is a string we do go by nameOf.  Maybe this is fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7599

From xueleifan at tencent.com  Mon Feb 28 20:33:16 2022
From: xueleifan at tencent.com (xueleifan(XueleiFan))
Date: Mon, 28 Feb 2022 20:33:16 +0000
Subject: [Internet]Re: JEP Review Request: TLS Certificate Compression
In-Reply-To: <E00B7163-6ACF-4AFB-A449-28A9339A7BAD@Tencent.Com>
References: <9D47E367-3214-46E9-A73D-5B8693C42BD2@Tencent.Com>
 <E00B7163-6ACF-4AFB-A449-28A9339A7BAD@Tencent.Com>
Message-ID: <7C72500B-4991-416C-AA01-2BB92869C5F3@Tencent.Com>

Hi,

It may be better to have more detail here, rather than refer you to the draft JEP.  The first question maybe, if TLS Certificate Compression is something we want it in OpenJDK?

The TLS Certificate Compression standard was described in RFC 8879, and has been enabled in browser Chrome and Safari. But, what?s TLS Certificate Compression and what?s the benefits of this feature?

For TLS connections, a client must authenticate the identity of the server. This typically involves verification that the identity of the server is included in a certificate and that the certificate is issued by a trusted entity.

Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance and security in QUIC. TLS certificate compression has the potential to ameliorate the attacks/problems by reducing the size of the handshakes to a size compatible with the security restriction.  The TLS Certificate Compression feature is an essential part for QUIC-TLS protocols.

For more details, please refer to section 4.4 in RFC 9001 (Using TLS to Secure QUIC):
---------
Note: Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance in QUIC as servers are limited to sending 3 bytes for every byte received prior to validating the client address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a certificate chain can be managed by limiting the number of names or extensions; using keys with small public key representations, like ECDSA; or by using certificate compression [COMPRESS].?
---------

and a more detailed description in the blog ?Does the QUIC handshake require compression to be fast??(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study).  I just copy part of the conclusion section of the bog here for your quick reference.
---------
First, the TLS certificate compression extension has a very large impact on QUIC performance. Even though the extension is new and being introduced fairly late in the process when compared to overall QUIC deployment schedules, it seems quite important for both clients and servers to implement the new extension so that the QUIC handshake can live up to its billing. Without some help, 40% of QUIC full handshakes would be no better than TCP, but compression can repair most of that issue. I have heard of other non-standardized approaches to reducing the size of the certificate chain, and they seem reasonable, but this is a problem worth addressing immediately with the existing compression extension.

...

Lastly, data from the real world again proves to be more insightful than intuition and is invaluable in making protocol design and implementation decisions. When I started this work I expected the impact of compression to be positive but marginally focused on a few edge cases. The data shows this optimization lands right on the sweet spot that ties configurations and the QUIC specification together and impacts a large portion of QUIC handshakes. My thanks to the authors of the compression extension.
---------


Besides, reducing the amount of information exchanged during a TLS handshake to a minimum helps to improve performance in environments, for example Internet of Things, where devices are connected to a network with a low bandwidth and lossy radio technology.

This feature is a part to improve the performance of TLS connections, and it is also a part of the path towards QUIC standards.

Chrome support TLS certificate compression with Brotil compression algorithm, and Safari support TLS certificate compression with Zlib compression algorithm.

In a summary, JDK could benefits from support RFC 8879 in the following areas:

    Performance - Reduce latency and improve performance of TLS and QUIC connections by support the TLS certificate compression standard in JDK.
    Security - Mitigate the impact of amplification attacks threat by reducing the size of the TLS handshakes with compressed certificates.

Please feel free to share you comments, if it is something we want in OpenJDK?

Thanks,
Xuelei


On Feb 28, 2022, at 10:57 AM, xueleifan(XueleiFan) <xueleifan at tencent.com<mailto:xueleifan at tencent.com>> wrote:

Hi,

Could I have this JEP reviewed?  One or more qualified Committers review is required to move it forward.

Here is the PR if you want to have a further look at the implementation and test:
    https://github.com/openjdk/jdk/pull/7599

Thanks,
Xuelei

On Feb 15, 2022, at 9:30 PM, xueleifan(XueleiFan) <xueleifan at tencent.com<mailto:xueleifan at tencent.com>> wrote:

Hi all,

The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review.  Detailed, please refer to the draft:

    https://bugs.openjdk.java.net/browse/JDK-8281710

Feel free to make comment and send your feedback to the alias.  I may submit this JEP in the beginning of next week if I hear no objections by the end of this week.

Thanks,
Xuelei



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220228/16db4738/attachment-0001.htm>

From xuelei at openjdk.java.net  Mon Feb 28 23:12:27 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 28 Feb 2022 23:12:27 GMT
Subject: RFR: 8273042: TLS Certificate Compression
In-Reply-To: <hn2TWrx0NLD_sDXac9IqmZXg_KRnUeTnF1m_wZdlvWM=.523df7c2-a89b-458e-98ea-18ae3f8e29c8@github.com>
References: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>
 <8aulg1Sv0Lu9Yv0MznJceizD4krTUHmIHLyzrYKK-8Q=.16c8990e-230a-4b7c-8372-57fe1d5955a2@github.com>
 <hn2TWrx0NLD_sDXac9IqmZXg_KRnUeTnF1m_wZdlvWM=.523df7c2-a89b-458e-98ea-18ae3f8e29c8@github.com>
Message-ID: <cbglGmx9-XLYfsPj4r0U5rnmb4cuP7jTEPmjEKi1ou0=.16cf7e65-43e5-492f-a282-30579a14b99d@github.com>

On Mon, 28 Feb 2022 19:44:19 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 49:
>> 
>>> 47:     }
>>> 48: 
>>> 49:     static CompressionAlgorithm nameOf(String name) {
>> 
>> Shouldn't this be valueOf?  We're not consistent in the method name across all our sun.security.ssl enumerations, but more often than not when we return the enumeration object it's via a valueOf call.
>
> Hmmm...I take that back.  Seems like when the input is a string we do go by nameOf.  Maybe this is fine.

I think I see your points. valueOf(String) is a built-in method of enum, where the String input is not the one was expected for the nameOf(String) method.  So nameOf() was used a lot in the SunJSSE provider implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7599