> * Gets the {@code subject} (subject distinguished name) value > * from the certificate. If the {@code subject} value is empty, > * then the {@code getName()} method of the returned > * {@code Principal} object returns an empty string (""). > * > *

See {@link #getIssuerDN() getIssuerDN} for {@code Name} > * and other relevant definitions. > * > * @return a Principal whose name is the subject name. > */ > public abstract Principal getSubjectDN(); > > Maybe the original writer meant "deprecated"? If so, maybe it's time to > deprecate the denigrated term here, and formally deprecate getSubjectDN? > > Kind regards, > Arjan Tijms > From arjan.tijms at gmail.com Fri Mar 5 15:17:58 2021 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 5 Mar 2021 16:17:58 +0100 Subject: X509Certificate#getSubjectDN, "denigrated"? In-Reply-To: References:

Message-ID: Hi, That looks good! I wanted to mention this for years, and when I finally do, you already fixed it :) Kind regards, Arjan On Fri, Mar 5, 2021 at 2:52 PM Sean Mullan wrote: > (Moving to security-dev and bcc-ing jdk-dev) > > This issue is fixed in JDK 16 [1], and the API is now deprecated [2], > along with several other related APIs that used that term. > > --Sean > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/145e1859a0a8 > [2] > > https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/security/cert/X509Certificate.html#getSubjectDN() > > On 3/5/21 8:37 AM, arjan tijms wrote: > > Hi, > > > > For some time now, X509Certificate#getSubjectDN is "denigrated": > > > > /** > > * Denigrated, replaced by {@linkplain > > * #getSubjectX500Principal()}. This method returns the {@code > subject} > > * as an implementation specific Principal object, which should not > be > > * relied upon by portable code. > > * > > *

> > * Gets the {@code subject} (subject distinguished name) value > > * from the certificate. If the {@code subject} value is empty, > > * then the {@code getName()} method of the returned > > * {@code Principal} object returns an empty string (""). > > * > > *

See {@link #getIssuerDN() getIssuerDN} for {@code Name} > > * and other relevant definitions. > > * > > * @return a Principal whose name is the subject name. > > */ > > public abstract Principal getSubjectDN(); > > > > Maybe the original writer meant "deprecated"? If so, maybe it's time to > > deprecate the denigrated term here, and formally deprecate getSubjectDN? > > > > Kind regards, > > Arjan Tijms > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aefimov at openjdk.java.net Fri Mar 5 16:03:07 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 5 Mar 2021 16:03:07 GMT Subject: RFR: 8262862: Harden tests sun/security/x509/URICertStore/ExtensionsWithLDAP.java and krb5/canonicalize/Test.java [v2] In-Reply-To: References:

Message-ID: On Thu, 4 Mar 2021 15:56:58 GMT, Fernando Guallini wrote: >> Certain JVM tools may access and initialise InetAddress class and its static fields during start up resulting in a NameService implementation being already set to the default **PlatformNameService**, causing intermittent failures in some tests that expect the use of **HostsFileNameService** instead by setting the system property jdk.net.hosts.file in the test main body, which has no effect in this scenario >> >> By setting the property **jdk.net.hosts.file** in the @run tag, there is certainty that it will be properly configured at the time that a [NameService](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L1155) is created > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > move set env properties to header The latest version looks good to me. Thanks. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/2809 From michaelm at openjdk.java.net Fri Mar 5 16:03:21 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 5 Mar 2021 16:03:21 GMT Subject: RFR: 8262862: Harden tests sun/security/x509/URICertStore/ExtensionsWithLDAP.java and krb5/canonicalize/Test.java [v2] In-Reply-To: References:

Message-ID: On Thu, 4 Mar 2021 15:56:58 GMT, Fernando Guallini wrote: >> Certain JVM tools may access and initialise InetAddress class and its static fields during start up resulting in a NameService implementation being already set to the default **PlatformNameService**, causing intermittent failures in some tests that expect the use of **HostsFileNameService** instead by setting the system property jdk.net.hosts.file in the test main body, which has no effect in this scenario >> >> By setting the property **jdk.net.hosts.file** in the @run tag, there is certainty that it will be properly configured at the time that a [NameService](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L1155) is created > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > move set env properties to header LGTM ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2809 From robm at openjdk.java.net Fri Mar 5 16:18:20 2021 From: robm at openjdk.java.net (Rob McKenna) Date: Fri, 5 Mar 2021 16:18:20 GMT Subject: RFR: 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" [v3] In-Reply-To: References:

Message-ID: On Thu, 4 Mar 2021 10:35:35 GMT, Daniel Fuchs wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8262438: Removed custom socket handling logic > > I don't see any specific issue with what you are proposing from a networking perspective, but you will need someone from security-libs to review the proposed changes and acknowledge that the test is still testing what it intends to test. The changes here don't affect the original fix given that the default impl of the client & server work for the purposes of the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/2749 From xuelei.fan at oracle.com Fri Mar 5 16:21:43 2021 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 5 Mar 2021 16:21:43 +0000 Subject: [External] : Re: TLS 1.3 Post-handshake authentication In-Reply-To: References:

Message-ID: Thanks for the detailed information. I have a better sense of the scenarios now. What about HTTP/2? Will the business logic or scenarios get changed for HTTP/2? Could the change apply to HTTP/1.1 as well? Xuelei On Mar 5, 2021, at 5:43 AM, arjan tijms > wrote: Hi, On Fri, Mar 5, 2021 at 2:05 AM Xue-Lei Fan > wrote: Does it mean that when switch to HTTP/2, the concern is not valid any longer? Or there is an alternative solution? Sorry for the questions, I know little about servlet. I'm trying to understand the requirement of this feature. Mark Thomas (Tomcat maintainer) recently explained this on the Servlet mailing list. I think it explains the requirement quite well, so I'll copy/paste it: "The sequence of events in the test is as follows: - Client connects. - TLS handshake, no client authentication. - Client sends request - Server parses it and maps it to a web application - Server compares request to security constraints - Security constraints require CLIENT-CERT - Request fails because server cannot trigger post-handshake authentication (Even if the server did support PHA, the client doesn't so it will fail there instead). My reading of the spec is that the ability to create per URL security constraints strongly implies that renegotiation / PHA needs to be supported. The existence of this test supports that view." The above is for HTTP/1.1, which is an important supported target of Servlet. Hope the above helps. Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjan.tijms at gmail.com Fri Mar 5 16:24:05 2021 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 5 Mar 2021 17:24:05 +0100 Subject: [External] : Re: TLS 1.3 Post-handshake authentication In-Reply-To: References:

Message-ID: Hi, On Fri, Mar 5, 2021 at 5:21 PM Xue-Lei Fan wrote: > Thanks for the detailed information. I have a better sense of the > scenarios now. What about HTTP/2? Will the business logic > or scenarios get changed for HTTP/2? Could the change apply to HTTP/1.1 as > well? > For HTTP/2 we'll have to specify something along the lines of the client-cert authentication mechanism not working at all, or working in a limited capacity (for the entire domain only). Unfortunately that (potential) change can not be applied to HTTP/1.1. Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: From fguallini at openjdk.java.net Fri Mar 5 16:29:06 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Fri, 5 Mar 2021 16:29:06 GMT Subject: Integrated: 8262862: Harden tests sun/security/x509/URICertStore/ExtensionsWithLDAP.java and krb5/canonicalize/Test.java In-Reply-To: References: Message-ID: <3nfb7ommPpEwdDLP4GmEDdS7F6B3A0ALVy4-C_dcriQ=.a9c5c6d3-0452-42e3-8780-85368871a80c@github.com> On Wed, 3 Mar 2021 12:23:00 GMT, Fernando Guallini wrote: > Certain JVM tools may access and initialise InetAddress class and its static fields during start up resulting in a NameService implementation being already set to the default **PlatformNameService**, causing intermittent failures in some tests that expect the use of **HostsFileNameService** instead by setting the system property jdk.net.hosts.file in the test main body, which has no effect in this scenario > > By setting the property **jdk.net.hosts.file** in the @run tag, there is certainty that it will be properly configured at the time that a [NameService](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L1155) is created This pull request has now been integrated. Changeset: e1cad970 Author: Fernando Guallini Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/e1cad970 Stats: 32 lines in 2 files changed: 7 ins; 20 del; 5 mod 8262862: Harden tests sun/security/x509/URICertStore/ExtensionsWithLDAP.java and krb5/canonicalize/Test.java Reviewed-by: aefimov, michaelm ------------- PR: https://git.openjdk.java.net/jdk/pull/2809 From github.com+30433125+djelinski at openjdk.java.net Fri Mar 5 16:47:06 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Fri, 5 Mar 2021 16:47:06 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v2] In-Reply-To: <66glPmvqcGuafhMIJXikBQzzaCp1-N3OGY8-hoypaUA=.7e49e138-8487-4700-806d-f9c2e80bfa7b@github.com> References:

<7UitLU6-vNGevKBUaBQZeCaEwS4eeg_SqB6dcsdAHnI=.828b3259-5dfb-4b7a-a6a7-3c4a00091915@github.com> <8Y_cdQ9z_7l6Ww0IN307bzUOq-trMRukZUlbzHRQvwk=.ef500b03-65a3-4feb-9ee8-fb363cce269b@github.com> <8BfIQquV5y8Zs2UBm9PVsaTLjPID8cPIwKwu_ThFUkY=.b040b0d9-c683-46ec-9235-0c1320b6ad4d@github.com>

<66glPmvqcGuafhMIJXikBQzzaCp1-N3OGY8-hoypaUA=.7e49e138-8487-4700-806d-f9c2e80bfa7b@github.com> Message-ID: <3pazdVsOeFjaWlqKdNlx9Ucy8zYI2g-N7cXiUsgUr3M=.848dc21f-0188-4c3f-b48c-c64d63fda404@github.com> On Mon, 22 Feb 2021 21:31:21 GMT, Xue-Lei Andrew Fan wrote: >> Actually there's a much easier solution to reduce the number of slow `put()`s without making any behavioral changes. >> The cache object could store the earliest expire time, and then exit `expungeExpiredEntries()` early when current time is earlier than the earliest expire time - when it is, we know that there are no expired items in the queue and we can skip the scan entirely. >> @XueleiFan do you think the above is worth exploring? > >> Actually there's a much easier solution to reduce the number of slow `put()`s without making any behavioral changes. >> The cache object could store the earliest expire time, and then exit `expungeExpiredEntries()` early when current time is earlier than the earliest expire time - when it is, we know that there are no expired items in the queue and we can skip the scan entirely. >> @XueleiFan do you think the above is worth exploring? > > Definitely, I think it is a good improvement. Actually, it is a surprise to me that the current code is not working this way. > > Sorry, I was/am on vacation, and the review could be delayed for a few days. ping @XueleiFan, I'd appreciate another review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2255 From rrich at openjdk.java.net Fri Mar 5 17:28:24 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 5 Mar 2021 17:28:24 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References:

<2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>

Message-ID: On Fri, 5 Mar 2021 11:11:44 GMT, Alan Hayward wrote: >>> I was building this PR on a new machine, and I now get the following error: >>> >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIClientRef client = (MIDIClientRef) NULL; >>> > ^~~~~~~~~~~~~~~~~~~~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIPortRef inPort = (MIDIPortRef) NULL; >>> > ^~~~~~~~~~~~~~~~~~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIPortRef outPort = (MIDIPortRef) NULL; >>> > ^~~~~~~~~~~~~~~~~~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL; >>> > ^~~~~~~~~~~~~~~~~~~~~~ >>> > 4 errors generated. >>> >>> As far as I can tell the only difference between the two systems is the xcode version: >>> >>> New system (failing) >>> % xcodebuild -version >>> Xcode 12.5 >>> Build version 12E5244e >>> >>> Old system (working) >>> % xcodebuild -version >>> Xcode 12.4 >>> Build version 12D4e >>> >>> Looks like the newer version of Xcode is being a little stricter with casting? >>> Replacing the NULL with 0 seems to fix the issue. >> >> Hello >> there is one issue with the info you provided, it's from Xcode12.5 beta. >> And beta license agreement forbids sharing output of beta version of compiler&co >> So we can't say we have issue with newer xcode beta until that beta went public & released. >> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public. > >> Hello >> there is one issue with the info you provided, it's from Xcode12.5 beta. >> And beta license agreement forbids sharing output of beta version of compiler&co >> So we can't say we have issue with newer xcode beta until that beta went public & released. >> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public. > > Ok, I wasn't aware of that. I'll downgrade back to the non-beta version. Hi, @VladimirKempik reported failure of CompressedClassPointers.largeHeapAbove32GTest() with [JDK-8262895](https://bugs.openjdk.java.net/browse/JDK-8262895) on macos_aarch64. He also helped analyzing the issue (thanks!). Apparently the vm has difficulties mapping the heap of 31GB at one of the preferred addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477). This causes the test failure indirectly. IMO it could be worth the effort to find out why the heap cannot be mapped at the preferred addresses. Reviewers should decide on it. I wouldn't be able to do it myself though as I don't have access to a macos_aarch64 system. Alternatively I'd suggest to exlude macos_aarch64 from the subtest largeHeapAbove32GTest. Best regards, Richard. -- #### Details of the analysis In the following trace we see the vm trying to allocate the heap at addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477) without success: images/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -Xmx31g -XX:-UseAOT -Xlog:gc+metaspace=trace,cds=trace,heap+gc+exit=info,gc+heap+coops=trace -Xshare:off -XX:+VerifyBeforeGC -XX:HeapSearchSteps=40 -version OpenJDK 64-Bit Server VM warning: Shared spaces are not supported in this VM [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001800000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000002000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000004000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000005000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0008000000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0010000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0018000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0020000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0080000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0100000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0110000000000000 heap of size 0x7c1000000 Finally it gives up and lets the os chose the address: [0.006s][trace][gc,heap,coops] Trying to allocate at address NULL heap of size 0x7c1000000 [0.006s][debug][gc,heap,coops] Protected page at the reserved heap base: 0x0000000280000000 / 16777216 bytes [0.006s][debug][gc,heap,coops] Heap address: 0x0000000281000000, size: 31744 MB, Compressed Oops mode: Non-zero based: 0x0000000280000000, Oop shift amount: 3 The os chooses to map the heap at 0x0000000281000000 that is at 10GB. This leaves not much room for a 4GB (*) aligned compressed class space below 32G for a zero based encoding. And indeed we get a compressed class space with an encoding base that is not zero and largeHeapAbove32GTest fails then [0.007s][info ][gc,metaspace ] Compressed class space mapped at: 0x0000007000000000-0x0000007040000000, reserved size: 1073741824 [0.007s][info ][gc,metaspace ] Narrow klass base: 0x0000007000000000, Narrow klass shift: 0, Narrow klass range: 0x40000000 On macos 10.15 (x86_64) the vm succeeds first try mapping the heap at address 0x0000001000000000. (*) On aarch64 the encoding base has to be 4GB aligned. Unfortunately the 4GB alignment is enforced to strictly on the start address of the compressed class space instead of enforcing it on the encoding base. See [JDK-8258756](https://bugs.openjdk.java.net/browse/JDK-8258756) ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From xuelei at openjdk.java.net Sat Mar 6 04:38:07 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 6 Mar 2021 04:38:07 GMT Subject: RFR: 8259886 : Improve SSL session cache performance and scalability [v5] In-Reply-To: References:

Message-ID: On Tue, 2 Mar 2021 21:00:04 GMT, djelinski wrote: >> Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity. >> >> First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`. >> Baseline results before any MemoryCache changes: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op >> CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op >> CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op >> CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op >> there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly. >> >> Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op >> CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op >> CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op >> CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op >> The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache. >> >> The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit: >> Benchmark (size) (timeout) Mode Cnt Score Error Units >> CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op >> CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op >> CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op >> CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op >> I wasn't expecting that much of an improvement, and don't know how to explain it. >> >> The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM. > > djelinski has updated the pull request incrementally with two additional commits since the last revision: > > - Avoid unproductive cache scans > - Revert Cache changes I would also update the copyright year to 2021. Otherwise, looks good to me. Thank you! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2255 From valeriep at openjdk.java.net Sat Mar 6 07:47:06 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Sat, 6 Mar 2021 07:47:06 GMT Subject: RFR: 8261462: GCM ByteBuffer decryption problems [v2] In-Reply-To: References:

Message-ID: <202b3tIt5DuIN3vIMCloQ8x8JMl25WrDCAt8jcwDG6w=.0ac986a4-0609-4981-a964-2dd1d1371376@github.com> On Sat, 13 Feb 2021 03:05:02 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of these two simple fixes. One just sets the input bytebuffer position to the limit upon completion of decryption. The second calls the CipherCore method to clear the state from the previous operation. >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > add gcmincrementdirect4 fix Changes look good. Only nit is the copyright year of the 2 source files should be updated. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2487 From alanb at openjdk.java.net Sat Mar 6 09:38:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 6 Mar 2021 09:38:08 GMT Subject: RFR: JDK-8263104: fix warnings for empty paragraphs In-Reply-To: References: Message-ID: <6pQuxdYXIeFdsAmjJLMiZgy5pKDxynzkTBjnYSr4SJw=.ff8af313-9adb-426a-89ce-65c16a8317c9@github.com> On Fri, 5 Mar 2021 19:36:13 GMT, Jonathan Gibbons wrote: > Please review some simple cleanup for empty `

` tags. > > Two of the tags are completely redundant, and simply deleted. > > The other three, in _package.html_ files are generally undesirable. Although the presumed intent of the `id` declaration is to label the `@see` info, proximity in the source code does not ensure proximity in the generated code. The actual result is an empty paragraph at the end of the enclosing generated `

`, and before the generated output for the `@since` tag. > > The better solution is to move the `id` declaration into the `@see `. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2850 From jjg at openjdk.java.net Sat Mar 6 15:10:07 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 6 Mar 2021 15:10:07 GMT Subject: Integrated: JDK-8263104: fix warnings for empty paragraphs In-Reply-To: References: Message-ID: <6FoMt0zfqvGcDldeeG44yeunGbakXCHgPLIjgzIfvZM=.4f9824c3-4576-4fe8-b816-b5f4ce4534f6@github.com> On Fri, 5 Mar 2021 19:36:13 GMT, Jonathan Gibbons wrote: > Please review some simple cleanup for empty `

<6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>

Message-ID: <_myKg9agXkEdf29bRLeluZk3-F9DdQg_oUOjp3-e8co=.c2aef251-5e62-4a8e-b01d-b7d05e0e3fd9@github.com> On Fri, 5 Mar 2021 16:15:42 GMT, Rob McKenna wrote: >> I don't see any specific issue with what you are proposing from a networking perspective, but you will need someone from security-libs to review the proposed changes and acknowledge that the test is still testing what it intends to test. > > The changes here don't affect the original fix given that the default impl of the client & server work for the purposes of the test. Can you please confirm that you saw all protocols ("TLSv1", "TLSv1.1", "TLSv1.2", "TLSv1.3") negotiated with updated test run? ------------- PR: https://git.openjdk.java.net/jdk/pull/2749 From ascarpino at openjdk.java.net Mon Mar 8 20:28:27 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 8 Mar 2021 20:28:27 GMT Subject: RFR: 8261462: GCM ByteBuffer decryption problems [v3] In-Reply-To: References: Message-ID: > Hi, > > I need a review of these two simple fixes. One just sets the input bytebuffer position to the limit upon completion of decryption. The second calls the CipherCore method to clear the state from the previous operation. > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: copyright update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2487/files - new: https://git.openjdk.java.net/jdk/pull/2487/files/b9aa4914..f1182148 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2487&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2487&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2487.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2487/head:pull/2487 PR: https://git.openjdk.java.net/jdk/pull/2487 From ascarpino at openjdk.java.net Mon Mar 8 20:28:28 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 8 Mar 2021 20:28:28 GMT Subject: RFR: 8261462: GCM ByteBuffer decryption problems [v2] In-Reply-To: <202b3tIt5DuIN3vIMCloQ8x8JMl25WrDCAt8jcwDG6w=.0ac986a4-0609-4981-a964-2dd1d1371376@github.com> References:

<202b3tIt5DuIN3vIMCloQ8x8JMl25WrDCAt8jcwDG6w=.0ac986a4-0609-4981-a964-2dd1d1371376@github.com> Message-ID: On Sat, 6 Mar 2021 07:44:04 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> add gcmincrementdirect4 fix > > Changes look good. Only nit is the copyright year of the 2 source files should be updated. Wow.. I'm surprised those copyrights weren't change. Thanks for the review ------------- PR: https://git.openjdk.java.net/jdk/pull/2487 From redestad at openjdk.java.net Mon Mar 8 20:39:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 8 Mar 2021 20:39:08 GMT Subject: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2879 From ascarpino at openjdk.java.net Mon Mar 8 21:31:10 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 8 Mar 2021 21:31:10 GMT Subject: Integrated: 8261462: GCM ByteBuffer decryption problems In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 19:54:43 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of these two simple fixes. One just sets the input bytebuffer position to the limit upon completion of decryption. The second calls the CipherCore method to clear the state from the previous operation. > > Thanks > > Tony This pull request has now been integrated. Changeset: 414ee95b Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/414ee95b Stats: 158 lines in 4 files changed: 153 ins; 0 del; 5 mod 8261462: GCM ByteBuffer decryption problems Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/2487 From jjiang at openjdk.java.net Mon Mar 8 22:39:26 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Mon, 8 Mar 2021 22:39:26 GMT Subject: RFR: JDK-8263188: JSSE should fail fast if there isn't supported signature algorithm Message-ID: If signature_algorithms extension is present, but the algorithms are unreconginzed or unsupported, JSSE peers should send fatal alert immediately. For example, in this case, it's unnecssary to try to produce ServerHello, Certificate and ServerKeyExchange messages. ------------- Commit messages: - JDK-8263188: JSSE should fail fast if there isn't supported signature algorithm Changes: https://git.openjdk.java.net/jdk/pull/2876/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2876&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263188 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2876/head:pull/2876 PR: https://git.openjdk.java.net/jdk/pull/2876 From jjg at openjdk.java.net Tue Mar 9 00:15:18 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 9 Mar 2021 00:15:18 GMT Subject: RFR: 8263105: security-libs doclint cleanup In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: <24gnlaRnK6HCVyWRR9rnjw4EQUbakQ3jZirWKBro4Vk=.a4e4b32d-ff12-4560-ab0a-608736d2e7dc@github.com> On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore wrote: > Fix various things pointed out by the most recent doclint run in the security-libs area. > > This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. I've read the first 10 files. The edits are definitely in the right direction, and will address the "missing comments" issues. I'll leave it up to you and the others in your team to decide what level of stylistic consistency you would like for the new comments, but just having a relevant comment at all is a great start. src/java.base/share/classes/java/security/BasicPermission.java line 497: > 495: /** > 496: * @serialData Default fields. > 497: */ FWIW, this doc comment will be ignored, because it will be superseded by the new comment on line 499. At some point doen the road, you may get a warning from javac about an ignored doc comment. src/java.base/share/classes/java/security/GuardedObject.java line 64: > 62: > 63: /** > 64: * The guard object add a period? src/java.base/share/classes/java/security/PermissionCollection.java line 105: > 103: * Whether this permission collection is read-only. > 104: *

> 105: * If set, add() will throw an exception. maybe use `{@code}` or `{@link}` on add? src/java.base/share/classes/java/security/Permissions.java line 581: > 579: /** > 580: * @serialData Default fields. > 581: */ Another ignored comment. I suggest just changing these to `/*` comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Tue Mar 9 00:15:17 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 9 Mar 2021 00:15:17 GMT Subject: RFR: 8263105: security-libs doclint cleanup Message-ID: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Fix various things pointed out by the most recent doclint run in the security-libs area. This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. ------------- Commit messages: - Final First Draft - Only 100 warnings output by default - 8263105: security-libs doclint cleanup Changes: https://git.openjdk.java.net/jdk/pull/2856/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263105 Stats: 351 lines in 39 files changed: 270 ins; 2 del; 79 mod Patch: https://git.openjdk.java.net/jdk/pull/2856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856 PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Tue Mar 9 00:15:20 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 9 Mar 2021 00:15:20 GMT Subject: RFR: 8263105: security-libs doclint cleanup In-Reply-To: <24gnlaRnK6HCVyWRR9rnjw4EQUbakQ3jZirWKBro4Vk=.a4e4b32d-ff12-4560-ab0a-608736d2e7dc@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> <24gnlaRnK6HCVyWRR9rnjw4EQUbakQ3jZirWKBro4Vk=.a4e4b32d-ff12-4560-ab0a-608736d2e7dc@github.com> Message-ID: <7J0SCUfBXhQs33Dm0ALYoOE-N3g8uJn93_reCgbebPg=.15fa4742-58d0-44cf-a113-0df0e25b7663@github.com> On Sat, 6 Mar 2021 19:20:39 GMT, Jonathan Gibbons wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > src/java.base/share/classes/java/security/BasicPermission.java line 497: > >> 495: /** >> 496: * @serialData Default fields. >> 497: */ > > FWIW, this doc comment will be ignored, because it will be superseded by the new comment on line 499. At some point doen the road, you may get a warning from javac about an ignored doc comment. Ok > src/java.base/share/classes/java/security/GuardedObject.java line 64: > >> 62: >> 63: /** >> 64: * The guard object > > add a period? Probably worth doing as it's the first sentence. > src/java.base/share/classes/java/security/PermissionCollection.java line 105: > >> 103: * Whether this permission collection is read-only. >> 104: *

>> 105: * If set, add() will throw an exception. > > maybe use `{@code}` or `{@link}` on add? Done. > src/java.base/share/classes/java/security/Permissions.java line 581: > >> 579: /** >> 580: * @serialData Default fields. >> 581: */ > > Another ignored comment. I suggest just changing these to `/*` comments. Good idea. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From iris at openjdk.java.net Tue Mar 9 00:49:08 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 9 Mar 2021 00:49:08 GMT Subject: RFR: 8263105: security-libs doclint cleanup In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore wrote: > Fix various things pointed out by the most recent doclint run in the security-libs area. > > This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. I'm happy to see a reduction in the number of warnings. I suspect there are a few places where Object{In,Out}putStream is fully qualified when it's not strictly necessary; however, since this is in pre-existing code, I don't think this needs to be changed now. src/java.base/share/classes/java/security/KeyPair.java line 53: > 51: > 52: /** > 53: * Extra line? ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Tue Mar 9 00:56:25 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 9 Mar 2021 00:56:25 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v2] In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: > Fix various things pointed out by the most recent doclint run in the security-libs area. > > This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Codereview Comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2856/files - new: https://git.openjdk.java.net/jdk/pull/2856/files/f2253d91..1fa29ea6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856 PR: https://git.openjdk.java.net/jdk/pull/2856 From darcy at openjdk.java.net Tue Mar 9 01:21:07 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 9 Mar 2021 01:21:07 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v2] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Codereview Comment Looks fine. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2856 From ewhelan at openjdk.java.net Tue Mar 9 09:24:06 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 9 Mar 2021 09:24:06 GMT Subject: RFR: 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" [v3] In-Reply-To: <_myKg9agXkEdf29bRLeluZk3-F9DdQg_oUOjp3-e8co=.c2aef251-5e62-4a8e-b01d-b7d05e0e3fd9@github.com> References: <_myKg9agXkEdf29bRLeluZk3-F9DdQg_oUOjp3-e8co=.c2aef251-5e62-4a8e-b01d-b7d05e0e3fd9@github.com> Message-ID: On Mon, 8 Mar 2021 19:25:09 GMT, Rajan Halade wrote: >> The changes here don't affect the original fix given that the default impl of the client & server work for the purposes of the test. > > Can you please confirm that you saw all protocols ("TLSv1", "TLSv1.1", "TLSv1.2", "TLSv1.3") negotiated with updated test run? Yes, the updated test run successfully tested with all of the protocols listed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2749 From dfuchs at openjdk.java.net Tue Mar 9 10:15:07 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 9 Mar 2021 10:15:07 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v2] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Codereview Comment I have recently gone through a similar exercise with `java.net`: what you have here looks good to me! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2856 From pconcannon at openjdk.java.net Tue Mar 9 11:12:10 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 9 Mar 2021 11:12:10 GMT Subject: Integrated: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick This pull request has now been integrated. Changeset: 0f2402d0 Author: Patrick Concannon URL: https://git.openjdk.java.net/jdk/commit/0f2402d0 Stats: 59 lines in 15 files changed: 0 ins; 27 del; 32 mod 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable Reviewed-by: lancea, bpb, darcy, naoto, iris, dfuchs, smarks, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/2879 From mullan at openjdk.java.net Tue Mar 9 16:10:17 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 9 Mar 2021 16:10:17 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v2] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Codereview Comment src/java.base/share/classes/java/security/CodeSigner.java line 170: > 168: /** > 169: * Restores the state of this object from the stream, and explicitly > 170: * reset hash code value to -1. Change "reset" to "resets". src/java.base/share/classes/java/security/Timestamp.java line 160: > 158: /** > 159: * Restores the state of this object from the stream, and explicitly > 160: * reset hash code value to -1 s/reset/resets, and add period at end of sentence. src/java.base/share/classes/java/security/cert/Certificate.java line 71: > 69: private final String type; > 70: > 71: /** Cache the hash code for the certiticate. */ I would drop the word "Cache". Also typo: s/certiticate/certificate. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From akozlov at openjdk.java.net Tue Mar 9 16:12:36 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 9 Mar 2021 16:12:36 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits: - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos - workaround JDK-8262895 by disabling subtest - Fix typo - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp - JDK-8259937: bsd_aarch64 part - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Fix after JDK-8259539, partially revert preconditions - JDK-8260471: bsd_aarch64 part - JDK-8259539: bsd_aarch64 part - JDK-8257828: bsd_aarch64 part - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=23 Stats: 2873 lines in 73 files changed: 2787 ins; 27 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Mar 9 16:12:37 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 9 Mar 2021 16:12:37 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> References: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> Message-ID: On Tue, 9 Feb 2021 09:06:26 GMT, Stefan Karlsson wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update signal handler part for debugger > > src/hotspot/share/runtime/threadWXSetters.hpp line 28: > >> 26: #define SHARE_RUNTIME_THREADWXSETTERS_HPP >> 27: >> 28: #include "runtime/thread.inline.hpp" > > This breaks against our convention to forbid inline.hpp files from being included from being included from .hpp files. You need to rework this by either moving the implementation to a .cpp file, or convert this file into an .inline.hpp > > See the Source Files section in: > https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html Thanks, I renamed the file to threadWXSetters.inline.hpp ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From wetmore at openjdk.java.net Tue Mar 9 16:29:10 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 9 Mar 2021 16:29:10 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v2] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: <84xf3jGiaFYFF4FKellEHL4XypTHf8fEB-xjWLJ4q44=.a5b07185-6c1e-44d1-8239-3123a6eb490c@github.com> On Tue, 9 Mar 2021 16:10:11 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Codereview Comment > > src/java.base/share/classes/javax/crypto/SealedObject.java line 428: > >> 426: * @throws IOException if an I/O error occurs >> 427: * @throws ClassNotFoundException if a serialized class cannot be loaded >> 428: * @throws NullPointerException if s is null. > > Remove period for consistency with other throws. Actually, you probably don't need to say that it throws NPE. I don't see that any other readObject method declares that, even if they do throw NPE if the stream is null. Seems like something that should just be assumed or does not happen under normal circumstances. It did seem really strange to me. I'll remove. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From mullan at openjdk.java.net Tue Mar 9 16:29:09 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 9 Mar 2021 16:29:09 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v2] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Codereview Comment src/java.base/share/classes/javax/crypto/SealedObject.java line 428: > 426: * @throws IOException if an I/O error occurs > 427: * @throws ClassNotFoundException if a serialized class cannot be loaded > 428: * @throws NullPointerException if s is null. Remove period for consistency with other throws. Actually, you probably don't need to say that it throws NPE. I don't see that any other readObject method declares that, even if they do throw NPE if the stream is null. Seems like something that should just be assumed or does not happen under normal circumstances. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From akozlov at openjdk.java.net Tue Mar 9 16:58:19 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 9 Mar 2021 16:58:19 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> References: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> Message-ID: On Tue, 9 Feb 2021 09:12:13 GMT, Stefan Karlsson wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update signal handler part for debugger > > src/hotspot/share/runtime/thread.hpp line 848: > >> 846: void init_wx(); >> 847: WXMode enable_wx(WXMode new_state); >> 848: #endif // __APPLE__ && AARCH64 > > Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions. The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From rhalade at openjdk.java.net Tue Mar 9 17:51:07 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 9 Mar 2021 17:51:07 GMT Subject: RFR: 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" [v3] In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 09:47:03 GMT, Evan Whelan wrote: >> Hi all, >> >> Please review my test fix relating to JDK-8262438 >> >> This patch introduces as Thread.sleep at the start of each iteration which creates a new test jvm. >> This allows the server socket sufficient time to release the previous connection and allows the port to be used again. >> >> I also refactored the behaviour for when the exitCode is not 0, allowing for an easier to read output. >> An incorrect HttpsUrlConnection.disconnect() was also removed. >> >> The test was ran 100 times on all platforms and no failures were seen. >> >> Thanks, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8262438: Removed custom socket handling logic Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2749 From akozlov at openjdk.java.net Tue Mar 9 17:58:21 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 9 Mar 2021 17:58:21 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> References: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> Message-ID: On Tue, 9 Feb 2021 09:23:50 GMT, Stefan Karlsson wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update signal handler part for debugger > > src/hotspot/share/runtime/thread.cpp line 2515: > >> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) { >> 2514: // Enable WXWrite: called directly from interpreter native wrapper. >> 2515: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread)); > > FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version: > ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) { > MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {} > void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp) > With that said, I'm fine with taking this discussion as a follow-up. The former version used no such macros. I like that now it's clear the W^X management is relevant to macos/aarch64 only. I see the point to move the pre-processor condition into the class implementation. But I think it will bring a bit of inconsistency, as the rest of W^X implementation is explicitly guarded by preprocessor conditionals. I've also tried to push macro conditionals as far as possible down to implementation, providing a kind of generalized W^X interface. That required a few artificial decisions, e.g. how would we call the mode we execute on the rest of platforms with write and execute allowed, WXWriteExec?.. I abandoned that attempt. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Mar 9 18:04:19 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 9 Mar 2021 18:04:19 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21] In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 10:31:19 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Minor fixes > > src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62: > >> 60: >> 61: #if defined(__APPLE__) || defined(_WIN64) >> 62: #define R18_RESERVED > > #define R18_RESERVED true``` We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From wetmore at openjdk.java.net Tue Mar 9 22:19:28 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 9 Mar 2021 22:19:28 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v3] In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: > Fix various things pointed out by the most recent doclint run in the security-libs area. > > This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: More Codereview Comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2856/files - new: https://git.openjdk.java.net/jdk/pull/2856/files/1fa29ea6..ed0cf2ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=01-02 Stats: 52 lines in 8 files changed: 0 ins; 42 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856 PR: https://git.openjdk.java.net/jdk/pull/2856 From djelinski1 at gmail.com Tue Mar 9 23:36:47 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 10 Mar 2021 00:36:47 +0100 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: Hi, Please review this 11u backport; this is the same patch as for head, except for microbenchmark makefile changes that did not apply because the file doesn't exist in 11u, and the actual microbenchmark, which would only add weight for no benefit. Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 webrev: https://djelinski.github.io/8259886-11u/webrev/index.html Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel From mbaesken at openjdk.java.net Wed Mar 10 15:04:13 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 10 Mar 2021 15:04:13 GMT Subject: RFR: 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 08:38:54 GMT, Christoph Langer wrote: > Exclude some failing tests from security/infra/java/security/cert/CertPathValidator Looks good, thanks! ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2840 From rriggs at openjdk.java.net Wed Mar 10 15:16:12 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 10 Mar 2021 15:16:12 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v3] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: <3D9QxdihO80TU6b0jEw_0oSaixV9zLDehI-weuDVy2U=.4b4c4b52-6b5f-4425-97b1-c5ab87f8dd0e@github.com> On Tue, 9 Mar 2021 22:19:28 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > More Codereview Comments src/java.base/share/classes/java/security/AllPermission.java line 165: > 163: > 164: /** > 165: * true if any AllPermissions have been added Please capitalize to make it a sentence, and end in ".". src/java.base/share/classes/java/security/BasicPermission.java line 261: > 259: > 260: /** > 261: * readObject is called to restore the state of the BasicPermission from Please capitalize... The readObject method... src/java.base/share/classes/java/security/BasicPermission.java line 526: > 524: > 525: /** > 526: * readObject is called to restore the state of the Ditto, capitalize. src/java.base/share/classes/java/security/Permissions.java line 579: > 577: }; > 578: > 579: /* The @ serialData comment can be removed entirely. It is unused due to the "@serial exclude" above. src/java.base/share/classes/java/security/UnresolvedPermissionCollection.java line 158: > 156: > 157: /* > 158: * @serialData Default field. the comment block containing @\serialdata can be omitted entirely. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From rriggs at openjdk.java.net Wed Mar 10 15:16:14 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 10 Mar 2021 15:16:14 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v2] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: <1HxROk2UKTV_3Tqvor1JZDSRzNggXntkrXV61pXA0-4=.d0823cf0-9dc6-4eb2-ba8b-32cfd38834b3@github.com> On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Codereview Comment src/java.base/share/classes/javax/crypto/SealedObject.java line 425: > 423: * Restores the state of the SealedObject from a stream. > 424: * > 425: * @param s the object input stream. Covert to @\throws but keep this declaration. There is no spec that otherwise covers this and it is consistent with other methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From ewhelan at openjdk.java.net Wed Mar 10 15:19:09 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 10 Mar 2021 15:19:09 GMT Subject: Integrated: 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 14:28:23 GMT, Evan Whelan wrote: > Hi all, > > Please review my test fix relating to JDK-8262438 > > This patch introduces as Thread.sleep at the start of each iteration which creates a new test jvm. > This allows the server socket sufficient time to release the previous connection and allows the port to be used again. > > I also refactored the behaviour for when the exitCode is not 0, allowing for an easier to read output. > An incorrect HttpsUrlConnection.disconnect() was also removed. > > The test was ran 100 times on all platforms and no failures were seen. > > Thanks, > Evan This pull request has now been integrated. Changeset: b2a2ddff Author: Evan Whelan Committer: Rob McKenna URL: https://git.openjdk.java.net/jdk/commit/b2a2ddff Stats: 68 lines in 1 file changed: 6 ins; 61 del; 1 mod 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" Reviewed-by: rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/2749 From iris at openjdk.java.net Wed Mar 10 18:51:08 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 10 Mar 2021 18:51:08 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v3] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: On Tue, 9 Mar 2021 22:19:28 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > More Codereview Comments Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From mullan at openjdk.java.net Wed Mar 10 19:12:09 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 10 Mar 2021 19:12:09 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v3] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: On Tue, 9 Mar 2021 22:19:28 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > More Codereview Comments Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/java/security/PrivilegedActionException.java line 101: > 99: * Serializable fields for UndeclaredThrowableException. > 100: * > 101: * @serialField exception Exception the undeclaredThrowable The "undeclaredThrowable" is confusing and not defined anywhere in this class specification. Suggest changing this to: The exception thrown by the privileged computation that resulted in this {@code PrivilegedActionException}. src/java.base/share/classes/java/security/PrivilegedActionException.java line 99: > 97: > 98: /** > 99: * Serializable fields for UndeclaredThrowableException. The "UndeclaredThrowableException" is confusing and not defined anywhere in this class specification. Suggest changing this to: Serializable fields for this {@code PrivilegedActionException}. src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java line 183: > 181: * @serialData this {@code KeyImpl} is serialized by > 182: * writing out the ASN1 Encoded bytes of the encryption key. > 183: * The ASN1 encoding is defined in RFC4120 and as follows: Nit: s/ASN1/ASN.1 (also on line 182). src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java line 183: > 181: * @serialData this {@code KeyImpl} is serialized by > 182: * writing out the ASN1 Encoded bytes of the encryption key. > 183: * The ASN1 encoding is defined in RFC4120 and as follows: Remove "and" and extra space after "as" ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Wed Mar 10 22:54:11 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 10 Mar 2021 22:54:11 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v3] In-Reply-To: <3D9QxdihO80TU6b0jEw_0oSaixV9zLDehI-weuDVy2U=.4b4c4b52-6b5f-4425-97b1-c5ab87f8dd0e@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> <3D9QxdihO80TU6b0jEw_0oSaixV9zLDehI-weuDVy2U=.4b4c4b52-6b5f-4425-97b1-c5ab87f8dd0e@github.com> Message-ID: On Wed, 10 Mar 2021 14:53:53 GMT, Roger Riggs wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> More Codereview Comments > > src/java.base/share/classes/java/security/AllPermission.java line 165: > >> 163: >> 164: /** >> 165: * true if any AllPermissions have been added > > Please capitalize to make it a sentence, and end in ".". Done. > src/java.base/share/classes/java/security/BasicPermission.java line 526: > >> 524: >> 525: /** >> 526: * readObject is called to restore the state of the > > Ditto, capitalize. It's the name of the method and the style is used in other packages. Leaving as is. > src/java.base/share/classes/java/security/Permissions.java line 579: > >> 577: }; >> 578: >> 579: /* > > The @ serialData comment can be removed entirely. It is unused due to the "@serial exclude" above. Ok. > src/java.base/share/classes/java/security/UnresolvedPermissionCollection.java line 158: > >> 156: >> 157: /* >> 158: * @serialData Default field. > > the comment block containing @\serialdata can be omitted entirely. ok ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Wed Mar 10 23:04:10 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 10 Mar 2021 23:04:10 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v2] In-Reply-To: <1HxROk2UKTV_3Tqvor1JZDSRzNggXntkrXV61pXA0-4=.d0823cf0-9dc6-4eb2-ba8b-32cfd38834b3@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> <1HxROk2UKTV_3Tqvor1JZDSRzNggXntkrXV61pXA0-4=.d0823cf0-9dc6-4eb2-ba8b-32cfd38834b3@github.com> Message-ID: On Wed, 10 Mar 2021 15:10:35 GMT, Roger Riggs wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Codereview Comment > > src/java.base/share/classes/javax/crypto/SealedObject.java line 425: > >> 423: * Restores the state of the SealedObject from a stream. >> 424: * >> 425: * @param s the object input stream. > > Covert to @\throws but keep this declaration. There is no spec that otherwise covers this and it is consistent with other methods. Ok, I'll keep the NullPointerException and change to @throws, although I don't think it's used in many methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Wed Mar 10 23:12:11 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 10 Mar 2021 23:12:11 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v3] In-Reply-To: References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: <0gleVXDrxNu-VoK8ZCNPi3CU5mqR9fo86X7WtPg3rlc=.b3f279a8-d3dc-4d32-a423-944628386150@github.com> On Wed, 10 Mar 2021 19:02:40 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> More Codereview Comments > > src/java.base/share/classes/java/security/PrivilegedActionException.java line 101: > >> 99: * Serializable fields for UndeclaredThrowableException. >> 100: * >> 101: * @serialField exception Exception the undeclaredThrowable > > The "undeclaredThrowable" is confusing and not defined anywhere in this class specification. Suggest changing this to: > > The exception thrown by the privileged computation that resulted in this {@code PrivilegedActionException}. Sure, good idea. Thanks. > src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java line 183: > >> 181: * @serialData this {@code KeyImpl} is serialized by >> 182: * writing out the ASN1 Encoded bytes of the encryption key. >> 183: * The ASN1 encoding is defined in RFC4120 and as follows: > > Nit: s/ASN1/ASN.1 (also on line 182). Corrected. > src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java line 183: > >> 181: * @serialData this {@code KeyImpl} is serialized by >> 182: * writing out the ASN1 Encoded bytes of the encryption key. >> 183: * The ASN1 encoding is defined in RFC4120 and as follows: > > Remove "and" and extra space after "as" Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From weijun at openjdk.java.net Thu Mar 11 00:06:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 11 Mar 2021 00:06:50 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v8] In-Reply-To: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> Message-ID: > This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario 2.2.0. > > The first step is an auto-import. The JDK implementation is removed first and Santuario code are imported. Some unrelated files (Ex: encryption) are removed, and package names are renamed to be internal. There are also some bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last import. Some are new. > > Several tests need to be updated because of internal method signature changes. Weijun Wang 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 15 additional commits since the last revision: - Merge branch 'master' into 8255255 - reapply 8259535: ECDSA SignatureValue do not always have the specified length - No more newInstance calls - Reapply 8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() - Fix test failures - Supporting named RSASSA-PSS without parameters - Reapply 8008744: Rework part of fix for JDK-6741606 - Reapply 8151893: Add security property to configure XML Signature secure validation mode Reapply 8140353: Improve signature checking - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes - Reapply 8038913: Bolster XML support (Init.java part) - ... and 5 more: https://git.openjdk.java.net/jdk/compare/ce7eb475...60496847 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1206/files - new: https://git.openjdk.java.net/jdk/pull/1206/files/24fb59fe..60496847 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1206&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1206&range=06-07 Stats: 6713 lines in 254 files changed: 2727 ins; 2527 del; 1459 mod Patch: https://git.openjdk.java.net/jdk/pull/1206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1206/head:pull/1206 PR: https://git.openjdk.java.net/jdk/pull/1206 From wetmore at openjdk.java.net Thu Mar 11 00:19:24 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 11 Mar 2021 00:19:24 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v4] In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: > Fix various things pointed out by the most recent doclint run in the security-libs area. > > This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Final codereview comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2856/files - new: https://git.openjdk.java.net/jdk/pull/2856/files/ed0cf2ba..edac22b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=02-03 Stats: 15 lines in 6 files changed: 2 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856 PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Thu Mar 11 00:22:09 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 11 Mar 2021 00:22:09 GMT Subject: RFR: 8263105: security-libs doclint cleanup [v4] In-Reply-To: <7J0SCUfBXhQs33Dm0ALYoOE-N3g8uJn93_reCgbebPg=.15fa4742-58d0-44cf-a113-0df0e25b7663@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> <24gnlaRnK6HCVyWRR9rnjw4EQUbakQ3jZirWKBro4Vk=.a4e4b32d-ff12-4560-ab0a-608736d2e7dc@github.com> <7J0SCUfBXhQs33Dm0ALYoOE-N3g8uJn93_reCgbebPg=.15fa4742-58d0-44cf-a113-0df0e25b7663@github.com> Message-ID: On Mon, 8 Mar 2021 19:50:06 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/java/security/BasicPermission.java line 497: >> >>> 495: /** >>> 496: * @serialData Default fields. >>> 497: */ >> >> FWIW, this doc comment will be ignored, because it will be superseded by the new comment on line 499. At some point doen the road, you may get a warning from javac about an ignored doc comment. > > Ok Removed after received similar later comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Thu Mar 11 00:29:09 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 11 Mar 2021 00:29:09 GMT Subject: Integrated: 8263105: security-libs doclint cleanup In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com> Message-ID: <42W8U-0W1f-W0sxeXCKhmwvjGnV_-HUpcX0yUtlIZ1k=.f8443a8d-47b1-4efc-82c8-41ad5c8901c7@github.com> On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore wrote: > Fix various things pointed out by the most recent doclint run in the security-libs area. > > This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. This pull request has now been integrated. Changeset: 32cbd193 Author: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/32cbd193 Stats: 302 lines in 35 files changed: 223 ins; 8 del; 71 mod 8263105: security-libs doclint cleanup Reviewed-by: iris, darcy, dfuchs, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2856 From wetmore at openjdk.java.net Thu Mar 11 01:20:20 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 11 Mar 2021 01:20:20 GMT Subject: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module Message-ID: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> Disable the "missing" target for java.smartcardio from doclint. ------------- Commit messages: - Forgot copyright date update - 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module Changes: https://git.openjdk.java.net/jdk/pull/2930/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2930&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252833 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2930.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2930/head:pull/2930 PR: https://git.openjdk.java.net/jdk/pull/2930 From iris at openjdk.java.net Thu Mar 11 01:25:06 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 11 Mar 2021 01:25:06 GMT Subject: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module In-Reply-To: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> References: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> Message-ID: On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote: > Disable the "missing" target for java.smartcardio from doclint. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2930 From ihse at openjdk.java.net Thu Mar 11 09:28:11 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 11 Mar 2021 09:28:11 GMT Subject: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module In-Reply-To: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> References: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> Message-ID: On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote: > Disable the "missing" target for java.smartcardio from doclint. Looks good to me. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2930 From clanger at openjdk.java.net Thu Mar 11 10:47:09 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 11 Mar 2021 10:47:09 GMT Subject: Integrated: 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 08:38:54 GMT, Christoph Langer wrote: > Exclude some failing tests from security/infra/java/security/cert/CertPathValidator This pull request has now been integrated. Changeset: a9b4f033 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/a9b4f033 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator Reviewed-by: mbaesken ------------- PR: https://git.openjdk.java.net/jdk/pull/2840 From shade at openjdk.java.net Thu Mar 11 11:28:14 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 11 Mar 2021 11:28:14 GMT Subject: RFR: 8263436: Silly array comparison in GaloisCounterMode.overlapDetection Message-ID: SonarCloud reports: Use "Arrays.equals(array1, array2)" or the "==" operator instead of using the "Object.equals(Object obj)" method. } else if (!src.isDirect() && !dst.isDirect()) { if (!src.isReadOnly()) { // If using the heap, check underlying byte[] address. if (!src.array().equals(dst.array()) ) { // <--- here Additional testing: - [x] Linux x86_64 fastdebug `jdk_security` ------------- Commit messages: - JDK-8263436: Silly array comparison in GaloisCounterMode.overlapDetection Changes: https://git.openjdk.java.net/jdk/pull/2938/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2938&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263436 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2938/head:pull/2938 PR: https://git.openjdk.java.net/jdk/pull/2938 From ihse at openjdk.java.net Thu Mar 11 11:59:08 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 11 Mar 2021 11:59:08 GMT Subject: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module In-Reply-To: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> References: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> Message-ID: On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote: > Disable the "missing" target for java.smartcardio from doclint. Revoking approval. ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2930 From ihse at openjdk.java.net Thu Mar 11 11:59:09 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 11 Mar 2021 11:59:09 GMT Subject: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module In-Reply-To: References: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> Message-ID: On Thu, 11 Mar 2021 09:25:34 GMT, Magnus Ihse Bursie wrote: >> Disable the "missing" target for java.smartcardio from doclint. > > Looks good to me. ... however, this fix does not achieve what the bug report is asking for. The patch here will modify flags to javac. The JBS issue talks about flags for javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/2930 From akozlov at openjdk.java.net Thu Mar 11 14:07:44 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 11 Mar 2021 14:07:44 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23] In-Reply-To: References: Message-ID: <5oHOwsaj5Jpg7ukRTFk7MG--w0_bq2qSwH6FN0WOZNY=.e519c482-ba19-4e24-955d-07743ab92359@github.com> On Wed, 3 Mar 2021 15:57:13 GMT, Gerard Ziemski wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207: >> >>> 205: // Enable WXWrite: this function is called by the signal handler at arbitrary >>> 206: // point of execution. >>> 207: ThreadWXEnable wx(WXWrite, thread); >> >> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform: >> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : >> _thread(thread ? thread : Thread::current()),` >> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check. > >> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform: >> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ? thread : Thread::current()),` >> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check. > > https://bugs.openjdk.java.net/browse/JDK-8262903 tracks this issue. Thanks for report and analysis! I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Thu Mar 11 14:07:43 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 11 Mar 2021 14:07:43 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: 8262903: [macos_aarch64] Thread::current() called on detached thread ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/a72f6834..f6fb01b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=23-24 Stats: 13 lines in 5 files changed: 3 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+829871+salusasecondus at openjdk.java.net Thu Mar 11 14:12:21 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Thu, 11 Mar 2021 14:12:21 GMT Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys Message-ID: This is my implementation for [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables creating of an SSL/TLS key log in the standardized [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format). This is supported by many TLS implementations and also by several parsers such as Wireshark. Supporting this will greatly ease in debugging TLS problems. (Note: I am covered by the Amazon corporate contribution agreement). ------------- Commit messages: - 8262880: Add support for the NSS Key Log Format for SSL/TLS keys Changes: https://git.openjdk.java.net/jdk/pull/2896/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2896&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262880 Stats: 327 lines in 5 files changed: 327 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2896.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2896/head:pull/2896 PR: https://git.openjdk.java.net/jdk/pull/2896 From simonis at openjdk.java.net Thu Mar 11 14:12:22 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 11 Mar 2021 14:12:22 GMT Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 17:18:39 GMT, SalusaSecondus wrote: > This is my implementation for [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables creating of an SSL/TLS key log in the standardized [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format). This is supported by many TLS implementations and also by several parsers such as Wireshark. Supporting this will greatly ease in debugging TLS problems. > > (Note: I am covered by the Amazon corporate contribution agreement). I can confirm that @SalusaSecondus is covered by the Amazon OCA. ------------- PR: https://git.openjdk.java.net/jdk/pull/2896 From rriggs at openjdk.java.net Thu Mar 11 14:56:20 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Mar 2021 14:56:20 GMT Subject: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module In-Reply-To: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> References: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> Message-ID: <21m43YAKO7S-X8dy-CibDXqidWY6rKibyLyPDi4rBw0=.3943b21f-038b-4fb3-b10c-858f3069da89@github.com> On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote: > Disable the "missing" target for java.smartcardio from doclint. Please assign a new bug and title to ignore/suppress the warnings. The original issue 8252833 should be left open. Thanks ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2930 From xuelei at openjdk.java.net Thu Mar 11 16:36:09 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 11 Mar 2021 16:36:09 GMT Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 17:18:39 GMT, SalusaSecondus wrote: > This is my implementation for [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables creating of an SSL/TLS key log in the standardized [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format). This is supported by many TLS implementations and also by several parsers such as Wireshark. Supporting this will greatly ease in debugging TLS problems. > > (Note: I am covered by the Amazon corporate contribution agreement). It is not good practice to leave secret information in debug log. Also, it may be not a good practice to introduce new logger format, including file and NSS format, into the SSLLogger. Someone also may want to introduce log format for MSS or XSS as well. Instead, please consider to make use of the features of Java Logger if you want to write the log to files, or use any special format. ------------- Changes requested by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2896 From ascarpino at openjdk.java.net Thu Mar 11 17:39:08 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 11 Mar 2021 17:39:08 GMT Subject: RFR: 8263436: Silly array comparison in GaloisCounterMode.overlapDetection In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 11:22:40 GMT, Aleksey Shipilev wrote: > SonarCloud reports: > Use "Arrays.equals(array1, array2)" or the "==" operator instead of using the "Object.equals(Object obj)" method. > > } else if (!src.isDirect() && !dst.isDirect()) { > if (!src.isReadOnly()) { > // If using the heap, check underlying byte[] address. > if (!src.array().equals(dst.array()) ) { // <--- here > > Additional testing: > - [x] Linux x86_64 fastdebug `jdk_security` Can you explain why the silly way it is written now is any different than what you are proposing? When running jshell your proposed change returns the same result as the existing code: one ==> byte[5] { 1, 2, 3, 4, 5 } two ==> byte[5] { 1, 2, 3, 4, 5 } jshell> one != two $9 ==> true jshell> !one.equals(two) $10 ==> true jshell> one != one $11 ==> false jshell> !one.equals(one) $12 ==> false Is the analysis tool thinking equals() is comparing the contents? ------------- PR: https://git.openjdk.java.net/jdk/pull/2938 From shade at openjdk.java.net Thu Mar 11 17:59:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 11 Mar 2021 17:59:06 GMT Subject: RFR: 8263436: Silly array comparison in GaloisCounterMode.overlapDetection In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 17:36:00 GMT, Anthony Scarpino wrote: >> SonarCloud reports: >> Use "Arrays.equals(array1, array2)" or the "==" operator instead of using the "Object.equals(Object obj)" method. >> >> } else if (!src.isDirect() && !dst.isDirect()) { >> if (!src.isReadOnly()) { >> // If using the heap, check underlying byte[] address. >> if (!src.array().equals(dst.array()) ) { // <--- here >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `jdk_security` > > Can you explain why the silly way it is written now is any different than what you are proposing? When running jshell your proposed change returns the same result as the existing code: > > one ==> byte[5] { 1, 2, 3, 4, 5 } > two ==> byte[5] { 1, 2, 3, 4, 5 } > jshell> one != two > $9 ==> true > > jshell> !one.equals(two) > $10 ==> true > > jshell> one != one > $11 ==> false > > jshell> !one.equals(one) > $12 ==> false > > Is the analysis tool thinking equals() is comparing the contents? > Can you explain why the silly way it is written now is any different than what you are proposing? Is the analysis tool thinking equals() is comparing the contents? See: https://rules.sonarsource.com/java/RSPEC-2159. Using `equals` raises the question if actual array contents comparisons was implied (which would require `Arrays.equals`). I know it is not implied here. Using `==` makes the intent clear. This is why the rule asks to choose either `==` or `Arrays.equals`. This is the only instance where that rule triggers in whole OpenJDK code. >From a micro-optimization perspective, `equals` is a method. This means interpreters are would have to do that call. Compilers would hopefully inline the call, but then it would still imply the null-check, because NPE should be thrown if one side is `null`. So, why call `equals()`, when `==` is better? ------------- PR: https://git.openjdk.java.net/jdk/pull/2938 From ascarpino at openjdk.java.net Thu Mar 11 18:18:07 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 11 Mar 2021 18:18:07 GMT Subject: RFR: 8263436: Silly array comparison in GaloisCounterMode.overlapDetection In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 17:55:39 GMT, Aleksey Shipilev wrote: >> Can you explain why the silly way it is written now is any different than what you are proposing? When running jshell your proposed change returns the same result as the existing code: >> >> one ==> byte[5] { 1, 2, 3, 4, 5 } >> two ==> byte[5] { 1, 2, 3, 4, 5 } >> jshell> one != two >> $9 ==> true >> >> jshell> !one.equals(two) >> $10 ==> true >> >> jshell> one != one >> $11 ==> false >> >> jshell> !one.equals(one) >> $12 ==> false >> >> Is the analysis tool thinking equals() is comparing the contents? > >> Can you explain why the silly way it is written now is any different than what you are proposing? Is the analysis tool thinking equals() is comparing the contents? > > See: https://rules.sonarsource.com/java/RSPEC-2159. > > Using `equals` raises the question if actual array contents comparisons was implied (which would require `Arrays.equals`). I know it is not implied here. Using `==` makes the intent clear. This is why the rule asks to choose either `==` or `Arrays.equals`. This is the only instance where that rule triggers in whole OpenJDK code. > > From a micro-optimization perspective, `equals` is a method. This means interpreters are would have to do that call. Compilers would hopefully inline the call, but then it would still imply the null-check, because NPE should be thrown if one side is `null`. > > So, why call `equals()`, when `==` is better? meh ------------- PR: https://git.openjdk.java.net/jdk/pull/2938 From ascarpino at openjdk.java.net Thu Mar 11 18:22:08 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 11 Mar 2021 18:22:08 GMT Subject: RFR: 8263436: Silly array comparison in GaloisCounterMode.overlapDetection In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 11:22:40 GMT, Aleksey Shipilev wrote: > SonarCloud reports: > Use "Arrays.equals(array1, array2)" or the "==" operator instead of using the "Object.equals(Object obj)" method. > > } else if (!src.isDirect() && !dst.isDirect()) { > if (!src.isReadOnly()) { > // If using the heap, check underlying byte[] address. > if (!src.array().equals(dst.array()) ) { // <--- here > > Additional testing: > - [x] Linux x86_64 fastdebug `jdk_security` Marked as reviewed by ascarpino (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2938 From shade at openjdk.java.net Thu Mar 11 18:27:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 11 Mar 2021 18:27:08 GMT Subject: RFR: 8263436: Silly array comparison in GaloisCounterMode.overlapDetection In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 18:19:41 GMT, Anthony Scarpino wrote: >> SonarCloud reports: >> Use "Arrays.equals(array1, array2)" or the "==" operator instead of using the "Object.equals(Object obj)" method. >> >> } else if (!src.isDirect() && !dst.isDirect()) { >> if (!src.isReadOnly()) { >> // If using the heap, check underlying byte[] address. >> if (!src.array().equals(dst.array()) ) { // <--- here >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `jdk_security` > > Marked as reviewed by ascarpino (Reviewer). Here is a demo, if anyone interested: @State(Scope.Thread) public class ArrayEquals { byte[] b1 = new byte[1]; byte[] b2 = new byte[1]; @Benchmark public boolean acmp() { return b1 == b2; } @Benchmark public boolean eq() { return b1.equals(b2); } } Benchmark Mode Cnt Score Error Units # C2 (Default) ArrayEquals.acmp avgt 5 0.678 ? 0.001 ns/op ArrayEquals.acmp:cycles avgt 2.576 #/op ArrayEquals.acmp:instructions avgt 10.199 #/op ArrayEquals.eq avgt 5 0.680 ? 0.007 ns/op ArrayEquals.eq:cycles avgt 2.540 #/op ArrayEquals.eq:instructions avgt 13.032 #/op ; <--- null check # C1 ArrayEquals.acmp avgt 5 1.086 ? 0.006 ns/op ArrayEquals.acmp:cycles avgt 4.110 #/op ArrayEquals.acmp:instructions avgt 16.325 #/op ArrayEquals.eq avgt 5 4.606 ? 0.001 ns/op ; <--- equals() inline failed ArrayEquals.eq:cycles avgt 17.328 #/op ArrayEquals.eq:instructions avgt 42.520 #/op # -Xint ArrayEquals.acmp avgt 5 207.550 ? 1.126 ns/op ArrayEquals.acmp:cycles avgt 763.037 #/op ArrayEquals.acmp:instructions avgt 570.161 #/op ArrayEquals.eq avgt 5 300.449 ? 26.939 ns/op ; <--- interpreter call cost ArrayEquals.eq:cycles avgt 1068.852 #/op ArrayEquals.eq:instructions avgt 722.228 #/op ------------- PR: https://git.openjdk.java.net/jdk/pull/2938 From simonis at openjdk.java.net Thu Mar 11 18:36:19 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 11 Mar 2021 18:36:19 GMT Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 16:33:10 GMT, Xue-Lei Andrew Fan wrote: >> This is my implementation for [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables creating of an SSL/TLS key log in the standardized [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format). This is supported by many TLS implementations and also by several parsers such as Wireshark. Supporting this will greatly ease in debugging TLS problems. >> >> (Note: I am covered by the Amazon corporate contribution agreement). > > It is not good practice to leave secret information in debug log. Also, it may be not a good practice to introduce new logger format, including file and NSS format, into the SSLLogger. Someone also may want to introduce log format for MSS or XSS as well. Instead, please consider to make use of the features of Java Logger if you want to write the log to files, or use any special format. I'm happy to create a CSR for this issue once the exact details of the option format have been figured out. ------------- PR: https://git.openjdk.java.net/jdk/pull/2896 From github.com+829871+salusasecondus at openjdk.java.net Thu Mar 11 18:43:06 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Thu, 11 Mar 2021 18:43:06 GMT Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 18:33:07 GMT, Volker Simonis wrote: >> It is not good practice to leave secret information in debug log. Also, it may be not a good practice to introduce new logger format, including file and NSS format, into the SSLLogger. Someone also may want to introduce log format for MSS or XSS as well. Instead, please consider to make use of the features of Java Logger if you want to write the log to files, or use any special format. > > I'm happy to create a CSR for this issue once the exact details of the option format have been figured out. I am not familiar with either the MSS or XSS log formats and would be interested to see them. The NSS format is a defacto industry standard and already supported by many libraries (both producers and consumers) and thus used widely in the security industry. Most other uses that I can find take this similar pattern of providing a file-name to the TLS logic and then getting key log (in this format) written to that file. I agree completely that logging secret information is dangerous and should almost never be done. That is why it has to be explicitly enabled (unlike most of the other `javax.net.debug` options) and another reason it is no commingled with the other logging output. ------------- PR: https://git.openjdk.java.net/jdk/pull/2896 From ascarpino at openjdk.java.net Thu Mar 11 18:54:06 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 11 Mar 2021 18:54:06 GMT Subject: RFR: 8263436: Silly array comparison in GaloisCounterMode.overlapDetection In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 18:24:43 GMT, Aleksey Shipilev wrote: >> Marked as reviewed by ascarpino (Reviewer). > > Here is a demo, if anyone interested: > > @State(Scope.Thread) > public class ArrayEquals { > byte[] b1 = new byte[1]; > byte[] b2 = new byte[1]; > > @Benchmark > public boolean acmp() { return b1 == b2; } > > @Benchmark > public boolean eq() { return b1.equals(b2); } > } > > Benchmark Mode Cnt Score Error Units > > # C2 (Default) > ArrayEquals.acmp avgt 5 0.678 ? 0.001 ns/op > ArrayEquals.acmp:cycles avgt 2.576 #/op > ArrayEquals.acmp:instructions avgt 10.199 #/op > > ArrayEquals.eq avgt 5 0.680 ? 0.007 ns/op > ArrayEquals.eq:cycles avgt 2.540 #/op > ArrayEquals.eq:instructions avgt 13.032 #/op ; <--- null check > > # C1 > ArrayEquals.acmp avgt 5 1.086 ? 0.006 ns/op > ArrayEquals.acmp:cycles avgt 4.110 #/op > ArrayEquals.acmp:instructions avgt 16.325 #/op > > ArrayEquals.eq avgt 5 4.606 ? 0.001 ns/op ; <--- equals() inline failed > ArrayEquals.eq:cycles avgt 17.328 #/op > ArrayEquals.eq:instructions avgt 42.520 #/op > > # -Xint > ArrayEquals.acmp avgt 5 207.550 ? 1.126 ns/op > ArrayEquals.acmp:cycles avgt 763.037 #/op > ArrayEquals.acmp:instructions avgt 570.161 #/op > > ArrayEquals.eq avgt 5 300.449 ? 26.939 ns/op ; <--- interpreter call cost > ArrayEquals.eq:cycles avgt 1068.852 #/op > ArrayEquals.eq:instructions avgt 722.228 #/op The performance data is more compelling rationale to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2938 From luoziyi at openjdk.java.net Thu Mar 11 20:00:23 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Thu, 11 Mar 2021 20:00:23 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec Message-ID: This is a P2 regression introduced by JDK-8254717. In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: X-axis: type of `keySpec` Y-axis: type of `key` Before JDK-8254717: | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | |--|--|--| | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | After JDK-8254717 (Green check is what we want to fix, red cross is the regression): | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | |--|--|--| | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | This commit fixes the regression. ### Tests * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed ------------- Commit messages: - Fix jcheck whitespace error - 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec Changes: https://git.openjdk.java.net/jdk/pull/2949/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2949&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263404 Stats: 21 lines in 1 file changed: 3 ins; 5 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/2949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2949/head:pull/2949 PR: https://git.openjdk.java.net/jdk/pull/2949 From iignatyev at openjdk.java.net Thu Mar 11 20:22:28 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 11 Mar 2021 20:22:28 GMT Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside of default package Message-ID: Hi all, could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls `jdk.test.lib.helpers. ClassFileInstaller::main`. from JBS: > ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. > > to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl. > > the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8263412). testing: - [x] `:jdk_core` against `{macos,windows,linux}-x64` - [x] `:jdk_svc` against `{macos,windows,linux}-x64` - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64` Thanks, -- Igor ------------- Commit messages: - make ClassFileInstaller.Manifest::from* public - updated copyright years - import j.t.l.helpers.ClassFileInstaller - added jdk/test/lib/helpers/ClassFileInstaller Changes: https://git.openjdk.java.net/jdk/pull/2932/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2932&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263412 Stats: 473 lines in 114 files changed: 145 ins; 229 del; 99 mod Patch: https://git.openjdk.java.net/jdk/pull/2932.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2932/head:pull/2932 PR: https://git.openjdk.java.net/jdk/pull/2932 From stefank at openjdk.java.net Thu Mar 11 20:31:16 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 11 Mar 2021 20:31:16 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25] In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > 8262903: [macos_aarch64] Thread::current() called on detached thread Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From stefank at openjdk.java.net Thu Mar 11 20:31:17 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 11 Mar 2021 20:31:17 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: References: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> Message-ID: <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com> On Tue, 9 Mar 2021 17:55:12 GMT, Anton Kozlov wrote: >> src/hotspot/share/runtime/thread.cpp line 2515: >> >>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) { >>> 2514: // Enable WXWrite: called directly from interpreter native wrapper. >>> 2515: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread)); >> >> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version: >> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) { >> MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {} >> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp) >> With that said, I'm fine with taking this discussion as a follow-up. > > The former version used no such macros. I like that now it's clear the W^X management is relevant to macos/aarch64 only. I see the point to move the pre-processor condition into the class implementation. But I think it will bring a bit of inconsistency, as the rest of W^X implementation is explicitly guarded by preprocessor conditionals. I've also tried to push macro conditionals as far as possible down to implementation, providing a kind of generalized W^X interface. That required a few artificial decisions, e.g. how would we call the mode we execute on the rest of platforms with write and execute allowed, WXWriteExec?.. I abandoned that attempt. I think we would use the same names, but I haven't given it more thought. I might take a look at this after this has been integrated. >> src/hotspot/share/runtime/thread.hpp line 848: >> >>> 846: void init_wx(); >>> 847: WXMode enable_wx(WXMode new_state); >>> 848: #endif // __APPLE__ && AARCH64 >> >> Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions. > > The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. > > In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR. Good point about Thread vs JavaThread. Yes, this can be looked into as follow-up cleanups. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From iklam at openjdk.java.net Thu Mar 11 20:58:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 11 Mar 2021 20:58:07 GMT Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside of default package In-Reply-To: References: Message-ID: <7P0MS1asoKJMsIEgliuJvza7mcz1z7aBeeF9RKccIK4=.d1dbefa1-3b4b-4adf-bf2e-24f7c61161cb@github.com> On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? > to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls `jdk.test.lib.helpers. ClassFileInstaller::main`. > > from JBS: >> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. >> >> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl. >> >> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129). > > testing: > - [x] `:jdk_core` against `{macos,windows,linux}-x64` > - [x] `:jdk_svc` against `{macos,windows,linux}-x64` > - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64` > > Thanks, > -- Igor The CDS test changes look good to me. It seems they are just adding a single line of import. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2932 From coleenp at openjdk.java.net Thu Mar 11 21:18:11 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 11 Mar 2021 21:18:11 GMT Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside of default package In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? > to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls `jdk.test.lib.helpers. ClassFileInstaller::main`. > > from JBS: >> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. >> >> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl. >> >> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129). > > testing: > - [x] `:jdk_core` against `{macos,windows,linux}-x64` > - [x] `:jdk_svc` against `{macos,windows,linux}-x64` > - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64` > > Thanks, > -- Igor Looks good. I looked at the RedefineClasses tests also. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2932 From wetmore at openjdk.java.net Fri Mar 12 00:35:07 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 12 Mar 2021 00:35:07 GMT Subject: Withdrawn: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module In-Reply-To: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> References: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> Message-ID: On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote: > Disable the "missing" target for java.smartcardio from doclint. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2930 From wetmore at openjdk.java.net Fri Mar 12 00:35:06 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 12 Mar 2021 00:35:06 GMT Subject: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module In-Reply-To: <21m43YAKO7S-X8dy-CibDXqidWY6rKibyLyPDi4rBw0=.3943b21f-038b-4fb3-b10c-858f3069da89@github.com> References: <17wBOzNKPlM4LXr7NIJkRoAqycmngF_OCQx6XOnkPAA=.13d403e6-f939-4180-88bd-40ccb1da5dbc@github.com> <21m43YAKO7S-X8dy-CibDXqidWY6rKibyLyPDi4rBw0=.3943b21f-038b-4fb3-b10c-858f3069da89@github.com> Message-ID: <0AHS8sAs6ey7lsq7cYH-VXghs-KETRRSzw2NqHbc1DM=.85709b56-5bd1-43c7-a808-5e90cfc925d5@github.com> On Thu, 11 Mar 2021 14:53:22 GMT, Roger Riggs wrote: >> Disable the "missing" target for java.smartcardio from doclint. > > Please assign a new bug and title to ignore/suppress the warnings. > The original issue 8252833 should be left open. > Thanks Closing, as it's unclear which approach should be taken. ------------- PR: https://git.openjdk.java.net/jdk/pull/2930 From mseledtsov at openjdk.java.net Fri Mar 12 02:11:07 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 12 Mar 2021 02:11:07 GMT Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside of default package In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? > to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls `jdk.test.lib.helpers. ClassFileInstaller::main`. > > from JBS: >> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. >> >> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl. >> >> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129). > > testing: > - [x] `:jdk_core` against `{macos,windows,linux}-x64` > - [x] `:jdk_svc` against `{macos,windows,linux}-x64` > - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64` > > Thanks, > -- Igor Marked as reviewed by mseledtsov (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2932 From dholmes at openjdk.java.net Fri Mar 12 05:27:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 12 Mar 2021 05:27:17 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25] In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > 8262903: [macos_aarch64] Thread::current() called on detached thread src/hotspot/share/runtime/safefetch.inline.hpp line 35: > 33: inline int SafeFetch32(int* adr, int errValue) { > 34: assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); > 35: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current())); I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Mar 12 07:12:17 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 12 Mar 2021 07:12:17 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8262903: [macos_aarch64] Thread::current() called on detached thread > > src/hotspot/share/runtime/safefetch.inline.hpp line 35: > >> 33: inline int SafeFetch32(int* adr, int errValue) { >> 34: assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); >> 35: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current())); > > I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN. I'm not sure about expected behavior then. We may crash trying to execute the generated code, since we may have no WXExec. If we switch to WXExec, we would need to go back to a previous W^X state, but we don't know which one without the thread. BTW, the test passes, probably that's why it didn't get attention. All non-trivial actions in the current implementation of `pd_hotspot_signal_handler` (hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324) assume non-NULL thread. So AFAICS, we should always have a thread when the SafeFetch is called. Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could just move ThreadWXEnable under the `if`. But now after https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows optional locking. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From shade at openjdk.java.net Fri Mar 12 07:38:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 12 Mar 2021 07:38:08 GMT Subject: Integrated: 8263436: Silly array comparison in GaloisCounterMode.overlapDetection In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 11:22:40 GMT, Aleksey Shipilev wrote: > SonarCloud reports: > Use "Arrays.equals(array1, array2)" or the "==" operator instead of using the "Object.equals(Object obj)" method. > > } else if (!src.isDirect() && !dst.isDirect()) { > if (!src.isReadOnly()) { > // If using the heap, check underlying byte[] address. > if (!src.array().equals(dst.array()) ) { // <--- here > > Additional testing: > - [x] Linux x86_64 fastdebug `jdk_security` This pull request has now been integrated. Changeset: 9f6b1d7f Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9f6b1d7f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8263436: Silly array comparison in GaloisCounterMode.overlapDetection Reviewed-by: ascarpino ------------- PR: https://git.openjdk.java.net/jdk/pull/2938 From david.holmes at oracle.com Fri Mar 12 07:58:56 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Mar 2021 17:58:56 +1000 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25] In-Reply-To: References: Message-ID: <59c46a13-91d9-bd60-70dd-ff8fde81c0c7@oracle.com> On 12/03/2021 5:12 pm, Anton Kozlov wrote: > On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes wrote: > >>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >>> >>> 8262903: [macos_aarch64] Thread::current() called on detached thread >> >> src/hotspot/share/runtime/safefetch.inline.hpp line 35: >> >>> 33: inline int SafeFetch32(int* adr, int errValue) { >>> 34: assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); >>> 35: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current())); >> >> I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN. > > I'm not sure about expected behavior then. We may crash trying to execute the generated code, since we may have no WXExec. If we switch to WXExec, we would need to go back to a previous W^X state, but we don't know which one without the thread. The NULL check is only part of it. In a signal handling context Thread::current() is not safe to call, you have to use Thread::current_or_null_safe(). > BTW, the test passes, probably that's why it didn't get attention. All non-trivial actions in the current implementation of `pd_hotspot_signal_handler` (hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324) assume non-NULL thread. So AFAICS, we should always have a thread when the SafeFetch is called. Okay but you still need to use Thread::current_or_null_safe(). Cheers, David > Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could just move ThreadWXEnable under the `if`. But now after https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows optional locking. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 > From shade at openjdk.java.net Fri Mar 12 09:28:19 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 12 Mar 2021 09:28:19 GMT Subject: RFR: 8263497: Clean up sun.security.krb5.PrincipalName::toByteArray Message-ID: SonarCloud actually found this: Verify this is the index that was intended; it was already set before. public byte[][] toByteArray() { byte[][] result = new byte[nameStrings.length][]; for (int i = 0; i < nameStrings.length; i++) { result[i] = new byte[nameStrings[i].length()]; // <-- here result[i] = nameStrings[i].getBytes(); } return result; } `getBytes()` returns the `byte[]` array, there is no need to allocate the array before it. ------------- Commit messages: - 8263497: Clean up sun.security.krb5.PrincipalName::toByteArray Changes: https://git.openjdk.java.net/jdk/pull/2962/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2962&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263497 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2962.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2962/head:pull/2962 PR: https://git.openjdk.java.net/jdk/pull/2962 From akozlov at openjdk.java.net Fri Mar 12 12:17:39 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 12 Mar 2021 12:17:39 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v26] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: - Add Azul copyright - Update Oracle copyright years - Use Thread::current_or_null_safe in SafeFetch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/f6fb01b2..29991c92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=25 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=24-25 Stats: 83 lines in 53 files changed: 41 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Mar 12 13:38:17 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Mar 2021 13:38:17 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 08:12:10 GMT, Anton Kozlov wrote: >> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround >> @gerard-ziemski, 8020753 was originally your fix, do you know if it still needed on intel-mac ? > > The x86_bsd still carries the workaround https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745. It's worth having macos ports to be aligned by features. I would propose to have this workaround for now, and decide on it later for macos/x86 and macos/aarch64 at once. Sorry for chiming in so late. Hello Anton. Please keep JDK-8020753 away from this port, as JDK-8020753 was very intel-specific workaround and macos11.0 on aarch64 doesn't show any signs of original bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Mar 12 14:10:18 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 12 Mar 2021 14:10:18 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25] In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 20:28:46 GMT, Stefan Karlsson wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8262903: [macos_aarch64] Thread::current() called on detached thread > > Marked as reviewed by stefank (Reviewer). > you still need to use Thread::current_or_null_safe() [for SafeFetch]. OK :) I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/fd4812e585e0528010a8863df50956a3b64a6744 @dcubed-ojdk, I also updated copyrights, this concludes fixes for the review https://github.com/openjdk/jdk/pull/2200#pullrequestreview-581784107. @theRealAph, could you elaborate on what is need to be done for https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From weijun at openjdk.java.net Fri Mar 12 16:14:08 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 12 Mar 2021 16:14:08 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 19:51:19 GMT, Ziyi Luo wrote: > This is a P2 regression introduced by JDK-8254717. > > In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: > > X-axis: type of `keySpec` > Y-axis: type of `key` > > Before JDK-8254717: > > | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | > |--|--|--| > | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | > | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | > > After JDK-8254717 (Green check is what we want to fix, red cross is the regression): > > | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | > |--|--|--| > | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | > | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | > > This commit fixes the regression. > > > ### Tests > > * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed > * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed My understanding is that the problem here is the 2 `isAssignableFrom` checks are in wrong order. The parent class RSA_PRIV_KEYSPEC_CLS should be checked first. BTW, please add a regression test to the fix. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From mullan at openjdk.java.net Fri Mar 12 16:45:21 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 12 Mar 2021 16:45:21 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v8] In-Reply-To: References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> Message-ID: On Thu, 11 Mar 2021 00:06:50 GMT, Weijun Wang wrote: >> This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario 2.2.0. >> >> The first step is an auto-import. The JDK implementation is removed first and Santuario code are imported. Some unrelated files (Ex: encryption) are removed, and package names are renamed to be internal. There are also some bulk changes on company name, comment style, and white spaces. >> >> Next steps are patches applied by JDK. Some are old patches before the last import. Some are new. >> >> Several tests need to be updated because of internal method signature changes. > > Weijun Wang 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 15 additional commits since the last revision: > > - Merge branch 'master' into 8255255 > - reapply 8259535: ECDSA SignatureValue do not always have the specified length > - No more newInstance calls > - Reapply 8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() > - Fix test failures > - Supporting named RSASSA-PSS without parameters > - Reapply 8008744: Rework part of fix for JDK-6741606 > - Reapply 8151893: Add security property to configure XML Signature secure validation mode > > Reapply 8140353: Improve signature checking > - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes > - Reapply 8038913: Bolster XML support (Init.java part) > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/337c62e0...60496847 src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 70: > 68: * @return the Set of Nodes > 69: */ > 70: static Set toNodeSet(Iterator i) { Why does `Iterator` cause a warning? ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From aph at openjdk.java.net Fri Mar 12 16:35:23 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 12 Mar 2021 16:35:23 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24] In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 16:12:36 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits: > > - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos > - workaround JDK-8262895 by disabling subtest > - Fix typo > - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp > - JDK-8259937: bsd_aarch64 part > - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos > - Fix after JDK-8259539, partially revert preconditions > - JDK-8260471: bsd_aarch64 part > - JDK-8259539: bsd_aarch64 part > - JDK-8257828: bsd_aarch64 part > - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834 > @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066). I think that what you've got now is fine. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From weijun at openjdk.java.net Fri Mar 12 16:13:18 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 12 Mar 2021 16:13:18 GMT Subject: RFR: 8263497: Clean up sun.security.krb5.PrincipalName::toByteArray In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 09:22:40 GMT, Aleksey Shipilev wrote: > SonarCloud actually found this: > Verify this is the index that was intended; it was already set before. > > > public byte[][] toByteArray() { > byte[][] result = new byte[nameStrings.length][]; > for (int i = 0; i < nameStrings.length; i++) { > result[i] = new byte[nameStrings[i].length()]; // <-- here > result[i] = nameStrings[i].getBytes(); > } > return result; > } > > `getBytes()` returns the `byte[]` array, there is no need to allocate the array before it. Marked as reviewed by weijun (Reviewer). Update the copyright year to 2021 and everything else is fine. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2962 From aph at openjdk.java.net Fri Mar 12 16:35:24 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 12 Mar 2021 16:35:24 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21] In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 18:01:11 GMT, Anton Kozlov wrote: >> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62: >> >>> 60: >>> 61: #if defined(__APPLE__) || defined(_WIN64) >>> 62: #define R18_RESERVED >> >> #define R18_RESERVED true``` > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro? Robustness, clarity, maintainability, convention. Why not? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Mar 12 16:44:38 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 12 Mar 2021 16:44:38 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v27] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Fix most of issues in java/foreign/ tests Failures related to va_args are tracked in JDK-8263512. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/29991c92..5bfe0f08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=26 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=25-26 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From shade at openjdk.java.net Fri Mar 12 16:35:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 12 Mar 2021 16:35:18 GMT Subject: RFR: 8263497: Clean up sun.security.krb5.PrincipalName::toByteArray [v2] In-Reply-To: References: Message-ID: <4ylxB5veJ0EMSb0_PTgbL3Bd84H3KE8zPTvaaL-lDoE=.16a883b2-6549-4a1c-be70-e1805b3c7a7d@github.com> > SonarCloud actually found this: > Verify this is the index that was intended; it was already set before. > > > public byte[][] toByteArray() { > byte[][] result = new byte[nameStrings.length][]; > for (int i = 0; i < nameStrings.length; i++) { > result[i] = new byte[nameStrings[i].length()]; // <-- here > result[i] = nameStrings[i].getBytes(); > } > return result; > } > > `getBytes()` returns the `byte[]` array, there is no need to allocate the array before it. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Copyright update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2962/files - new: https://git.openjdk.java.net/jdk/pull/2962/files/6223ee6f..7e8a3104 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2962&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2962&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2962.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2962/head:pull/2962 PR: https://git.openjdk.java.net/jdk/pull/2962 From github.com+829871+salusasecondus at openjdk.java.net Fri Mar 12 17:02:07 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Fri, 12 Mar 2021 17:02:07 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 15:39:48 GMT, Weijun Wang wrote: >> This is a P2 regression introduced by JDK-8254717. >> >> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: >> >> X-axis: type of `keySpec` >> Y-axis: type of `key` >> >> Before JDK-8254717: >> >> | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | >> |--|--|--| >> | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | >> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | >> >> After JDK-8254717 (Green check is what we want to fix, red cross is the regression): >> >> | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | >> |--|--|--| >> | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | >> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | >> >> This commit fixes the regression. >> >> >> ### Tests >> >> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed >> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed > > My understanding is that the problem here is the 2 `isAssignableFrom` checks are in wrong order. The parent class RSA_PRIV_KEYSPEC_CLS should be checked first. > > BTW, please add a regression test to the fix. Thanks. If we check the parent class `RSA_PRIV_KEYSPEC_CLS` first, then the JDK will return instances of `RSAPrivateKeySpec` even when it *could* return an instance of `RSAPrivateCrtKeySpec`. If the underlying RSA key has CRT parameters, then it seems preferable to return the more detailed and specific `RSAPrivateCrtKeySpec` if possible. (Not opportunistically returning `RSAPrivateCrtKeySpec` is actually one of the specific things that the prior change (which introduced this regression) is trying to fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From jlaskey at openjdk.java.net Fri Mar 12 19:05:28 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 12 Mar 2021 19:05:28 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v29] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: - Review requested changes - Merge branch 'master' into 8248862 - Remove conflicts - Use isAnnotationPresent - Introduce isDeprecated - Update javadoc - Merge branch 'master' into 8248862 - Adjust ThreadLocalRandom javadoc inheritence - L32X64StarStarRandom -> L32X64MixRandom - Various corrects - ... and 53 more: https://git.openjdk.java.net/jdk/compare/273f8bdf...e5b87227 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=28 Stats: 13827 lines in 26 files changed: 11646 ins; 1849 del; 332 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From luoziyi at openjdk.java.net Fri Mar 12 22:00:18 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Fri, 12 Mar 2021 22:00:18 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v2] In-Reply-To: References: Message-ID: > This is a P2 regression introduced by JDK-8254717. > > In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: > > X-axis: type of `keySpec` > Y-axis: type of `key` > > Before JDK-8254717: > > | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | > |--|--|--| > | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | > | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | > > After JDK-8254717 (Green check is what we want to fix, red cross is the regression): > > | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | > |--|--|--| > | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | > | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | > > This commit fixes the regression. > > > ### Tests > > * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed > * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed Ziyi Luo has updated the pull request incrementally with one additional commit since the last revision: Add one test case for the regression fixed by 8263404 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2949/files - new: https://git.openjdk.java.net/jdk/pull/2949/files/0ebb72d0..e9a76978 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2949&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2949&range=00-01 Stats: 62 lines in 1 file changed: 61 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2949/head:pull/2949 PR: https://git.openjdk.java.net/jdk/pull/2949 From luoziyi at openjdk.java.net Fri Mar 12 22:09:07 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Fri, 12 Mar 2021 22:09:07 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 15:39:48 GMT, Weijun Wang wrote: >> This is a P2 regression introduced by JDK-8254717. >> >> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: >> >> X-axis: type of `keySpec` >> Y-axis: type of `key` >> >> Before JDK-8254717: >> >> | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | >> |--|--|--| >> | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | >> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | >> >> After JDK-8254717 (Green check is what we want to fix, red cross is the regression): >> >> | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | >> |--|--|--| >> | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | >> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | >> >> This commit fixes the regression. >> >> >> ### Tests >> >> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed >> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed > > My understanding is that the problem here is the 2 `isAssignableFrom` checks are in wrong order. The parent class RSA_PRIV_KEYSPEC_CLS should be checked first. > > BTW, please add a regression test to the fix. Thanks. Hi @wangweij Thanks for your review. As @SalusaSecondus commented, RSAPrivateKeyCrtSpec should be favored over RSAPrivateKeySpec when the PrivateKey is a Crt Key. I just modified our JTreg test to include all four cases described in the PR description. ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From weijun at openjdk.java.net Fri Mar 12 22:09:08 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 12 Mar 2021 22:09:08 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 22:04:35 GMT, Ziyi Luo wrote: >> My understanding is that the problem here is the 2 `isAssignableFrom` checks are in wrong order. The parent class RSA_PRIV_KEYSPEC_CLS should be checked first. >> >> BTW, please add a regression test to the fix. Thanks. > > Hi @wangweij Thanks for your review. As @SalusaSecondus commented, RSAPrivateKeyCrtSpec should be favored over RSAPrivateKeySpec when the PrivateKey is a Crt Key. I just modified our JTreg test to include all four cases described in the PR description. I still cannot understand why CRT is always preferred. The original implementation also hadn't done that. ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From iignatyev at openjdk.java.net Fri Mar 12 23:16:08 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 12 Mar 2021 23:16:08 GMT Subject: Integrated: 8263412: ClassFileInstaller can't be used by classes outside of default package In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? > to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls `jdk.test.lib.helpers. ClassFileInstaller::main`. > > from JBS: >> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. >> >> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl. >> >> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129). > > testing: > - [x] `:jdk_core` against `{macos,windows,linux}-x64` > - [x] `:jdk_svc` against `{macos,windows,linux}-x64` > - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: e834f99d Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/e834f99d Stats: 472 lines in 114 files changed: 145 ins; 229 del; 98 mod 8263412: ClassFileInstaller can't be used by classes outside of default package Reviewed-by: iklam, coleenp, mseledtsov ------------- PR: https://git.openjdk.java.net/jdk/pull/2932 From iignatyev at openjdk.java.net Fri Mar 12 23:16:06 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 12 Mar 2021 23:16:06 GMT Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside of default package In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 02:08:09 GMT, Mikhailo Seledtsov wrote: >> Hi all, >> >> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? >> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls `jdk.test.lib.helpers. ClassFileInstaller::main`. >> >> from JBS: >>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. >>> >>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl. >>> >>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129). >> >> testing: >> - [x] `:jdk_core` against `{macos,windows,linux}-x64` >> - [x] `:jdk_svc` against `{macos,windows,linux}-x64` >> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64` >> >> Thanks, >> -- Igor > > Marked as reviewed by mseledtsov (Committer). Ioi, Coleen, Misha, thanks for your reviews. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/2932 From github.com+829871+salusasecondus at openjdk.java.net Sat Mar 13 00:40:06 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Sat, 13 Mar 2021 00:40:06 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec In-Reply-To: References: Message-ID: <2KLmEc8838CzSSDp6hqaphYT_k2inBBhkGB_9eJc04I=.9ca5b175-01a3-4730-a393-f3887f659d73@github.com> On Fri, 12 Mar 2021 22:06:40 GMT, Weijun Wang wrote: >> Hi @wangweij Thanks for your review. As @SalusaSecondus commented, RSAPrivateKeyCrtSpec should be favored over RSAPrivateKeySpec when the PrivateKey is a Crt Key. I just modified our JTreg test to include all four cases described in the PR description. > > I still cannot understand why CRT is always preferred. The original implementation also hadn't done that. I believe that the original implementation intended to do this but made a mistake. This is why the original implementation (with the backwards `isAssignableFrom` logic) first checked to see if it could use CRT (as it had more information) and only afterwards fell back to seeing if it could use `RSAPrivateKeySpec`. RSA CRT keys are much more efficient than normal RSA private keys and also result in more a more standard compliant output when serialized to PKCS#8 format (which technically requires the CRT parameters to be present). Thus, I believe we should try to preserve the CRT parameters whenever possible for our users. Now users who request an `RSAPrivateKeySpec` and then use it to later create a new key (using `KeyFactory.generatePrivate`) can keep the significant performance benefits for that private key. ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From iignatyev at openjdk.java.net Sat Mar 13 04:38:48 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 13 Mar 2021 04:38:48 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split Message-ID: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> Hi all, could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used). from JBS: > after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. testing: - [x] `grep ' ClassFileInstaller[^.]` - [ ] tier1-3 Thanks, -- Igor ------------- Commit messages: - fixup - update copyright year - rm test/lib/ClassFileInstaller.java - 's/ ClassFileInstaller / jdk.test.lib.helpers.ClassFileInstaller /g' Changes: https://git.openjdk.java.net/jdk/pull/2985/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263549 Stats: 1736 lines in 867 files changed: 0 ins; 67 del; 1669 mod Patch: https://git.openjdk.java.net/jdk/pull/2985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2985/head:pull/2985 PR: https://git.openjdk.java.net/jdk/pull/2985 From iignatyev at openjdk.java.net Sat Mar 13 04:42:08 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 13 Mar 2021 04:42:08 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> Message-ID: On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used). > > from JBS: >> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. > > testing: > - [x] `grep ' ClassFileInstaller[^.]` > - [ ] tier1-3 > > Thanks, > -- Igor note for reviewers: the big part of the patch is just `sed -i 's/ ClassFileInstaller / jdk.test.lib.helpers.ClassFileInstaller /g'` ------------- PR: https://git.openjdk.java.net/jdk/pull/2985 From dholmes at openjdk.java.net Sat Mar 13 05:52:22 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 13 Mar 2021 05:52:22 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v27] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 16:44:38 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix most of issues in java/foreign/ tests > > Failures related to va_args are tracked in JDK-8263512. src/hotspot/share/runtime/safefetch.inline.hpp line 35: > 33: inline int SafeFetch32(int* adr, int errValue) { > 34: assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); > 35: Thread* thread = Thread::current_or_null_safe(); Sorry but this should be MACOS_AARCH64 only. All three lines need to be ifdef'd if you are going to include the assertion. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From iklam at openjdk.java.net Sat Mar 13 06:19:06 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 13 Mar 2021 06:19:06 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> Message-ID: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com> On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used). > > from JBS: >> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. > > testing: > - [x] `grep ' ClassFileInstaller[^.]` > - [ ] tier1-3 > > Thanks, > -- Igor I did this and scanned the differences (with the diff file from the webrev) and it looks reasonable to me. grep '^[+-]' diff.txt | grep -v Copyright | grep -v '^.[+-]' | less It looks like most of the changes are mechanical. There were only a few cases where manual changes were made. I trusted that you have tested those cases individually. But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2985 From iignatyev at openjdk.java.net Sat Mar 13 06:30:00 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 13 Mar 2021 06:30:00 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split [v2] In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> Message-ID: > Hi all, > > could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used). > > from JBS: >> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. > > testing: > - [x] `grep ' ClassFileInstaller[^.]` > - [ ] tier1-3 > > Thanks, > -- Igor Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: fix compilation error in IncorrectAOTLibraryTest test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2985/files - new: https://git.openjdk.java.net/jdk/pull/2985/files/6e53ad97..ff6d4f91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2985/head:pull/2985 PR: https://git.openjdk.java.net/jdk/pull/2985 From iignatyev at openjdk.java.net Sat Mar 13 06:44:12 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 13 Mar 2021 06:44:12 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split [v3] In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> Message-ID: > Hi all, > > could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used). > > from JBS: >> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. > > testing: > - [x] `grep ' ClassFileInstaller[^.]` > - [ ] tier1-3 > > Thanks, > -- Igor Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: fix compilation error in IncorrectAOTLibraryTest test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2985/files - new: https://git.openjdk.java.net/jdk/pull/2985/files/ff6d4f91..3a3b7a84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2985/head:pull/2985 PR: https://git.openjdk.java.net/jdk/pull/2985 From iignatyev at openjdk.java.net Sat Mar 13 06:44:13 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 13 Mar 2021 06:44:13 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split [v3] In-Reply-To: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com> References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com> Message-ID: On Sat, 13 Mar 2021 06:16:37 GMT, Ioi Lam wrote: >> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> fix compilation error in IncorrectAOTLibraryTest test > > I did this and scanned the differences (with the diff file from the webrev) and it looks reasonable to me. > > grep '^[+-]' diff.txt | grep -v Copyright | grep -v '^.[+-]' | less > > It looks like most of the changes are mechanical. There were only a few cases where manual changes were made. I trusted that you have tested those cases individually. > > But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other. Hi Ioi, thanks for review this, I ran the whole tier1-3 jobs which should provide enough coverage. as oracle builds don't have AOT feature enabled, I missed a compilation error in `IncorrectAOTLibraryTest` test. the test failed in GitHub action and should be fixed by [3a3b7a8](https://github.com/openjdk/jdk/pull/2985/commits/3a3b7a846289181b466b3c1eb478a0a571d9468b). -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/2985 From iklam at openjdk.java.net Sat Mar 13 07:14:09 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 13 Mar 2021 07:14:09 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split [v3] In-Reply-To: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com> References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com> Message-ID: On Sat, 13 Mar 2021 06:16:37 GMT, Ioi Lam wrote: > But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other. The root cause seems to be https://bugs.openjdk.java.net/browse/CODETOOLS-7902847 ------------- PR: https://git.openjdk.java.net/jdk/pull/2985 From weijun at openjdk.java.net Sat Mar 13 14:15:12 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 13 Mar 2021 14:15:12 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v8] In-Reply-To: References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> Message-ID: On Fri, 12 Mar 2021 16:29:34 GMT, Sean Mullan wrote: >> Weijun Wang 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 15 additional commits since the last revision: >> >> - Merge branch 'master' into 8255255 >> - reapply 8259535: ECDSA SignatureValue do not always have the specified length >> - No more newInstance calls >> - Reapply 8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() >> - Fix test failures >> - Supporting named RSASSA-PSS without parameters >> - Reapply 8008744: Rework part of fix for JDK-6741606 >> - Reapply 8151893: Add security property to configure XML Signature secure validation mode >> >> Reapply 8140353: Improve signature checking >> - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes >> - Reapply 8038913: Bolster XML support (Init.java part) >> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/f285a525...60496847 > > src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 70: > >> 68: * @return the Set of Nodes >> 69: */ >> 70: static Set toNodeSet(Iterator i) { > > Why does `Iterator` cause a warning? It's called at https://github.com/wangweij/jdk/blob/604968474ac20abae1d65a5c00053c76a47c559a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java#L159 where there is no template parameter. ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From dcubed at openjdk.java.net Sat Mar 13 14:23:08 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 13 Mar 2021 14:23:08 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split [v3] In-Reply-To: References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> Message-ID: On Sat, 13 Mar 2021 06:44:12 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used). >> >> from JBS: >>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. >> >> testing: >> - [x] `grep ' ClassFileInstaller[^.]` >> - [ ] tier1-3 >> >> Thanks, >> -- Igor > > Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. I downloaded the patch and used Ioi's cmd pattern to scroll through the changes. I can't honestly say that I looked at every line since 867 changed files would overwhelm anyone's brain... I did notice a couple of `@run main` instead of `@run driver` calls to the ClassFileInstaller, but those are pre-existing. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2985 From iignatyev at openjdk.java.net Sat Mar 13 14:56:07 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 13 Mar 2021 14:56:07 GMT Subject: Integrated: 8263549: 8263412 can cause jtreg testlibrary split In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> Message-ID: <_mpUEh9QVZbxsshQP1hNQlstVSmOwqImgOwhZV4lvIQ=.f49472ae-9d8e-4058-beb8-77e0f7b4fd3a@github.com> On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used). > > from JBS: >> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. > > testing: > - [x] `grep ' ClassFileInstaller[^.]` > - [ ] tier1-3 > > Thanks, > -- Igor This pull request has now been integrated. Changeset: a7aba2b6 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/a7aba2b6 Stats: 1738 lines in 867 files changed: 2 ins; 67 del; 1669 mod 8263549: 8263412 can cause jtreg testlibrary split Reviewed-by: iklam, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/2985 From iignatyev at openjdk.java.net Sat Mar 13 14:56:06 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 13 Mar 2021 14:56:06 GMT Subject: RFR: 8263549: 8263412 can cause jtreg testlibrary split [v3] In-Reply-To: References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com> Message-ID: On Sat, 13 Mar 2021 14:20:20 GMT, Daniel D. Daugherty wrote: >> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > I downloaded the patch and used Ioi's cmd pattern to scroll through > the changes. I can't honestly say that I looked at every line since 867 > changed files would overwhelm anyone's brain... > > I did notice a couple of `@run main` instead of `@run driver` calls > to the ClassFileInstaller, but those are pre-existing. > > Thumbs up. Hi Dan, Thanks for your review! > I did notice a couple of @run main instead of @run driver calls to the ClassFileInstaller, but those are pre-existing. I noticed this too, planning to fix that with a separate RFE. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/2985 From jlaskey at openjdk.java.net Sun Mar 14 14:57:29 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Sun, 14 Mar 2021 14:57:29 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v30] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Review revisions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/e5b87227..ddb1a30c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=29 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=28-29 Stats: 321 lines in 4 files changed: 79 ins; 203 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From shade at openjdk.java.net Mon Mar 15 06:31:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 15 Mar 2021 06:31:08 GMT Subject: Integrated: 8263497: Clean up sun.security.krb5.PrincipalName::toByteArray In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 09:22:40 GMT, Aleksey Shipilev wrote: > SonarCloud actually found this: > Verify this is the index that was intended; it was already set before. > > > public byte[][] toByteArray() { > byte[][] result = new byte[nameStrings.length][]; > for (int i = 0; i < nameStrings.length; i++) { > result[i] = new byte[nameStrings[i].length()]; // <-- here > result[i] = nameStrings[i].getBytes(); > } > return result; > } > > `getBytes()` returns the `byte[]` array, there is no need to allocate the array before it. This pull request has now been integrated. Changeset: 06383033 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/06383033 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8263497: Clean up sun.security.krb5.PrincipalName::toByteArray Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/2962 From github.com+828220+forax at openjdk.java.net Mon Mar 15 08:20:11 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 15 Mar 2021 08:20:11 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3] In-Reply-To: <5IW2VsaVaqCMqkD6qkNxdWpL1qJM8daN1yf9a-Ivxk8=.d15e95c1-183d-4d50-98ff-e112beadf602@github.com> References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com> <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@github.com> <2I2HK8tDFSLtPqs0JFLKLgh3QmMTkM1HKuvKQNmsfIg=.a383a449-18e3-413a-a6ba-91dc80fde86a@github.com> <5IW2VsaVaqCMqkD6qkNxdWpL1qJM8daN1yf9a-Ivxk8=.d15e95c1-183d-4d50-98ff-e112beadf602@github.com> Message-ID: On Wed, 18 Nov 2020 13:45:46 GMT, Jim Laskey wrote: >> Need rebase > > Created new PR because of forced push: https://github.com/openjdk/jdk/pull/1292 LGTM ------------- PR: https://git.openjdk.java.net/jdk/pull/1273 From redestad at openjdk.java.net Mon Mar 15 12:40:16 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 15 Mar 2021 12:40:16 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 20:14:12 GMT, ?????? ??????? wrote: >> Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. >> >> As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. > > Hi @cl4es, >> Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. > > I've checked out Aleksey's branch and applied my changes onto it, the only thing that I changed to make it work is replacing > public boolean isLatin1(String str) { > return str.isLatin1(); > } > with > public boolean isLatin1(String str) { > return str.coder == String.LATIN1; > } > The rest of the code was left intact. `jdk:tier1` is OK after the change. >> As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. > > Apart from `JavaLangAccess` the only thing that comes to my mind is reflection, but it will destroy all the improvement. Otherwise I cannot figure out any other way to access somehow package-private latin/non-latin functionality of `j.l.String` in `java.util` package. I wonder, whether I'm missing any other opportunities? A less intrusive alternative would be to use a `StringBuilder`, see changes in this branch: https://github.com/openjdk/jdk/compare/master...cl4es:stringjoin_improvement?expand=1 (I adapted your StringJoinerBenchmark to work with the ascii-only build constraint) This underperforms compared to your patch since StringBuilder.toString needs to do a copy, but improves over the baseline: Benchmark (count) (length) (mode) Mode Cnt Score Error Units StringJoinerBenchmark.stringJoiner 100 64 latin avgt 5 5420.701 ? 1433.485 ns/op StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm 100 64 latin avgt 5 20640.428 ? 0.130 B/op Patch: Benchmark (count) (length) (mode) Mode Cnt Score Error Units StringJoinerBenchmark.stringJoiner 100 64 latin avgt 5 4271.401 ? 677.560 ns/op StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm 100 64 latin avgt 5 14136.294 ? 0.095 B/op The comparative benefit is that we'd avoid punching more holes into String implementation details for now. Not ruling that out indefinitely, but I think it needs a stronger motivation than to improve StringJoiner alone. ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From jlaskey at openjdk.java.net Mon Mar 15 12:54:32 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 15 Mar 2021 12:54:32 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Missing @since ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/ddb1a30c..9d05aa56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=30 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=29-30 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jboes at openjdk.java.net Mon Mar 15 12:55:11 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 15 Mar 2021 12:55:11 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 > > @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? @turbanoff Given that this PR has been lingering for a while, you could drop the change in `X509CertPath.java` for now and integrate the remaining changes. I'm happy to sponsor in that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+10835776+stsypanov at openjdk.java.net Mon Mar 15 13:56:08 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 15 Mar 2021 13:56:08 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 12:36:24 GMT, Claes Redestad wrote: >> Hi @cl4es, >>> Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. >> >> I've checked out Aleksey's branch and applied my changes onto it, the only thing that I changed to make it work is replacing >> public boolean isLatin1(String str) { >> return str.isLatin1(); >> } >> with >> public boolean isLatin1(String str) { >> return str.coder == String.LATIN1; >> } >> The rest of the code was left intact. `jdk:tier1` is OK after the change. >>> As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. >> >> Apart from `JavaLangAccess` the only thing that comes to my mind is reflection, but it will destroy all the improvement. Otherwise I cannot figure out any other way to access somehow package-private latin/non-latin functionality of `j.l.String` in `java.util` package. I wonder, whether I'm missing any other opportunities? > > A less intrusive alternative would be to use a `StringBuilder`, see changes in this branch: https://github.com/openjdk/jdk/compare/master...cl4es:stringjoin_improvement?expand=1 (I adapted your StringJoinerBenchmark to work with the ascii-only build constraint) > > This underperforms compared to your patch since StringBuilder.toString needs to do a copy, but improves over the baseline: > Benchmark (count) (length) (mode) Mode Cnt Score Error Units > StringJoinerBenchmark.stringJoiner 100 64 latin avgt 5 5420.701 ? 1433.485 ns/op > StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm 100 64 latin avgt 5 20640.428 ? 0.130 B/op > Patch: > Benchmark (count) (length) (mode) Mode Cnt Score Error Units > StringJoinerBenchmark.stringJoiner 100 64 latin avgt 5 4271.401 ? 677.560 ns/op > StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm 100 64 latin avgt 5 14136.294 ? 0.095 B/op > > The comparative benefit is that we'd avoid punching more holes into String implementation details for now. Not ruling that out indefinitely, but I think it needs a stronger motivation than to improve StringJoiner alone. I was thinking about `StringBuilder` at the very beginning but then decided to have no bounds checks and reallocations. Indeed from maintainability point of view your solution is much more attractive. I have one minor comment about `append()`: I think we should do more chaining, e.g. StringBuilder sb = new StringBuilder(len); sb.append(elts[0]); should be StringBuilder sb = new StringBuilder(len).append(elts[0]); etc. to have less bytecode. E.g. if we take public String sb() { StringBuilder sb = new StringBuilder(); sb.append("a"); sb.append("b"); return sb.toString(); } `sb.append()` gets compiled into L1 LINENUMBER 23 L1 ALOAD 1 LDC "a" INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; POP L2 LINENUMBER 24 L2 ALOAD 1 LDC "b" INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; POP ``` and in case we have ``` sb.append("a").append("b"); ``` the amount of byte code is reduced: ``` L1 LINENUMBER 23 L1 ALOAD 1 LDC "a" INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; LDC "b" INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; POP ``` Also I'd change if (addLen == 0) { compactElts(); return size == 0 ? "" : elts[0]; } to if (size == 0) { if (addLen == 0) { return ""; } return prefix + suffix; } The second variant is more understandable to me and likely to be slightly faster. And finally, should I close this PR and you'll create a new one from your branch, or I need to copy your changes here? ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From redestad at openjdk.java.net Mon Mar 15 14:10:09 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 15 Mar 2021 14:10:09 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 13:52:57 GMT, ?????? ??????? wrote: >> A less intrusive alternative would be to use a `StringBuilder`, see changes in this branch: https://github.com/openjdk/jdk/compare/master...cl4es:stringjoin_improvement?expand=1 (I adapted your StringJoinerBenchmark to work with the ascii-only build constraint) >> >> This underperforms compared to your patch since StringBuilder.toString needs to do a copy, but improves over the baseline: >> Benchmark (count) (length) (mode) Mode Cnt Score Error Units >> StringJoinerBenchmark.stringJoiner 100 64 latin avgt 5 5420.701 ? 1433.485 ns/op >> StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm 100 64 latin avgt 5 20640.428 ? 0.130 B/op >> Patch: >> Benchmark (count) (length) (mode) Mode Cnt Score Error Units >> StringJoinerBenchmark.stringJoiner 100 64 latin avgt 5 4271.401 ? 677.560 ns/op >> StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm 100 64 latin avgt 5 14136.294 ? 0.095 B/op >> >> The comparative benefit is that we'd avoid punching more holes into String implementation details for now. Not ruling that out indefinitely, but I think it needs a stronger motivation than to improve StringJoiner alone. > > I was thinking about `StringBuilder` at the very beginning but then decided to have no bounds checks and reallocations. Indeed from maintainability point of view your solution is much more attractive. I have one minor comment about `append()`: I think we should do more chaining, e.g. > StringBuilder sb = new StringBuilder(len); > sb.append(elts[0]); > should be > StringBuilder sb = new StringBuilder(len).append(elts[0]); > etc. to have less bytecode. > > E.g. if we take > public String sb() { > StringBuilder sb = new StringBuilder(); > > sb.append("a"); > sb.append("b"); > > return sb.toString(); > } > `sb.append()` gets compiled into > L1 > LINENUMBER 23 L1 > ALOAD 1 > LDC "a" > INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; > POP > L2 > LINENUMBER 24 L2 > ALOAD 1 > LDC "b" > INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; > POP > ``` > and in case we have > ``` > sb.append("a").append("b"); > ``` > the amount of byte code is reduced: > ``` > L1 > LINENUMBER 23 L1 > ALOAD 1 > LDC "a" > INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; > LDC "b" > INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; > POP > ``` > > Also I'd change > if (addLen == 0) { > compactElts(); > return size == 0 ? "" : elts[0]; > } > to > if (size == 0) { > if (addLen == 0) { > return ""; > } > return prefix + suffix; > } > The second variant is more understandable to me and likely to be slightly faster. > > And finally, should I close this PR and you'll create a new one from your branch, or I need to copy your changes here? Up to you. If you adapt your PR to use a StringBuilder as suggested I can review and sponsor. ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From github.com+741251+turbanoff at openjdk.java.net Mon Mar 15 14:50:24 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Mar 2021 14:50:24 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v13] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy drop changes in X509CertPath ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/1b30471d..96920ee6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11-12 Stats: 25 lines in 1 file changed: 22 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From hohensee at amazon.com Mon Mar 15 17:09:54 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 15 Mar 2021 17:09:54 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: <739B2CF5-1C67-46A8-8C91-3642CD6C9818@amazon.com> The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. Thanks, Paul ?-----Original Message----- From: security-dev on behalf of Daniel Jeli?ski Date: Tuesday, March 9, 2021 at 3:37 PM To: "jdk-updates-dev at openjdk.java.net" Cc: "security-dev at openjdk.java.net" Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Hi, Please review this 11u backport; this is the same patch as for head, except for microbenchmark makefile changes that did not apply because the file doesn't exist in 11u, and the actual microbenchmark, which would only add weight for no benefit. Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 webrev: https://djelinski.github.io/8259886-11u/webrev/index.html Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel From mullan at openjdk.java.net Mon Mar 15 17:48:07 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 15 Mar 2021 17:48:07 GMT Subject: RFR: 8262389: Use permitted_enctypes if default_tkt_enctypes or default_tgs_enctypes is not present In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 20:56:42 GMT, Weijun Wang wrote: > When default_tkt_enctypes or default_tgs_enctypes, use the value of permitted_enctypes if it exists. > > Please also review the CSR at https://bugs.openjdk.java.net/browse/JDK-8262391 and release note at https://bugs.openjdk.java.net/browse/JDK-8262401. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2729 From github.com+10835776+stsypanov at openjdk.java.net Mon Mar 15 18:00:27 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 15 Mar 2021 18:00:27 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v2] In-Reply-To: References: Message-ID: > Hello, > > as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. > > This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. > > As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: > String delimiter = this.delimiter; > char[] chars = new char[this.len + addLen]; > int k = getChars(this.prefix, chars, 0); > if (size > 0) { > k += getChars(elts[0], chars, k); // inflate byte[] > > for(int i = 1; i < size; ++i) { > k += getChars(delimiter, chars, k); > k += getChars(elts[i], chars, k); > } > } > > k += getChars(this.suffix, chars, k); > return new String(chars); // compress char[] -> byte[] > This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) > covering both cases when resulting String is Latin1 or UTF-16 > > I've prepared a patch along with benchmark proving that this change is correct and brings improvement. > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class StringJoinerBenchmark { > > @Benchmark > public String stringJoiner(Data data) { > String[] stringArray = data.stringArray; > return Joiner.joinWithStringJoiner(stringArray); > } > > @State(Scope.Thread) > public static class Data { > > @Param({"latin", "cyrillic", "mixed"}) > private String mode; > > @Param({"8", "32", "64"}) > private int length; > > @Param({"5", "10", "100"}) > private int count; > > private String[] stringArray; > > @Setup > public void setup() { > RandomStringGenerator generator = new RandomStringGenerator(); > > stringArray = new String[count]; > > for (int i = 0; i < count; i++) { > String alphabet = getAlphabet(i, mode); > stringArray[i] = generator.randomString(alphabet, length); > } > } > > private static String getAlphabet(int index, String mode) { > var latin = "abcdefghijklmnopqrstuvwxyz"; //English > var cyrillic = "????????????????????????????????"; // Russian > > String alphabet; > switch (mode) { > case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; > case "latin" -> alphabet = latin; > case "cyrillic" -> alphabet = cyrillic; > default -> throw new RuntimeException("Illegal mode " + mode); > } > return alphabet; > } > } > } > > public class Joiner { > > public static String joinWithStringJoiner(String[] stringArray) { > StringJoiner joiner = new StringJoiner(",", "[", "]"); > for (String str : stringArray) { > joiner.add(str); > } > return joiner.toString(); > } > } > > > (count) (length) (mode) Java 14 patched Units > stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op > stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op > stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op > stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op > stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op > stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op > stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op > stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op > stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op > stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op > stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op > stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op > stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op > stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op > stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op > stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op > stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op > stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op > stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op > stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op > stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op > stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op > stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op > stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op > stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op > stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op > stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op > > stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - 8148937: (str) Use StringBuilder as cl4es suggests - 8148937: (str) Check also delimiter, prefix and suffix - 8148937: (str) Adapt StringJoiner for Compact Strings ------------- Changes: https://git.openjdk.java.net/jdk/pull/2627/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2627&range=01 Stats: 135 lines in 2 files changed: 114 ins; 10 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2627/head:pull/2627 PR: https://git.openjdk.java.net/jdk/pull/2627 From akozlov at openjdk.java.net Mon Mar 15 18:23:35 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Mar 2021 18:23:35 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v28] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits: - JDK-8262491: bsd_aarch64 part - JDK-8263002: bsd_aarch64 part - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Wider #ifdef block - Fix most of issues in java/foreign/ tests Failures related to va_args are tracked in JDK-8263512. - Add Azul copyright - Update Oracle copyright years - Use Thread::current_or_null_safe in SafeFetch - 8262903: [macos_aarch64] Thread::current() called on detached thread - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=27 Stats: 2949 lines in 75 files changed: 2839 ins; 27 del; 83 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+10835776+stsypanov at openjdk.java.net Mon Mar 15 18:51:11 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 15 Mar 2021 18:51:11 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 14:07:29 GMT, Claes Redestad wrote: >> I was thinking about `StringBuilder` at the very beginning but then decided to have no bounds checks and reallocations. Indeed from maintainability point of view your solution is much more attractive. I have one minor comment about `append()`: I think we should do more chaining, e.g. >> StringBuilder sb = new StringBuilder(len); >> sb.append(elts[0]); >> should be >> StringBuilder sb = new StringBuilder(len).append(elts[0]); >> etc. to have less bytecode. >> >> E.g. if we take >> public String sb() { >> StringBuilder sb = new StringBuilder(); >> >> sb.append("a"); >> sb.append("b"); >> >> return sb.toString(); >> } >> `sb.append()` gets compiled into >> L1 >> LINENUMBER 23 L1 >> ALOAD 1 >> LDC "a" >> INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; >> POP >> L2 >> LINENUMBER 24 L2 >> ALOAD 1 >> LDC "b" >> INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; >> POP >> ``` >> and in case we have >> ``` >> sb.append("a").append("b"); >> ``` >> the amount of byte code is reduced: >> ``` >> L1 >> LINENUMBER 23 L1 >> ALOAD 1 >> LDC "a" >> INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; >> LDC "b" >> INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; >> POP >> ``` >> >> Also I'd change >> if (addLen == 0) { >> compactElts(); >> return size == 0 ? "" : elts[0]; >> } >> to >> if (size == 0) { >> if (addLen == 0) { >> return ""; >> } >> return prefix + suffix; >> } >> The second variant is more understandable to me and likely to be slightly faster. >> >> And finally, should I close this PR and you'll create a new one from your branch, or I need to copy your changes here? > > Up to you. If you adapt your PR to use a StringBuilder as suggested I can review and sponsor. I'll reuse existing PR then. ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From jboes at openjdk.java.net Mon Mar 15 18:52:17 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 15 Mar 2021 18:52:17 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: <4Bae_Uh8Zakn4cnmbXkUcV9xRTus1hgHCEPVthHuEyc=.fb959963-ff7a-4067-b888-e178d9f70e91@github.com> On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 > > @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? @turbanoff Tier 1-3 still all clear. If you /integrate, I will sponsor this tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From akozlov at openjdk.java.net Mon Mar 15 18:56:18 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Mar 2021 18:56:18 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com> References: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com> Message-ID: On Thu, 11 Mar 2021 20:27:51 GMT, Stefan Karlsson wrote: >> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. >> >> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR. > > Good point about Thread vs JavaThread. Yes, this can be looked into as follow-up cleanups. The enhancement is tracked in https://bugs.openjdk.java.net/browse/JDK-8263492 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Mar 15 18:56:17 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Mar 2021 18:56:17 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21] In-Reply-To: References: Message-ID: <4EryfweVy9Q97cbm7rAcsSIXuK2XImbIfuPeloJuXEA=.90a1f396-299c-43d2-922b-9af36ca43467@github.com> On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley wrote: >> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro? > > Robustness, clarity, maintainability, convention. Why not? I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`). The rest of the defines in this file follows the pattern: a define without a value to be checked with `#ifdef` and define with a value to be checked with `#if`. To be consistent, I would need to add `#define R18_RESERVED false` to the `#else` clause and change every `#ifdef R18_RESERVED`/`#ifndef R18_RESERVED` to `#if R18_RESERVED`/`#if !R18_RESERVED`. I think we'll win in clarity in the long term if I will not implement the suggestion without related changes. (And related changes would introduce additional noise, which we are fighting with). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Mar 15 18:56:23 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Mar 2021 18:56:23 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v28] In-Reply-To: References: Message-ID: <0dFnMCcGeahDTezdMqNQ2ZtipjeEaCpNezow6Kqy5xE=.ec72c0d8-8252-4abf-ab7a-8ce4b89ca527@github.com> On Sat, 13 Mar 2021 05:49:53 GMT, David Holmes wrote: >> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits: >> >> - JDK-8262491: bsd_aarch64 part >> - JDK-8263002: bsd_aarch64 part >> - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos >> - Wider #ifdef block >> - Fix most of issues in java/foreign/ tests >> >> Failures related to va_args are tracked in JDK-8263512. >> - Add Azul copyright >> - Update Oracle copyright years >> - Use Thread::current_or_null_safe in SafeFetch >> - 8262903: [macos_aarch64] Thread::current() called on detached thread >> - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos >> - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618 > > src/hotspot/share/runtime/safefetch.inline.hpp line 35: > >> 33: inline int SafeFetch32(int* adr, int errValue) { >> 34: assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated"); >> 35: Thread* thread = Thread::current_or_null_safe(); > > Sorry but this should be MACOS_AARCH64 only. All three lines need to be ifdef'd if you are going to include the assertion. > > Thanks, > David Right, thanks! Fixed in https://github.com/openjdk/jdk/pull/2200/commits/3d0f4d2342adc867eaf762fa83a9c3035d6439bd ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From valeriep at openjdk.java.net Mon Mar 15 20:45:17 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 15 Mar 2021 20:45:17 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes Message-ID: Can someone help review this somewhat trivial change? Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. Thanks, Valerie ------------- Commit messages: - 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes Changes: https://git.openjdk.java.net/jdk/pull/3018/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3018&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260274 Stats: 241 lines in 7 files changed: 220 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3018/head:pull/3018 PR: https://git.openjdk.java.net/jdk/pull/3018 From psandoz at openjdk.java.net Mon Mar 15 20:48:12 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 15 Mar 2021 20:48:12 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com> References: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com> Message-ID: On Fri, 26 Feb 2021 13:15:28 GMT, R?mi Forax wrote: >> Looking for some final code reviews. > > I still don't like the fact that the factory uses reflection but i don't see how to do better This is now looking very nicely structured. The only thing i am unsure are the details around `RandomGenerator` being a service provider interface. The documentation mentions this at various points (mostly as implementation notes), but it's not really called out on `RandomGenerator`. Trying out the patch, I can implement `RandomGenerator` and register it as a service: public class AlwaysZero implements RandomGenerator { @Override public long nextLong() { return 0; } } ... RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero"); Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not public). If i rename the above to `L32X64MixRandom` an `ExceptionInInitializerError` is produced due to duplicate keys. I suspect you want to filter out the service providers to those that only declare `RandomGeneratorProperties`, thereby restricting to providers only supplied by the platform. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From redestad at openjdk.java.net Mon Mar 15 20:58:10 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 15 Mar 2021 20:58:10 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v2] In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 18:00:27 GMT, ?????? ??????? wrote: >> Hello, >> >> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. >> >> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. >> >> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: >> String delimiter = this.delimiter; >> char[] chars = new char[this.len + addLen]; >> int k = getChars(this.prefix, chars, 0); >> if (size > 0) { >> k += getChars(elts[0], chars, k); // inflate byte[] >> >> for(int i = 1; i < size; ++i) { >> k += getChars(delimiter, chars, k); >> k += getChars(elts[i], chars, k); >> } >> } >> >> k += getChars(this.suffix, chars, k); >> return new String(chars); // compress char[] -> byte[] >> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) >> covering both cases when resulting String is Latin1 or UTF-16 >> >> I've prepared a patch along with benchmark proving that this change is correct and brings improvement. >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class StringJoinerBenchmark { >> >> @Benchmark >> public String stringJoiner(Data data) { >> String[] stringArray = data.stringArray; >> return Joiner.joinWithStringJoiner(stringArray); >> } >> >> @State(Scope.Thread) >> public static class Data { >> >> @Param({"latin", "cyrillic", "mixed"}) >> private String mode; >> >> @Param({"8", "32", "64"}) >> private int length; >> >> @Param({"5", "10", "100"}) >> private int count; >> >> private String[] stringArray; >> >> @Setup >> public void setup() { >> RandomStringGenerator generator = new RandomStringGenerator(); >> >> stringArray = new String[count]; >> >> for (int i = 0; i < count; i++) { >> String alphabet = getAlphabet(i, mode); >> stringArray[i] = generator.randomString(alphabet, length); >> } >> } >> >> private static String getAlphabet(int index, String mode) { >> var latin = "abcdefghijklmnopqrstuvwxyz"; //English >> var cyrillic = "????????????????????????????????"; // Russian >> >> String alphabet; >> switch (mode) { >> case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; >> case "latin" -> alphabet = latin; >> case "cyrillic" -> alphabet = cyrillic; >> default -> throw new RuntimeException("Illegal mode " + mode); >> } >> return alphabet; >> } >> } >> } >> >> public class Joiner { >> >> public static String joinWithStringJoiner(String[] stringArray) { >> StringJoiner joiner = new StringJoiner(",", "[", "]"); >> for (String str : stringArray) { >> joiner.add(str); >> } >> return joiner.toString(); >> } >> } >> >> >> (count) (length) (mode) Java 14 patched Units >> stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op >> stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op >> stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op >> stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op >> stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op >> stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op >> stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op >> stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op >> stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op >> stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op >> stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op >> stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op >> stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op >> stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op >> stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op >> stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op >> stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op >> stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op >> stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op >> stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op >> stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op >> stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op >> stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op >> stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op >> stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op >> stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op >> stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op >> >> stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - 8148937: (str) Use StringBuilder as cl4es suggests > - 8148937: (str) Check also delimiter, prefix and suffix > - 8148937: (str) Adapt StringJoiner for Compact Strings The copyright year and description of the microbenchmark needs to be updated (my copy-paste error). I'd also consider narrowing down the parameter combinations and iteration times so that default execution times is more reasonable (currently ~45 minutes even though these micros stabilize in seconds) ------------- Changes requested by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2627 From ascarpino at openjdk.java.net Mon Mar 15 20:59:06 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 15 Mar 2021 20:59:06 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: Message-ID: <1HK6D7T1pefJ7ayAvwUYeQu-CqCZLkkVNC_4zX7ILCA=.c4289e81-557b-4982-a290-7c6293ed69af@github.com> On Mon, 15 Mar 2021 20:39:13 GMT, Valerie Peng wrote: > Can someone help review this somewhat trivial change? > > Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. > Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. > > Thanks, > Valerie >From a performance standpoint, having a single synchronized block on every init() operations is going to slow things down ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From xuelei at openjdk.java.net Mon Mar 15 20:59:09 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 15 Mar 2021 20:59:09 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: Message-ID: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> On Mon, 15 Mar 2021 20:39:13 GMT, Valerie Peng wrote: > Can someone help review this somewhat trivial change? > > Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. > Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. > > Thanks, > Valerie src/java.base/share/classes/sun/security/jca/JCAUtil.java line 62: > 60: private static SecureRandom instance = new SecureRandom(); > 61: public static SecureRandom instance(boolean checkConfig) { > 62: synchronized (CachedSecureRandomHolder.class) { Is there a performance regression because of this synchronization? ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From valeriep at openjdk.java.net Mon Mar 15 21:08:09 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 15 Mar 2021 21:08:09 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> Message-ID: On Mon, 15 Mar 2021 20:55:24 GMT, Xue-Lei Andrew Fan wrote: >> Can someone help review this somewhat trivial change? >> >> Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. >> Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. >> >> Thanks, >> Valerie > > src/java.base/share/classes/sun/security/jca/JCAUtil.java line 62: > >> 60: private static SecureRandom instance = new SecureRandom(); >> 61: public static SecureRandom instance(boolean checkConfig) { >> 62: synchronized (CachedSecureRandomHolder.class) { > > Is there a performance regression because of this synchronization? It depends, this may not be a "hot area" where there is a lot of contention? Or do you feel maybe we should just go with the slower "new SecureRandom()" call for each affected class? I am on the fence actually. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From ascarpino at openjdk.java.net Mon Mar 15 21:34:08 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 15 Mar 2021 21:34:08 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> Message-ID: <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> On Mon, 15 Mar 2021 21:05:36 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/jca/JCAUtil.java line 62: >> >>> 60: private static SecureRandom instance = new SecureRandom(); >>> 61: public static SecureRandom instance(boolean checkConfig) { >>> 62: synchronized (CachedSecureRandomHolder.class) { >> >> Is there a performance regression because of this synchronization? > > It depends, this may not be a "hot area" where there is a lot of contention? Or do you feel maybe we should just go with the slower "new SecureRandom()" call for each affected class? I am on the fence actually. Since 5 classes have init() calls that would be acquiring this lock, something that could be independent would be better. Calling "new SecureRandom()" may or may not be better, but hope it wouldn't lock over operations during creation. I'm just throwing out an idea: Can the provider index number be verify in the list each time? Better yet, maybe a way to have this triggered each time a provider is added or removed from the list? ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From xuelei at openjdk.java.net Mon Mar 15 21:39:05 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 15 Mar 2021 21:39:05 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> Message-ID: On Mon, 15 Mar 2021 21:31:12 GMT, Anthony Scarpino wrote: >> It depends, this may not be a "hot area" where there is a lot of contention? Or do you feel maybe we should just go with the slower "new SecureRandom()" call for each affected class? I am on the fence actually. > > Since 5 classes have init() calls that would be acquiring this lock, something that could be independent would be better. Calling "new SecureRandom()" may or may not be better, but hope it wouldn't lock over operations during creation. > > I'm just throwing out an idea: > Can the provider index number be verify in the list each time? > > Better yet, maybe a way to have this triggered each time a provider is added or removed from the list? Cipher and KeyPairGenerator could be used a lot in TLS context. The synchronization may impact in some circumstances. Supporting dynamic configuration could be error-prone. For example, one thread to set the providers, and another thread get the providers by calling Cipher.init(). Unless the set and get use the same lock, the return value of the get method is not predictable. The lock here is on CachedSecureRandomHolder for providers configuration getting, and no lock (or different lock) for providers configuration setting. So applications may be able to get the expected behaviors by introducing this synchronization. As this behavior has been a while, I may not update the implementation. Instead, I would like to add an "implNote" tag to state that once the default provider is loaded, an implementation may be changed it any longer. Applications could use provider parameter if there is a preference. If you want go ahead, maybe the performance impacted could be mitigated by locking less processes. For example: if (checkConfig) { Provider[] currConfig = Security.getProviders(); if (!Arrays.equals(cachedConfig, currConfig)) { synchronized (CachedSecureRandomHolder.class) { // double check the currConfig currConfig = Security.getProviders(); if (!Arrays.equals(cachedConfig, currConfig)) { instance = ... cachedConfig = ... } } } } return instance; However, I still not very sure of the performance of Security.getProviders() because it is synchronized as well. Further, I may want to evaluate if the update of Security provider (for example Providers.setProviderList) could trigger an even to update the default instances. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From valeriep at openjdk.java.net Mon Mar 15 21:34:10 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 15 Mar 2021 21:34:10 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec In-Reply-To: <2KLmEc8838CzSSDp6hqaphYT_k2inBBhkGB_9eJc04I=.9ca5b175-01a3-4730-a393-f3887f659d73@github.com> References: <2KLmEc8838CzSSDp6hqaphYT_k2inBBhkGB_9eJc04I=.9ca5b175-01a3-4730-a393-f3887f659d73@github.com> Message-ID: On Sat, 13 Mar 2021 00:37:41 GMT, SalusaSecondus wrote: >> I still cannot understand why CRT is always preferred. The original implementation also hadn't done that. > > I believe that the original implementation intended to do this but made a mistake. This is why the original implementation (with the backwards `isAssignableFrom` logic) first checked to see if it could use CRT (as it had more information) and only afterwards fell back to seeing if it could use `RSAPrivateKeySpec`. > > RSA CRT keys are much more efficient than normal RSA private keys and also result in more a more standard compliant output when serialized to PKCS#8 format (which technically requires the CRT parameters to be present). Thus, I believe we should try to preserve the CRT parameters whenever possible for our users. Now users who request an `RSAPrivateKeySpec` and then use it to later create a new key (using `KeyFactory.generatePrivate`) can keep the significant performance benefits for that private key. P11RSAKeyFactory.java should also be included into this fix as it's subject to the same RSAPrivateKeySpec vs RSAPrivateCrtKeySpec issue. My personal take is that the isAssignableFrom() call may be more for checking if both keyspecs are the same. If the original impl (pre-8254717 code) really intend to return RSAPrivateCrtKeySpec for RSAPrivateCrtKey objs, then it should just check key type to be CRT and no need to call isAssignableFrom() with both RSAPrivateCrtKeySpec AND RSAPrivateKeySpec, just check the later would suffice. Thus, I'd argue the original intention is to return the keyspec matching the requested keyspec class. I can see the potential performance benefit of piggybacking the Crt info and generating Crt keys when RSAPrivateKeySpec is specified. However, the way it is coded in this PR seems a bit unclear. The InvalidKeySpecException definitely must be fixed. As for the RSAPrivateKeySpec->RSAPrivateCrtKeySpec change, it's a change of behavior comparing to pre-8254717 code which I am ok with if we can be sure that there is no undesirable side-effects. ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From valeriep at openjdk.java.net Mon Mar 15 21:43:15 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 15 Mar 2021 21:43:15 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v2] In-Reply-To: References: Message-ID: <8rVOlonoFd_A0BE2-lYBfsvpWRZI-pVH9j-or1Zd7xQ=.9349d8ab-aa3c-460a-99f4-4d205cae3588@github.com> On Fri, 12 Mar 2021 22:00:18 GMT, Ziyi Luo wrote: >> This is a P2 regression introduced by JDK-8254717. >> >> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: >> >> X-axis: type of `keySpec` >> Y-axis: type of `key` >> >> Before JDK-8254717: >> >> | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | >> |--|--|--| >> | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | >> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | >> >> After JDK-8254717 (Green check is what we want to fix, red cross is the regression): >> >> | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | >> |--|--|--| >> | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | >> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | >> >> This commit fixes the regression. >> >> >> ### Tests >> >> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed >> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed > > Ziyi Luo has updated the pull request incrementally with one additional commit since the last revision: > > Add one test case for the regression fixed by 8263404 test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 80: > 78: // === Case 1: private key is RSAPrivateCrtKey, expected spec is RSAPrivateKeySpec > 79: // === Expected: return RSAPrivateCrtKeySpec > 80: // Since RSAPrivateCrtKeySpec inherits from RSAPrivateKeySpec, we'd expect this next line to return an instance of RSAPrivateKeySpec Typo? I think you mean RSAPrivateCrtKeySpec? test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 83: > 81: // (because the private key has CRT parts). > 82: KeySpec spec = factory.getKeySpec(pair.getPrivate(), RSAPrivateKeySpec.class); > 83: if (!(spec instanceof RSAPrivateCrtKeySpec)) { The generated key is implementation specific, you should check the key type before checking the returned key spec? test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 99: > 97: // InvalidKeySpecException should not be thrown > 98: KeySpec notCrtSpec = factory.getKeySpec(notCrtKey, RSAPrivateKeySpec.class); > 99: if (notCrtSpec instanceof RSAPrivateCrtKeySpec) { Just to be safe, check the returned keyspec is RSAPrivateKeySpec? ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From github.com+829871+salusasecondus at openjdk.java.net Mon Mar 15 21:43:16 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Mon, 15 Mar 2021 21:43:16 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v2] In-Reply-To: <8rVOlonoFd_A0BE2-lYBfsvpWRZI-pVH9j-or1Zd7xQ=.9349d8ab-aa3c-460a-99f4-4d205cae3588@github.com> References: <8rVOlonoFd_A0BE2-lYBfsvpWRZI-pVH9j-or1Zd7xQ=.9349d8ab-aa3c-460a-99f4-4d205cae3588@github.com> Message-ID: On Mon, 15 Mar 2021 21:35:16 GMT, Valerie Peng wrote: >> Ziyi Luo has updated the pull request incrementally with one additional commit since the last revision: >> >> Add one test case for the regression fixed by 8263404 > > test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 80: > >> 78: // === Case 1: private key is RSAPrivateCrtKey, expected spec is RSAPrivateKeySpec >> 79: // === Expected: return RSAPrivateCrtKeySpec >> 80: // Since RSAPrivateCrtKeySpec inherits from RSAPrivateKeySpec, we'd expect this next line to return an instance of RSAPrivateKeySpec > > Typo? I think you mean RSAPrivateCrtKeySpec? Yup. Thank you for the catch. > test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 83: > >> 81: // (because the private key has CRT parts). >> 82: KeySpec spec = factory.getKeySpec(pair.getPrivate(), RSAPrivateKeySpec.class); >> 83: if (!(spec instanceof RSAPrivateCrtKeySpec)) { > > The generated key is implementation specific, you should check the key type before checking the returned key spec? How about we specifically use the ` SunRsaSign` provider then (which does generate an `RSAPrivateCrtKey`)? ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From github.com+10835776+stsypanov at openjdk.java.net Mon Mar 15 21:47:28 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 15 Mar 2021 21:47:28 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v3] In-Reply-To: References: Message-ID: > Hello, > > as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. > > This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. > > As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: > String delimiter = this.delimiter; > char[] chars = new char[this.len + addLen]; > int k = getChars(this.prefix, chars, 0); > if (size > 0) { > k += getChars(elts[0], chars, k); // inflate byte[] > > for(int i = 1; i < size; ++i) { > k += getChars(delimiter, chars, k); > k += getChars(elts[i], chars, k); > } > } > > k += getChars(this.suffix, chars, k); > return new String(chars); // compress char[] -> byte[] > This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) > covering both cases when resulting String is Latin1 or UTF-16 > > I've prepared a patch along with benchmark proving that this change is correct and brings improvement. > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class StringJoinerBenchmark { > > @Benchmark > public String stringJoiner(Data data) { > String[] stringArray = data.stringArray; > return Joiner.joinWithStringJoiner(stringArray); > } > > @State(Scope.Thread) > public static class Data { > > @Param({"latin", "cyrillic", "mixed"}) > private String mode; > > @Param({"8", "32", "64"}) > private int length; > > @Param({"5", "10", "100"}) > private int count; > > private String[] stringArray; > > @Setup > public void setup() { > RandomStringGenerator generator = new RandomStringGenerator(); > > stringArray = new String[count]; > > for (int i = 0; i < count; i++) { > String alphabet = getAlphabet(i, mode); > stringArray[i] = generator.randomString(alphabet, length); > } > } > > private static String getAlphabet(int index, String mode) { > var latin = "abcdefghijklmnopqrstuvwxyz"; //English > var cyrillic = "????????????????????????????????"; // Russian > > String alphabet; > switch (mode) { > case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; > case "latin" -> alphabet = latin; > case "cyrillic" -> alphabet = cyrillic; > default -> throw new RuntimeException("Illegal mode " + mode); > } > return alphabet; > } > } > } > > public class Joiner { > > public static String joinWithStringJoiner(String[] stringArray) { > StringJoiner joiner = new StringJoiner(",", "[", "]"); > for (String str : stringArray) { > joiner.add(str); > } > return joiner.toString(); > } > } > > > (count) (length) (mode) Java 14 patched Units > stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op > stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op > stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op > stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op > stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op > stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op > stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op > stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op > stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op > stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op > stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op > stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op > stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op > stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op > stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op > stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op > stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op > stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op > stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op > stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op > stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op > stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op > stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op > stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op > stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op > stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op > stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op > > stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8148937: (str) Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2627/files - new: https://git.openjdk.java.net/jdk/pull/2627/files/e0d7d122..b600ea62 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2627&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2627&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2627/head:pull/2627 PR: https://git.openjdk.java.net/jdk/pull/2627 From github.com+10835776+stsypanov at openjdk.java.net Mon Mar 15 21:47:31 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 15 Mar 2021 21:47:31 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v2] In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 20:54:54 GMT, Claes Redestad wrote: >> ?????? ??????? 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: >> >> - 8148937: (str) Use StringBuilder as cl4es suggests >> - 8148937: (str) Check also delimiter, prefix and suffix >> - 8148937: (str) Adapt StringJoiner for Compact Strings > > The copyright year and description of the microbenchmark needs to be updated (my copy-paste error). I'd also consider narrowing down the parameter combinations and iteration times so that default execution times is more reasonable (currently ~45 minutes even though these micros stabilize in seconds) Done. I've removed mixed mode from benchmark, anyway it falls back to non-latin1 case ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From github.com+829871+salusasecondus at openjdk.java.net Mon Mar 15 21:59:08 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Mon, 15 Mar 2021 21:59:08 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec In-Reply-To: References: <2KLmEc8838CzSSDp6hqaphYT_k2inBBhkGB_9eJc04I=.9ca5b175-01a3-4730-a393-f3887f659d73@github.com> Message-ID: On Mon, 15 Mar 2021 21:30:57 GMT, Valerie Peng wrote: > P11RSAKeyFactory.java should also be included into this fix as it's subject to the same RSAPrivateKeySpec vs RSAPrivateCrtKeySpec issue. Thank you. We'll fix this. > > My personal take is that the isAssignableFrom() call may be more for checking if both keyspecs are the same. If the original impl (pre-8254717 code) really intend to return RSAPrivateCrtKeySpec for RSAPrivateCrtKey objs, then it should just check key type to be CRT and no need to call isAssignableFrom() with both RSAPrivateCrtKeySpec AND RSAPrivateKeySpec, just check the later would suffice. Thus, I'd argue the original intention is to return the keyspec matching the requested keyspec class. I wondered this too, but if that were the case, I'd expect to see `RSA_PRIVCRT_KEYSPEC_CLS.equals(keySpec)` instead. It seems more likely that the code is just trying to ensure that some valid implementation of the KeySpec is returned rather than the specific one. > I can see the potential performance benefit of piggybacking the Crt info and generating Crt keys when RSAPrivateKeySpec is specified. However, the way it is coded in this PR seems a bit unclear. The InvalidKeySpecException definitely must be fixed. As for the RSAPrivateKeySpec->RSAPrivateCrtKeySpec change, it's a change of behavior comparing to pre-8254717 code which I am ok with if we can be sure that there is no undesirable side-effects. I'm definitely up for ways to make this clearer. I'll ensure that the next version has some better comments to explain the logic flow so that future us doesn't need to guess about original intent in the way we are now. I agree that this should be a safe change. Outside of some extremely sensitive unit tests (which is how I discovered this bug in the first place), I don't expect much code to depend on the *exact* class returned by this method. (Any code doing so would be wrong as well, but we still need to pay attention to it.) We can see similar behavior elsewhere in the JDK where a more specialized class is returned by a method similar to this. AlgorithmParameters params = AlgorithmParameters.getInstance("EC"); params.init(new ECGenParameterSpec("secp256r1")); ECParameterSpec spec = params.getParameterSpec(ECParameterSpec.class); System.out.println(spec); System.out.println(spec.getClass()); In this case we can see that [EcParameters](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/ECParameters.java#L201) returns an instance of the private class `sun.security.util.NamedCurve` specifically to preserve additional information about the parameters for later use within the JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From github.com+829871+salusasecondus at openjdk.java.net Mon Mar 15 22:15:15 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Mon, 15 Mar 2021 22:15:15 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> Message-ID: On Mon, 15 Mar 2021 21:36:08 GMT, Xue-Lei Andrew Fan wrote: >> Since 5 classes have init() calls that would be acquiring this lock, something that could be independent would be better. Calling "new SecureRandom()" may or may not be better, but hope it wouldn't lock over operations during creation. >> >> I'm just throwing out an idea: >> Can the provider index number be verify in the list each time? >> >> Better yet, maybe a way to have this triggered each time a provider is added or removed from the list? > > Cipher and KeyPairGenerator could be used a lot in TLS context. The synchronization may impact in some circumstances. Supporting dynamic configuration could be error-prone. For example, one thread to set the providers, and another thread get the providers by calling Cipher.init(). Unless the set and get use the same lock, the return value of the get method is not predictable. The lock here is on CachedSecureRandomHolder for providers configuration getting, and no lock (or different lock) for providers configuration setting. So applications may be able to get the expected behaviors by introducing this synchronization. > > As this behavior has been a while, I may not update the implementation. Instead, I would like to add an "implNote" tag to state that once the default provider is loaded, an implementation may be changed it any longer. Applications could use provider parameter if there is a preference. > > If you want go ahead, maybe the performance impacted could be mitigated by locking less processes. For example: > > if (checkConfig) { > Provider[] currConfig = Security.getProviders(); > if (!Arrays.equals(cachedConfig, currConfig)) { > synchronized (CachedSecureRandomHolder.class) { > // double check the currConfig > currConfig = Security.getProviders(); > if (!Arrays.equals(cachedConfig, currConfig)) { > instance = ... > cachedConfig = ... > } > } > } > } > return instance; > > However, I still not very sure of the performance of Security.getProviders() because it is synchronized as well. Further, I may want to evaluate if the update of Security provider (for example Providers.setProviderList) could trigger an even to update the default instances. I would definitely not call `new SecureRandom()` each time as that can have real performance problems (especially on systems which pull from `/dev/random` and may not have hardware entropy). The synchronization worries me too. Could `java.security.Security` contain a "provider version" `int` (volatile, atomic, or similar) which is incremented every time the provider list is changed? Then this class (clearly using some non-public API) would check that value and if it is the same, just return the cached instance. If it has changed since the last time, then it would update `instance` and its remembered value of the index. I think that we might be able to do it without taking any locks in this class because even if the providers change out from under us, we returned a reasonable value (subject to multi-threading) and will fix things up when we're called the next time. // using this and name collision to highlight what's a field and what's local int providerListVersion = Security.nonPublicGetProviderListVersion(); if (this.providerListVersion != providerListVersion) { this.providerListVersion = providerListVersion; this.instance = new SecureRandom(); } return this.instance; ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From redestad at openjdk.java.net Mon Mar 15 22:28:09 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 15 Mar 2021 22:28:09 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v3] In-Reply-To: References: Message-ID: <1XB3J7cc36ryVjr0mAqJNXi4qkzoEPvv6epleEvJGTs=.df2d2d20-97f1-437a-87df-ee7c74dfae68@github.com> On Mon, 15 Mar 2021 21:47:28 GMT, ?????? ??????? wrote: >> Hello, >> >> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. >> >> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. >> >> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: >> String delimiter = this.delimiter; >> char[] chars = new char[this.len + addLen]; >> int k = getChars(this.prefix, chars, 0); >> if (size > 0) { >> k += getChars(elts[0], chars, k); // inflate byte[] >> >> for(int i = 1; i < size; ++i) { >> k += getChars(delimiter, chars, k); >> k += getChars(elts[i], chars, k); >> } >> } >> >> k += getChars(this.suffix, chars, k); >> return new String(chars); // compress char[] -> byte[] >> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) >> covering both cases when resulting String is Latin1 or UTF-16 >> >> I've prepared a patch along with benchmark proving that this change is correct and brings improvement. >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class StringJoinerBenchmark { >> >> @Benchmark >> public String stringJoiner(Data data) { >> String[] stringArray = data.stringArray; >> return Joiner.joinWithStringJoiner(stringArray); >> } >> >> @State(Scope.Thread) >> public static class Data { >> >> @Param({"latin", "cyrillic", "mixed"}) >> private String mode; >> >> @Param({"8", "32", "64"}) >> private int length; >> >> @Param({"5", "10", "100"}) >> private int count; >> >> private String[] stringArray; >> >> @Setup >> public void setup() { >> RandomStringGenerator generator = new RandomStringGenerator(); >> >> stringArray = new String[count]; >> >> for (int i = 0; i < count; i++) { >> String alphabet = getAlphabet(i, mode); >> stringArray[i] = generator.randomString(alphabet, length); >> } >> } >> >> private static String getAlphabet(int index, String mode) { >> var latin = "abcdefghijklmnopqrstuvwxyz"; //English >> var cyrillic = "????????????????????????????????"; // Russian >> >> String alphabet; >> switch (mode) { >> case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; >> case "latin" -> alphabet = latin; >> case "cyrillic" -> alphabet = cyrillic; >> default -> throw new RuntimeException("Illegal mode " + mode); >> } >> return alphabet; >> } >> } >> } >> >> public class Joiner { >> >> public static String joinWithStringJoiner(String[] stringArray) { >> StringJoiner joiner = new StringJoiner(",", "[", "]"); >> for (String str : stringArray) { >> joiner.add(str); >> } >> return joiner.toString(); >> } >> } >> >> >> (count) (length) (mode) Java 14 patched Units >> stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op >> stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op >> stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op >> stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op >> stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op >> stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op >> stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op >> stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op >> stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op >> stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op >> stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op >> stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op >> stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op >> stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op >> stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op >> stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op >> stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op >> stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op >> stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op >> stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op >> stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op >> stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op >> stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op >> stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op >> stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op >> stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op >> stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op >> >> stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8148937: (str) Update copyright year Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From luoziyi at openjdk.java.net Mon Mar 15 23:05:08 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Mon, 15 Mar 2021 23:05:08 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v2] In-Reply-To: References: <8rVOlonoFd_A0BE2-lYBfsvpWRZI-pVH9j-or1Zd7xQ=.9349d8ab-aa3c-460a-99f4-4d205cae3588@github.com> Message-ID: On Mon, 15 Mar 2021 21:37:59 GMT, SalusaSecondus wrote: >> test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 80: >> >>> 78: // === Case 1: private key is RSAPrivateCrtKey, expected spec is RSAPrivateKeySpec >>> 79: // === Expected: return RSAPrivateCrtKeySpec >>> 80: // Since RSAPrivateCrtKeySpec inherits from RSAPrivateKeySpec, we'd expect this next line to return an instance of RSAPrivateKeySpec >> >> Typo? I think you mean RSAPrivateCrtKeySpec? > > Yup. Thank you for the catch. This is not a typo but I found the sentence very confusing. I'll update the comment. What I meant: `keySpec` is RSAPrivateKeySpec ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From darcy at openjdk.java.net Mon Mar 15 23:05:14 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 15 Mar 2021 23:05:14 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31] In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Missing @since src/java.base/share/classes/java/util/Random.java line 135: > 133: * number generator which is maintained by method {@link #next}. > 134: * > 135: * @implSpec

The invocation {@code new Random(seed)} is equivalent to: This is not conventional formatting for an implSpec section. I suggest putting implSpec on its own line and then left-justifying the text as normal. A new paragraph tag is no needed at the beginning of implSpec. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From darcy at openjdk.java.net Mon Mar 15 23:11:14 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 15 Mar 2021 23:11:14 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31] In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Missing @since src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 62: > 60: @Retention(RetentionPolicy.RUNTIME) > 61: @Target(ElementType.TYPE) > 62: public @interface RandomGeneratorProperties { Should the is-deprecated information be stored here? ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From valeriep at openjdk.java.net Mon Mar 15 23:35:08 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 15 Mar 2021 23:35:08 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> Message-ID: On Mon, 15 Mar 2021 22:11:51 GMT, SalusaSecondus wrote: >> Cipher and KeyPairGenerator could be used a lot in TLS context. The synchronization may impact in some circumstances. Supporting dynamic configuration could be error-prone. For example, one thread to set the providers, and another thread get the providers by calling Cipher.init(). Unless the set and get use the same lock, the return value of the get method is not predictable. The lock here is on CachedSecureRandomHolder for providers configuration getting, and no lock (or different lock) for providers configuration setting. So applications may be able to get the expected behaviors by introducing this synchronization. >> >> As this behavior has been a while, I may not update the implementation. Instead, I would like to add an "implNote" tag to state that once the default provider is loaded, an implementation may be changed it any longer. Applications could use provider parameter if there is a preference. >> >> If you want go ahead, maybe the performance impacted could be mitigated by locking less processes. For example: >> >> if (checkConfig) { >> Provider[] currConfig = Security.getProviders(); >> if (!Arrays.equals(cachedConfig, currConfig)) { >> synchronized (CachedSecureRandomHolder.class) { >> // double check the currConfig >> currConfig = Security.getProviders(); >> if (!Arrays.equals(cachedConfig, currConfig)) { >> instance = ... >> cachedConfig = ... >> } >> } >> } >> } >> return instance; >> >> However, I still not very sure of the performance of Security.getProviders() because it is synchronized as well. Further, I may want to evaluate if the update of Security provider (for example Providers.setProviderList) could trigger an even to update the default instances. > > I would definitely not call `new SecureRandom()` each time as that can have real performance problems (especially on systems which pull from `/dev/random` and may not have hardware entropy). The synchronization worries me too. > > Could `java.security.Security` contain a "provider version" `int` (volatile, atomic, or similar) which is incremented every time the provider list is changed? Then this class (clearly using some non-public API) would check that value and if it is the same, just return the cached instance. If it has changed since the last time, then it would update `instance` and its remembered value of the index. I think that we might be able to do it without taking any locks in this class because even if the providers change out from under us, we returned a reasonable value (subject to multi-threading) and will fix things up when we're called the next time. > > // using this and name collision to highlight what's a field and what's local > int providerListVersion = Security.nonPublicGetProviderListVersion(); > if (this.providerListVersion != providerListVersion) { > this.providerListVersion = providerListVersion; > this.instance = new SecureRandom(); > } > return this.instance; Or, I can also separate out the instance returned by getSecureRandom() so that code path should be unaffected, e.g.: // cached SecureRandom instance private static class CachedSecureRandomHolder { public static SecureRandom instance = new SecureRandom(); private static Provider[] cachedConfig = Security.getProviders(); private static SecureRandom def = instance; public static SecureRandom getDefault() { synchronized (CachedSecureRandomHolder.class) { Provider[] currConfig = Security.getProviders(); if (!Arrays.equals(cachedConfig, currConfig)) { def = new SecureRandom(); cachedConfig = currConfig; } } return def; } } /** * Get a SecureRandom instance. This method should be used by JDK * internal code in favor of calling "new SecureRandom()". That needs to * iterate through the provider table to find the default SecureRandom * implementation, which is fairly inefficient. */ public static SecureRandom getSecureRandom() { return CachedSecureRandomHolder.instance; } /** * Get the default SecureRandom instance. This method is the * optimized version of "new SecureRandom()" which re-uses the default * SecureRandom impl if the provider table is the same. */ public static SecureRandom getDefSecureRandom() { return CachedSecureRandomHolder.getDefault(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From github.com+829871+salusasecondus at openjdk.java.net Tue Mar 16 00:13:07 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Tue, 16 Mar 2021 00:13:07 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> Message-ID: <9Fl5FBtlpMV8XYFSMuz5IkRiF3JGwoDwTKgm2sgxDn0=.5828d958-8eb1-423b-b500-8807981ba1f1@github.com> On Mon, 15 Mar 2021 23:31:33 GMT, Valerie Peng wrote: >> I would definitely not call `new SecureRandom()` each time as that can have real performance problems (especially on systems which pull from `/dev/random` and may not have hardware entropy). The synchronization worries me too. >> >> Could `java.security.Security` contain a "provider version" `int` (volatile, atomic, or similar) which is incremented every time the provider list is changed? Then this class (clearly using some non-public API) would check that value and if it is the same, just return the cached instance. If it has changed since the last time, then it would update `instance` and its remembered value of the index. I think that we might be able to do it without taking any locks in this class because even if the providers change out from under us, we returned a reasonable value (subject to multi-threading) and will fix things up when we're called the next time. >> >> // using this and name collision to highlight what's a field and what's local >> int providerListVersion = Security.nonPublicGetProviderListVersion(); >> if (this.providerListVersion != providerListVersion) { >> this.providerListVersion = providerListVersion; >> this.instance = new SecureRandom(); >> } >> return this.instance; > > Or, I can also separate out the instance returned by getSecureRandom() so that code path should be unaffected, e.g.: > // cached SecureRandom instance > private static class CachedSecureRandomHolder { > public static SecureRandom instance = new SecureRandom(); > private static Provider[] cachedConfig = Security.getProviders(); > private static SecureRandom def = instance; > > public static SecureRandom getDefault() { > synchronized (CachedSecureRandomHolder.class) { > Provider[] currConfig = Security.getProviders(); > if (!Arrays.equals(cachedConfig, currConfig)) { > def = new SecureRandom(); > cachedConfig = currConfig; > } > } > return def; > } > } > > /** > * Get a SecureRandom instance. This method should be used by JDK > * internal code in favor of calling "new SecureRandom()". That needs to > * iterate through the provider table to find the default SecureRandom > * implementation, which is fairly inefficient. > */ > public static SecureRandom getSecureRandom() { > return CachedSecureRandomHolder.instance; > } > > /** > * Get the default SecureRandom instance. This method is the > * optimized version of "new SecureRandom()" which re-uses the default > * SecureRandom impl if the provider table is the same. > */ > public static SecureRandom getDefSecureRandom() { > return CachedSecureRandomHolder.getDefault(); > } Doesn't that still incur a JVM-wide lock whenever `CachedSecureRandomHolder.getDefSecureRandom()` is called? I recall a different JVM-wide lock in the `getInstance` path ([JDK-7107615](https://bugs.openjdk.java.net/browse/JDK-7107615)) creating significant performance issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From github.com+741251+turbanoff at openjdk.java.net Tue Mar 16 10:13:11 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Mar 2021 10:13:11 GMT Subject: Integrated: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy This pull request has now been integrated. Changeset: 68deb24b Author: Andrey Turbanov Committer: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/68deb24b Stats: 105 lines in 7 files changed: 3 ins; 78 del; 24 mod 8080272: Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Reviewed-by: mcimadamore, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From sgehwolf at redhat.com Tue Mar 16 10:20:37 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Mar 2021 11:20:37 +0100 Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys In-Reply-To: References: Message-ID: <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com> Hi Martin, On Mon, 2021-03-15 at 17:10 +0000, Doerr, Martin wrote: > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ This doesn't look like the right webrev to me. Could you please double- check? Thanks, Severin From sgehwolf at redhat.com Tue Mar 16 14:11:59 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Mar 2021 15:11:59 +0100 Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys In-Reply-To: References: <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com> Message-ID: On Tue, 2021-03-16 at 10:39 +0000, Doerr, Martin wrote: > http://cr.openjdk.java.net/~mdoerr/8243559_root_ca_11u/webrev.00/ This looks good to me. Thanks, Severin From xuelei at openjdk.java.net Tue Mar 16 15:33:07 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 16 Mar 2021 15:33:07 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: <9Fl5FBtlpMV8XYFSMuz5IkRiF3JGwoDwTKgm2sgxDn0=.5828d958-8eb1-423b-b500-8807981ba1f1@github.com> References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> <9Fl5FBtlpMV8XYFSMuz5IkRiF3JGwoDwTKgm2sgxDn0=.5828d958-8eb1-423b-b500-8807981ba1f1@github.com> Message-ID: On Tue, 16 Mar 2021 00:10:00 GMT, SalusaSecondus wrote: >> Or, I can also separate out the instance returned by getSecureRandom() so that code path should be unaffected, e.g.: >> // cached SecureRandom instance >> private static class CachedSecureRandomHolder { >> public static SecureRandom instance = new SecureRandom(); >> private static Provider[] cachedConfig = Security.getProviders(); >> private static SecureRandom def = instance; >> >> public static SecureRandom getDefault() { >> synchronized (CachedSecureRandomHolder.class) { >> Provider[] currConfig = Security.getProviders(); >> if (!Arrays.equals(cachedConfig, currConfig)) { >> def = new SecureRandom(); >> cachedConfig = currConfig; >> } >> } >> return def; >> } >> } >> >> /** >> * Get a SecureRandom instance. This method should be used by JDK >> * internal code in favor of calling "new SecureRandom()". That needs to >> * iterate through the provider table to find the default SecureRandom >> * implementation, which is fairly inefficient. >> */ >> public static SecureRandom getSecureRandom() { >> return CachedSecureRandomHolder.instance; >> } >> >> /** >> * Get the default SecureRandom instance. This method is the >> * optimized version of "new SecureRandom()" which re-uses the default >> * SecureRandom impl if the provider table is the same. >> */ >> public static SecureRandom getDefSecureRandom() { >> return CachedSecureRandomHolder.getDefault(); >> } > > Doesn't that still incur a JVM-wide lock whenever `CachedSecureRandomHolder.getDefSecureRandom()` is called? I recall a different JVM-wide lock in the `getInstance` path ([JDK-7107615](https://bugs.openjdk.java.net/browse/JDK-7107615)) creating significant performance issues. I did not get the point that the code path should be unaffected". As there are a few update like: init(keysize, JCAUtil.getSecureRandom()); init(keysize, JCAUtil.getDefSecureRandom()); I think there are some impact on the existing application which use the default sec > Or, I can also separate out the instance returned by getSecureRandom() so that code path should be unaffected, e.g.: I did not get the point that the "code path should be unaffected"? JCAUtil.getDefSecureRandom() is used in updates like: init(keysize, JCAUtil.getSecureRandom()); init(keysize, JCAUtil.getDefSecureRandom()); > > ``` > // cached SecureRandom instance > private static class CachedSecureRandomHolder { > public static SecureRandom instance = new SecureRandom(); > private static Provider[] cachedConfig = Security.getProviders(); > private static SecureRandom def = instance; > > public static SecureRandom getDefault() { > synchronized (CachedSecureRandomHolder.class) { > Provider[] currConfig = Security.getProviders(); > if (!Arrays.equals(cachedConfig, currConfig)) { > def = new SecureRandom(); > cachedConfig = currConfig; > } > } > return def; > } > } > > /** > * Get a SecureRandom instance. This method should be used by JDK > * internal code in favor of calling "new SecureRandom()". That needs to > * iterate through the provider table to find the default SecureRandom > * implementation, which is fairly inefficient. > */ > public static SecureRandom getSecureRandom() { > return CachedSecureRandomHolder.instance; > } > > /** > * Get the default SecureRandom instance. This method is the > * optimized version of "new SecureRandom()" which re-uses the default > * SecureRandom impl if the provider table is the same. > */ > public static SecureRandom getDefSecureRandom() { > return CachedSecureRandomHolder.getDefault(); > } > ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From djelinski1 at gmail.com Tue Mar 16 16:49:03 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Tue, 16 Mar 2021 17:49:03 +0100 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: <739B2CF5-1C67-46A8-8C91-3642CD6C9818@amazon.com> References: <739B2CF5-1C67-46A8-8C91-3642CD6C9818@amazon.com> Message-ID: Thanks Paul for your review and for the hint. Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html compared to original, changes to make/test/BuildMicrobenchmark.gmk were dropped because file does not exist in jdk11 compared to previous webrev, CacheBench was re-added. Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > Thanks, > Paul > > ?-----Original Message----- > From: security-dev on behalf of Daniel Jeli?ski > Date: Tuesday, March 9, 2021 at 3:37 PM > To: "jdk-updates-dev at openjdk.java.net" > Cc: "security-dev at openjdk.java.net" > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Hi, > Please review this 11u backport; this is the same patch as for head, > except for microbenchmark makefile changes that did not apply because > the file doesn't exist in 11u, and the actual microbenchmark, which > would only add weight for no benefit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > Testing: Linux x86_64 tier1 and tier2. > > Thanks, > Daniel > From hohensee at amazon.com Tue Mar 16 17:59:53 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Mar 2021 17:59:53 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: <00A0F08F-FB4C-49BB-9FCC-B52F10466EA2@amazon.com> Looks good! :) ?-----Original Message----- From: Daniel Jeli?ski Date: Tuesday, March 16, 2021 at 9:49 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks Paul for your review and for the hint. Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html compared to original, changes to make/test/BuildMicrobenchmark.gmk were dropped because file does not exist in jdk11 compared to previous webrev, CacheBench was re-added. Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > Thanks, > Paul > > -----Original Message----- > From: security-dev on behalf of Daniel Jeli?ski > Date: Tuesday, March 9, 2021 at 3:37 PM > To: "jdk-updates-dev at openjdk.java.net" > Cc: "security-dev at openjdk.java.net" > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Hi, > Please review this 11u backport; this is the same patch as for head, > except for microbenchmark makefile changes that did not apply because > the file doesn't exist in 11u, and the actual microbenchmark, which > would only add weight for no benefit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > Testing: Linux x86_64 tier1 and tier2. > > Thanks, > Daniel > From valeriep at openjdk.java.net Tue Mar 16 20:56:06 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 16 Mar 2021 20:56:06 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> <9Fl5FBtlpMV8XYFSMuz5IkRiF3JGwoDwTKgm2sgxDn0=.5828d958-8eb1-423b-b500-8807981ba1f1@github.com> Message-ID: On Tue, 16 Mar 2021 15:29:51 GMT, Xue-Lei Andrew Fan wrote: >> Doesn't that still incur a JVM-wide lock whenever `CachedSecureRandomHolder.getDefSecureRandom()` is called? I recall a different JVM-wide lock in the `getInstance` path ([JDK-7107615](https://bugs.openjdk.java.net/browse/JDK-7107615)) creating significant performance issues. > > I did not get the point that the code path should be unaffected". As there are a few update like: > init(keysize, JCAUtil.getSecureRandom()); > init(keysize, JCAUtil.getDefSecureRandom()); > > I think there are some impact on the existing application which use the default sec > >> Or, I can also separate out the instance returned by getSecureRandom() so that code path should be unaffected, e.g.: > > I did not get the point that the "code path should be unaffected"? JCAUtil.getDefSecureRandom() is used in updates like: > init(keysize, JCAUtil.getSecureRandom()); > init(keysize, JCAUtil.getDefSecureRandom()); > >> >> ``` >> // cached SecureRandom instance >> private static class CachedSecureRandomHolder { >> public static SecureRandom instance = new SecureRandom(); >> private static Provider[] cachedConfig = Security.getProviders(); >> private static SecureRandom def = instance; >> >> public static SecureRandom getDefault() { >> synchronized (CachedSecureRandomHolder.class) { >> Provider[] currConfig = Security.getProviders(); >> if (!Arrays.equals(cachedConfig, currConfig)) { >> def = new SecureRandom(); >> cachedConfig = currConfig; >> } >> } >> return def; >> } >> } >> >> /** >> * Get a SecureRandom instance. This method should be used by JDK >> * internal code in favor of calling "new SecureRandom()". That needs to >> * iterate through the provider table to find the default SecureRandom >> * implementation, which is fairly inefficient. >> */ >> public static SecureRandom getSecureRandom() { >> return CachedSecureRandomHolder.instance; >> } >> >> /** >> * Get the default SecureRandom instance. This method is the >> * optimized version of "new SecureRandom()" which re-uses the default >> * SecureRandom impl if the provider table is the same. >> */ >> public static SecureRandom getDefSecureRandom() { >> return CachedSecureRandomHolder.getDefault(); >> } >> ``` > As this behavior has been a while, I may not update the implementation. Instead, I would like to add an "implNote" tag to state that once the default provider is loaded, an implementation may be changed it any longer. Applications could use provider parameter if there is a preference. Well, javadoc of the affected init methods clearly specifies that "get them using the SecureRandom implementation of the highest-priority installed provider as the source of randomness. ", thus I am not sure if we can just get around this with an _ at implNote_. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From valeriep at openjdk.java.net Tue Mar 16 21:00:07 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 16 Mar 2021 21:00:07 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> <9Fl5FBtlpMV8XYFSMuz5IkRiF3JGwoDwTKgm2sgxDn0=.5828d958-8eb1-423b-b500-8807981ba1f1@github.com> Message-ID: On Tue, 16 Mar 2021 20:53:27 GMT, Valerie Peng wrote: >> I did not get the point that the code path should be unaffected". As there are a few update like: >> init(keysize, JCAUtil.getSecureRandom()); >> init(keysize, JCAUtil.getDefSecureRandom()); >> >> I think there are some impact on the existing application which use the default sec >> >>> Or, I can also separate out the instance returned by getSecureRandom() so that code path should be unaffected, e.g.: >> >> I did not get the point that the "code path should be unaffected"? JCAUtil.getDefSecureRandom() is used in updates like: >> init(keysize, JCAUtil.getSecureRandom()); >> init(keysize, JCAUtil.getDefSecureRandom()); >> >>> >>> ``` >>> // cached SecureRandom instance >>> private static class CachedSecureRandomHolder { >>> public static SecureRandom instance = new SecureRandom(); >>> private static Provider[] cachedConfig = Security.getProviders(); >>> private static SecureRandom def = instance; >>> >>> public static SecureRandom getDefault() { >>> synchronized (CachedSecureRandomHolder.class) { >>> Provider[] currConfig = Security.getProviders(); >>> if (!Arrays.equals(cachedConfig, currConfig)) { >>> def = new SecureRandom(); >>> cachedConfig = currConfig; >>> } >>> } >>> return def; >>> } >>> } >>> >>> /** >>> * Get a SecureRandom instance. This method should be used by JDK >>> * internal code in favor of calling "new SecureRandom()". That needs to >>> * iterate through the provider table to find the default SecureRandom >>> * implementation, which is fairly inefficient. >>> */ >>> public static SecureRandom getSecureRandom() { >>> return CachedSecureRandomHolder.instance; >>> } >>> >>> /** >>> * Get the default SecureRandom instance. This method is the >>> * optimized version of "new SecureRandom()" which re-uses the default >>> * SecureRandom impl if the provider table is the same. >>> */ >>> public static SecureRandom getDefSecureRandom() { >>> return CachedSecureRandomHolder.getDefault(); >>> } >>> ``` > >> As this behavior has been a while, I may not update the implementation. Instead, I would like to add an "implNote" tag to state that once the default provider is loaded, an implementation may be changed it any longer. Applications could use provider parameter if there is a preference. > > Well, javadoc of the affected init methods clearly specifies that "get them using the SecureRandom implementation of the highest-priority installed provider as the source of randomness. ", thus I am not sure if we can just get around this with an _ at implNote_. > I did not get the point that the code path should be unaffected". As there are a few update like: > init(keysize, JCAUtil.getSecureRandom()); > init(keysize, JCAUtil.getDefSecureRandom()); What I mean is that the new suggestion will not impact callers of JCAUtil.getSecureRandom() which I thought what your performance regression means. To enforce that the most preferred SecureRandom impl is used, this for sure will incur some cost especially when the existing impl just returns a cached obj w/o any checking. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From valeriep at openjdk.java.net Tue Mar 16 21:04:07 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 16 Mar 2021 21:04:07 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes In-Reply-To: References: <8h6ezmpTv6Fsweyy8wVUbywr72JlCoDv7HxMVSMcIvE=.8a74de92-63a9-467c-b618-12a3a4b44911@github.com> <49YykypFkZttZgwJ6JWKrhMy5tq6MXV0SwjpNL33HkU=.61d79eff-eb3d-4045-aac2-f2ea1a6a0c49@github.com> <9Fl5FBtlpMV8XYFSMuz5IkRiF3JGwoDwTKgm2sgxDn0=.5828d958-8eb1-423b-b500-8807981ba1f1@github.com> Message-ID: On Tue, 16 Mar 2021 20:57:48 GMT, Valerie Peng wrote: >>> As this behavior has been a while, I may not update the implementation. Instead, I would like to add an "implNote" tag to state that once the default provider is loaded, an implementation may be changed it any longer. Applications could use provider parameter if there is a preference. >> >> Well, javadoc of the affected init methods clearly specifies that "get them using the SecureRandom implementation of the highest-priority installed provider as the source of randomness. ", thus I am not sure if we can just get around this with an _ at implNote_. > >> I did not get the point that the code path should be unaffected". As there are a few update like: >> init(keysize, JCAUtil.getSecureRandom()); >> init(keysize, JCAUtil.getDefSecureRandom()); > > What I mean is that the new suggestion will not impact callers of JCAUtil.getSecureRandom() which I thought what your performance regression means. To enforce that the most preferred SecureRandom impl is used, this for sure will incur some cost especially when the existing impl just returns a cached obj w/o any checking. > Could `java.security.Security` contain a "provider version" `int` (volatile, atomic, or similar) which is incremented every time the provider list is changed? Then this class (clearly using some non-public API) would check that value and if it is the same, just return the cached instance. If it has changed since the last time, then it would update `instance` and its remembered value of the index. I think that we might be able to do it without taking any locks in this class because even if the providers change out from under us, we returned a reasonable value (subject to multi-threading) and will fix things up when we're called the next time. This and Tony's suggestion sounds similar and I can sure explore this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From github.com+160684+tommyettinger at openjdk.java.net Tue Mar 16 21:04:12 2021 From: github.com+160684+tommyettinger at openjdk.java.net (Tommy Ettinger) Date: Tue, 16 Mar 2021 21:04:12 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: References: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com> Message-ID: On Mon, 15 Mar 2021 20:45:30 GMT, Paul Sandoz wrote: >> I still don't like the fact that the factory uses reflection but i don't see how to do better > > This is now looking very nicely structured. > > The only thing i am unsure are the details around `RandomGenerator` being a service provider interface. The documentation mentions this at various points (mostly as implementation notes), but it's not really called out on `RandomGenerator`. > > Trying out the patch, I can implement `RandomGenerator` and register it as a service: > > public class AlwaysZero implements RandomGenerator { > @Override > public long nextLong() { > return 0; > } > } > ... > RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero"); > > > Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not public). If i rename the above to `L32X64MixRandom` an `ExceptionInInitializerError` is produced due to duplicate keys. > > I suspect you want to filter out the service providers to those that only declare `RandomGeneratorProperties`, thereby restricting to providers only supplied by the platform. Has anyone here benchmarked this? I've run BumbleBench benchmarks (one of the AdoptOpenJDK team's tools, [available here](https://github.com/adoptium/bumblebench)) and I'm skeptical of the original claims in [JEP 356](https://openjdk.java.net/jeps/356), namely: > ...a new class of splittable PRNG algorithms (LXM) has also been discovered that are almost as fast [as SplittableRandom]... On my machine, L64X128MixRandom's algorithm is 53% slower than SplittableRandom, a halving in performance that I think would be inaccurate to describe as "almost as fast." I've benchmarked on Java 8 HotSpot (Windows 10, x64) and Java 15 OpenJ9 (same machine). On HotSpot, which I think is the main concern, I go from 1021770880 (over 1 billion) random longs per second with SplittableRandom to 479769280 (over 479 million) with my (I believe faithful) implementation of L64X128MixRandom. That is where I observed the 53% reduction. While SplittableRandom specifically seems to perform relatively badly on OpenJ9, with 893283072 longs per second (893 million), other similar random number generators do extremely well on OpenJ9; [LaserRandom](https://github.com/tommyettinger/jdkgdxds/blob/master/src/main/java/com/github/tommyettinger/ds/support/LaserRandom.java) generates 4232752128 random longs per second (4.2 billion) where L64X128MixRandom gets 840015872 (840 million). My benchmark repo is a mess, but if anyone wants to see and verify, [here it is](https://github.com/tommyettinger/assorted-benchmarks/tree/master/src/main/java/net/adoptopenjdk/bumblebench/examples). JMH benchmarks might provide different or just additional useful information; I've only run BumbleBench. One could make the argument that getting a random long from a PRNG takes so little time in the first place that it is unlikely to be a bottleneck, and by that logic, LXM is "almost as fast." However, if random generation is not being called often enough for its speed to matter, you are exceedingly unlikely to need so many (over 9 quintillion) parallel streams or such a long period per stream ((2 to the 192) minus (2 to the 64)). LXM is also 1-dimensionally equidistributed, while the foundation it is built on should allow 4-dimensional equidistribution (with the caveat of any LFSR that an all-zero state is impossible), with the same memory use per generator (4 longs), a longer period, and comparable quality using `xoshiro256**`, or possibly `xoshiro256++`, giving up streams but permitting twice as many leaps as LXM has streams if you maintain the same period as L64X128MixRandom. If I were implementing a PRNG to operate in a future official version of the JVM, I would definitely look into ways to use AES-NI, and I think the interfaces provided here should be valuable for any similar addition, even if I disagree with the provided implementations of those interfaces. Thank you for your time. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jjiang at openjdk.java.net Tue Mar 16 23:21:40 2021 From: jjiang at openjdk.java.net (John Jiang) Date: Tue, 16 Mar 2021 23:21:40 GMT Subject: RFR: JDK-8263188: JSSE should fail fast if there isn't supported signature algorithm [v2] In-Reply-To: References: Message-ID: > If signature_algorithms extension is present, but the algorithms are unreconginzed or unsupported, JSSE peers should send fatal alert immediately. > For example, in this case, it's unnecssary to try to produce ServerHello, Certificate and ServerKeyExchange messages. John Jiang has updated the pull request incrementally with one additional commit since the last revision: TLSv1.2 CertificateRequest could fail fast if no common signature scheme and add two tests for TLSv1.2 and TLSv1.3 respectively ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2876/files - new: https://git.openjdk.java.net/jdk/pull/2876/files/bed8a7b7..a0552d45 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2876&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2876&range=00-01 Stats: 485 lines in 5 files changed: 473 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2876/head:pull/2876 PR: https://git.openjdk.java.net/jdk/pull/2876 From djelinski1 at gmail.com Wed Mar 17 06:39:13 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 17 Mar 2021 07:39:13 +0100 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: <00A0F08F-FB4C-49BB-9FCC-B52F10466EA2@amazon.com> References: <00A0F08F-FB4C-49BB-9FCC-B52F10466EA2@amazon.com> Message-ID: Thanks again Paul. Could you sponsor the change? As far as I can tell, I'd need to add a fix request now, but I don't have access to issue tracker. Thanks, Daniel wt., 16 mar 2021 o 18:59 Hohensee, Paul napisa?(a): > > Looks good! :) > > ?-----Original Message----- > From: Daniel Jeli?ski > Date: Tuesday, March 16, 2021 at 9:49 AM > To: "Hohensee, Paul" > Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Thanks Paul for your review and for the hint. > > Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > were dropped because file does not exist in jdk11 > compared to previous webrev, CacheBench was re-added. > > Testing: Linux x86_64 tier1 and tier2. > Thanks, > Daniel > > pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: security-dev on behalf of Daniel Jeli?ski > > Date: Tuesday, March 9, 2021 at 3:37 PM > > To: "jdk-updates-dev at openjdk.java.net" > > Cc: "security-dev at openjdk.java.net" > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > > > Hi, > > Please review this 11u backport; this is the same patch as for head, > > except for microbenchmark makefile changes that did not apply because > > the file doesn't exist in 11u, and the actual microbenchmark, which > > would only add weight for no benefit. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > Testing: Linux x86_64 tier1 and tier2. > > > > Thanks, > > Daniel > > > From djelinski1 at gmail.com Wed Mar 17 08:56:55 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 17 Mar 2021 09:56:55 +0100 Subject: Request for comment: the session ticket protection scheme for distributed TLS sessions. In-Reply-To: References: Message-ID: Hi Xuelei, I reviewed the RFC above (I hope I'm not too late!) and have some concerns about the security properties of the proposed solution. Essentially they would apply to all schemes using session ticket encryption keys derived from a long-lived secret. How does this apply to TLS versions before 1.3? My understanding is that deriving session ticket encryption keys from a long-term secret immediately forfeits all forward secrecy in all versions of TLS before 1.3. This also applies to TLS 1.3 when psk_ke is used. How are we going to ensure Key Compromise Impersonation (KCI) resistance (defined in [1])? Will it be possible for an attacker to spoof peer certificates in a session ticket if he gains access to our long-term secret? I didn't find answers in the JEP or in the CSR, so I thought I'd ask here. Thanks, Daniel [1] https://tools.ietf.org/html/rfc8446#appendix-E.1 czw., 29 pa? 2020 o 04:41 Xue-Lei Fan napisa?(a): > > The PNG may be too large to open from some mail system. Here is the PDF version. BTW, I also made an update on the use of AEAD algorithm with additional data. > > Thanks, > Xuelei > > > > On Oct 23, 2020, at 8:58 AM, Xuelei Fan wrote: > > > > Hi, > > > > I'm working on the JEP to improve the scalability and throughput of the TLS implementation, by supporting distributed session resumption across clusters of computers. > > > > TLS session tickets will used for session resumption in a cluster. To support distributed session resumption, a session ticket that is generated and protected in one server node must be usable for session resumption on other server nodes in the distributed system. Each node should use the same session ticket structure, and share the secrets that are used to protect session tickets. More details, please refer to the JEP: > > https://bugs.openjdk.java.net/browse/JDK-8245551 > > > > It is a essential part of the implementation that we need to define a session ticket protection scheme. The scheme will support key generation, key rotation and key synchronization across clusters of computers. > > > > The attached doc_distributed_credential_protection.md is a markdown file, which may not easy to read. So I attached a rendered picture as well. > > > > Please let me know if you have any concerns. Any comments are welcome. > > > > Thanks, > > Xuelei > > > From github.com+76791+alblue at openjdk.java.net Wed Mar 17 12:17:00 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Wed, 17 Mar 2021 12:17:00 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base Message-ID: Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. This fixes the issues in the `java.base` package for ease of reviewing. https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124 ------------- Commit messages: - 8263658: Use the blessed modifier order in java.base Changes: https://git.openjdk.java.net/jdk/pull/2993/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263658 Stats: 140 lines in 29 files changed: 0 ins; 0 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/2993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2993/head:pull/2993 PR: https://git.openjdk.java.net/jdk/pull/2993 From shade at openjdk.java.net Wed Mar 17 12:17:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 17 Mar 2021 12:17:00 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base In-Reply-To: References: Message-ID: On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt wrote: > Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. > > This fixes the issues in the `java.base` package for ease of reviewing. > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124 Please change the synopsis to "8263658: Use the blessed modifier order in java.base" to get this PR hooked properly to the new bug. Also configure the run the testing, see "Pre-submit test status" in "Checks". ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From rriggs at openjdk.java.net Wed Mar 17 13:31:50 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 17 Mar 2021 13:31:50 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base In-Reply-To: References: Message-ID: On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt wrote: > Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. > > This fixes the issues in the `java.base` package for ease of reviewing. > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From chegar at openjdk.java.net Wed Mar 17 13:32:54 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 17 Mar 2021 13:32:54 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v3] In-Reply-To: References: Message-ID: <4T_9Q1V9-NxupS0kBhqrUrh6XjBmSTxSqtjKW9zRb0g=.49910022-dcb6-4e36-966a-ea197b0c57a2@github.com> On Mon, 15 Mar 2021 21:47:28 GMT, ?????? ??????? wrote: >> Hello, >> >> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. >> >> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. >> >> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: >> String delimiter = this.delimiter; >> char[] chars = new char[this.len + addLen]; >> int k = getChars(this.prefix, chars, 0); >> if (size > 0) { >> k += getChars(elts[0], chars, k); // inflate byte[] >> >> for(int i = 1; i < size; ++i) { >> k += getChars(delimiter, chars, k); >> k += getChars(elts[i], chars, k); >> } >> } >> >> k += getChars(this.suffix, chars, k); >> return new String(chars); // compress char[] -> byte[] >> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) >> covering both cases when resulting String is Latin1 or UTF-16 >> >> I've prepared a patch along with benchmark proving that this change is correct and brings improvement. >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class StringJoinerBenchmark { >> >> @Benchmark >> public String stringJoiner(Data data) { >> String[] stringArray = data.stringArray; >> return Joiner.joinWithStringJoiner(stringArray); >> } >> >> @State(Scope.Thread) >> public static class Data { >> >> @Param({"latin", "cyrillic", "mixed"}) >> private String mode; >> >> @Param({"8", "32", "64"}) >> private int length; >> >> @Param({"5", "10", "100"}) >> private int count; >> >> private String[] stringArray; >> >> @Setup >> public void setup() { >> RandomStringGenerator generator = new RandomStringGenerator(); >> >> stringArray = new String[count]; >> >> for (int i = 0; i < count; i++) { >> String alphabet = getAlphabet(i, mode); >> stringArray[i] = generator.randomString(alphabet, length); >> } >> } >> >> private static String getAlphabet(int index, String mode) { >> var latin = "abcdefghijklmnopqrstuvwxyz"; //English >> var cyrillic = "????????????????????????????????"; // Russian >> >> String alphabet; >> switch (mode) { >> case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; >> case "latin" -> alphabet = latin; >> case "cyrillic" -> alphabet = cyrillic; >> default -> throw new RuntimeException("Illegal mode " + mode); >> } >> return alphabet; >> } >> } >> } >> >> public class Joiner { >> >> public static String joinWithStringJoiner(String[] stringArray) { >> StringJoiner joiner = new StringJoiner(",", "[", "]"); >> for (String str : stringArray) { >> joiner.add(str); >> } >> return joiner.toString(); >> } >> } >> >> >> (count) (length) (mode) Java 14 patched Units >> stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op >> stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op >> stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op >> stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op >> stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op >> stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op >> stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op >> stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op >> stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op >> stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op >> stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op >> stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op >> stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op >> stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op >> stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op >> stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op >> stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op >> stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op >> stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op >> stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op >> stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op >> stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op >> stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op >> stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op >> stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op >> stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op >> stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op >> >> stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8148937: (str) Update copyright year Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From github.com+10835776+stsypanov at openjdk.java.net Wed Mar 17 13:37:52 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 17 Mar 2021 13:37:52 GMT Subject: Integrated: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: <5bem8C3JNFJeVXKjolHcGMWeNhnykzQvKvym7yFVLV8=.0f1bf64e-dfb3-4687-ad7b-be1d0f628376@github.com> On Thu, 18 Feb 2021 14:30:15 GMT, ?????? ??????? wrote: > Hello, > > as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. > > This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. > > As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: > String delimiter = this.delimiter; > char[] chars = new char[this.len + addLen]; > int k = getChars(this.prefix, chars, 0); > if (size > 0) { > k += getChars(elts[0], chars, k); // inflate byte[] > > for(int i = 1; i < size; ++i) { > k += getChars(delimiter, chars, k); > k += getChars(elts[i], chars, k); > } > } > > k += getChars(this.suffix, chars, k); > return new String(chars); // compress char[] -> byte[] > This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) > covering both cases when resulting String is Latin1 or UTF-16 > > I've prepared a patch along with benchmark proving that this change is correct and brings improvement. > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class StringJoinerBenchmark { > > @Benchmark > public String stringJoiner(Data data) { > String[] stringArray = data.stringArray; > return Joiner.joinWithStringJoiner(stringArray); > } > > @State(Scope.Thread) > public static class Data { > > @Param({"latin", "cyrillic", "mixed"}) > private String mode; > > @Param({"8", "32", "64"}) > private int length; > > @Param({"5", "10", "100"}) > private int count; > > private String[] stringArray; > > @Setup > public void setup() { > RandomStringGenerator generator = new RandomStringGenerator(); > > stringArray = new String[count]; > > for (int i = 0; i < count; i++) { > String alphabet = getAlphabet(i, mode); > stringArray[i] = generator.randomString(alphabet, length); > } > } > > private static String getAlphabet(int index, String mode) { > var latin = "abcdefghijklmnopqrstuvwxyz"; //English > var cyrillic = "????????????????????????????????"; // Russian > > String alphabet; > switch (mode) { > case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; > case "latin" -> alphabet = latin; > case "cyrillic" -> alphabet = cyrillic; > default -> throw new RuntimeException("Illegal mode " + mode); > } > return alphabet; > } > } > } > > public class Joiner { > > public static String joinWithStringJoiner(String[] stringArray) { > StringJoiner joiner = new StringJoiner(",", "[", "]"); > for (String str : stringArray) { > joiner.add(str); > } > return joiner.toString(); > } > } > > > (count) (length) (mode) Java 14 patched Units > stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op > stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op > stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op > stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op > stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op > stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op > stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op > stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op > stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op > stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op > stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op > stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op > stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op > stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op > stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op > stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op > stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op > stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op > stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op > stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op > stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op > stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op > stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op > stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op > stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op > stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op > stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op > > stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op This pull request has now been integrated. Changeset: 000012a3 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/000012a3 Stats: 135 lines in 2 files changed: 113 ins; 10 del; 12 mod 8148937: (str) Adapt StringJoiner for Compact Strings Reviewed-by: redestad, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From xuelei at openjdk.java.net Wed Mar 17 17:28:01 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 17 Mar 2021 17:28:01 GMT Subject: RFR: 8263743: redundant lock in SSLSocketImpl Message-ID: <8ZKiO4E1g_n5TZvpxwine_ylN96sCa30zpWsruajgxE=.ad78c80d-c9ee-4f60-815c-a891e32abecf@github.com> Remove redundant lock in SSLSocketImpl. In the SSLSocketImpl, there is a socket level lock while reading application data (see readApplicationRecord). socketLock.lock(); try { plainText = decode(buffer); } finally { socketLock.unlock(); } If an application data read is in progress, other calling to SSLSocket APIs (for example getUseClientMode()) could be blocked if socket level locks are used. No new regression test. Simple fix, hard to trigger the deadlock. ------------- Commit messages: - 8263743: redundant lock in SSLSocketImpl Changes: https://git.openjdk.java.net/jdk/pull/3053/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3053&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263743 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3053.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3053/head:pull/3053 PR: https://git.openjdk.java.net/jdk/pull/3053 From valeriep at openjdk.java.net Wed Mar 17 19:25:13 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 17 Mar 2021 19:25:13 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v2] In-Reply-To: References: Message-ID: <5alaBL424qbhasmwgzYPzvq4hI05uHeXRES52D_mbRk=.021e85be-2bca-4bbd-ae71-4a71b418697a@github.com> > Can someone help review this somewhat trivial change? > > Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. > Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Changed to use volatile for the default SecureRandom object reference ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3018/files - new: https://git.openjdk.java.net/jdk/pull/3018/files/48b7fa35..0ad630f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3018&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3018&range=00-01 Stats: 34 lines in 2 files changed: 16 ins; 13 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3018/head:pull/3018 PR: https://git.openjdk.java.net/jdk/pull/3018 From github.com+829871+salusasecondus at openjdk.java.net Wed Mar 17 19:54:50 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Wed, 17 Mar 2021 19:54:50 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v2] In-Reply-To: <5alaBL424qbhasmwgzYPzvq4hI05uHeXRES52D_mbRk=.021e85be-2bca-4bbd-ae71-4a71b418697a@github.com> References: <5alaBL424qbhasmwgzYPzvq4hI05uHeXRES52D_mbRk=.021e85be-2bca-4bbd-ae71-4a71b418697a@github.com> Message-ID: On Wed, 17 Mar 2021 19:25:13 GMT, Valerie Peng wrote: >> Can someone help review this somewhat trivial change? >> >> Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. >> Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Changed to use volatile for the default SecureRandom object reference src/java.base/share/classes/sun/security/jca/JCAUtil.java line 29: > 27: > 28: import java.lang.ref.*; > 29: import java.util.Arrays; Import no longer needed. src/java.base/share/classes/sun/security/jca/JCAUtil.java line 84: > 82: * SecureRandom impl if the provider table is the same. > 83: */ > 84: public static SecureRandom getDefSecureRandom() { When should people use `getSecureRandom` rather than `getDefSecureRandom()`? Are we leaving the old to avoid changing behavior out from under people who may not expect it? src/java.base/share/classes/sun/security/jca/JCAUtil.java line 92: > 90: } > 91: } > 92: return def; Do we need to worry about `clearDefSecureRandom()` being called between lines 88 and 92? Thread 1: `getDefSecureRandom()#85` (`def` is `null`) Thread 1: `getDefSecureRandom()#86` Thread 1: `getDefSecureRandom()#87` (`def` is still `null`) Thread 1: `getDefSecureRandom()#88` (`def` is **not** `null`) Thread 2: `clearDefSecureRandom()` (`def` is `null` again) Thread 1: `getDefSecureRandom()#92` (return `def` which is incorrectly `null`) Suggestion: SecureRandom result = def; if (result == null) { synchronized (JCAUtil.class) { result = def; if (result == null) { def = result = new SecureRandom() } } } return result; ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From valeriep at openjdk.java.net Wed Mar 17 19:54:51 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 17 Mar 2021 19:54:51 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v2] In-Reply-To: References: <5alaBL424qbhasmwgzYPzvq4hI05uHeXRES52D_mbRk=.021e85be-2bca-4bbd-ae71-4a71b418697a@github.com> Message-ID: On Wed, 17 Mar 2021 19:32:56 GMT, SalusaSecondus wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed to use volatile for the default SecureRandom object reference > > src/java.base/share/classes/sun/security/jca/JCAUtil.java line 29: > >> 27: >> 28: import java.lang.ref.*; >> 29: import java.util.Arrays; > > Import no longer needed. Sure, will remove. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From valeriep at openjdk.java.net Wed Mar 17 19:59:50 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 17 Mar 2021 19:59:50 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v2] In-Reply-To: References: <5alaBL424qbhasmwgzYPzvq4hI05uHeXRES52D_mbRk=.021e85be-2bca-4bbd-ae71-4a71b418697a@github.com> Message-ID: On Wed, 17 Mar 2021 19:34:54 GMT, SalusaSecondus wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed to use volatile for the default SecureRandom object reference > > src/java.base/share/classes/sun/security/jca/JCAUtil.java line 84: > >> 82: * SecureRandom impl if the provider table is the same. >> 83: */ >> 84: public static SecureRandom getDefSecureRandom() { > > When should people use `getSecureRandom` rather than `getDefSecureRandom()`? Are we leaving the old to avoid changing behavior out from under people who may not expect it? To minimize the impact, I leave the JCAUtil.getSecureRandom() impl as is. I suppose this is more for JDK internal code which is not required to use the most preferred SecureRandom impl. There are quite a few callers to this method and I feel it's better to leave them out of this change. > src/java.base/share/classes/sun/security/jca/JCAUtil.java line 92: > >> 90: } >> 91: } >> 92: return def; > > Do we need to worry about `clearDefSecureRandom()` being called between lines 88 and 92? > > Thread 1: `getDefSecureRandom()#85` (`def` is `null`) > Thread 1: `getDefSecureRandom()#86` > Thread 1: `getDefSecureRandom()#87` (`def` is still `null`) > Thread 1: `getDefSecureRandom()#88` (`def` is **not** `null`) > Thread 2: `clearDefSecureRandom()` (`def` is `null` again) > Thread 1: `getDefSecureRandom()#92` (return `def` which is incorrectly `null`) > > > Suggestion: > > SecureRandom result = def; > if (result == null) { > synchronized (JCAUtil.class) { > result = def; > if (result == null) { > def = result = new SecureRandom(); > } > } > } > return result; Sure, good point. I will update. Thanks for catching this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From hohensee at amazon.com Wed Mar 17 20:00:37 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Mar 2021 20:00:37 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: Np, tagged. ?-----Original Message----- From: Daniel Jeli?ski Date: Tuesday, March 16, 2021 at 11:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks again Paul. Could you sponsor the change? As far as I can tell, I'd need to add a fix request now, but I don't have access to issue tracker. Thanks, Daniel wt., 16 mar 2021 o 18:59 Hohensee, Paul napisa?(a): > > Looks good! :) > > -----Original Message----- > From: Daniel Jeli?ski > Date: Tuesday, March 16, 2021 at 9:49 AM > To: "Hohensee, Paul" > Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Thanks Paul for your review and for the hint. > > Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > were dropped because file does not exist in jdk11 > compared to previous webrev, CacheBench was re-added. > > Testing: Linux x86_64 tier1 and tier2. > Thanks, > Daniel > > pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: security-dev on behalf of Daniel Jeli?ski > > Date: Tuesday, March 9, 2021 at 3:37 PM > > To: "jdk-updates-dev at openjdk.java.net" > > Cc: "security-dev at openjdk.java.net" > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > > > Hi, > > Please review this 11u backport; this is the same patch as for head, > > except for microbenchmark makefile changes that did not apply because > > the file doesn't exist in 11u, and the actual microbenchmark, which > > would only add weight for no benefit. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > Testing: Linux x86_64 tier1 and tier2. > > > > Thanks, > > Daniel > > > From valeriep at openjdk.java.net Wed Mar 17 20:09:04 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 17 Mar 2021 20:09:04 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: > Can someone help review this somewhat trivial change? > > Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. > Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Fixed a null race condition ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3018/files - new: https://git.openjdk.java.net/jdk/pull/3018/files/0ad630f3..b513e51d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3018&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3018&range=01-02 Stats: 7 lines in 1 file changed: 2 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3018/head:pull/3018 PR: https://git.openjdk.java.net/jdk/pull/3018 From github.com+829871+salusasecondus at openjdk.java.net Wed Mar 17 20:16:49 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Wed, 17 Mar 2021 20:16:49 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 20:09:04 GMT, Valerie Peng wrote: >> Can someone help review this somewhat trivial change? >> >> Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. >> Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a null race condition Not that my review counts towards approval, but this looks good to me (and fixes some issues I've been wrestling with on and off for several years now, so I'm really happy to see this change). ------------- Marked as reviewed by SalusaSecondus at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/3018 From xuelei at openjdk.java.net Wed Mar 17 20:44:49 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 17 Mar 2021 20:44:49 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v2] In-Reply-To: References: <5alaBL424qbhasmwgzYPzvq4hI05uHeXRES52D_mbRk=.021e85be-2bca-4bbd-ae71-4a71b418697a@github.com> Message-ID: <3SGq07XWj4Ozl8mjNKEzEy7t4uvGmhTuRTE8vC-ZtRQ=.0b7ae5fa-c543-412b-ac29-91db9560fe07@github.com> On Wed, 17 Mar 2021 19:55:13 GMT, Valerie Peng wrote: > To minimize the impact, I leave the JCAUtil.getSecureRandom() impl as is. I suppose this is more for JDK internal code which is not required to use the most preferred SecureRandom impl. There are quite a few callers to this method and I feel it's better to leave them out of this change. The internal use may be just to avoid to create new instances of SecureRandom. Those use may need to use the latest updated secure random provider as well, for example the use in DSA key pair generation (DSAKeyPairGenerator.java). With this update, I think the performance impact should be minimal and we may be able to have a uniform behavior no matter internal or external uses. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From xuelei at openjdk.java.net Wed Mar 17 20:52:50 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 17 Mar 2021 20:52:50 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 20:09:04 GMT, Valerie Peng wrote: >> Can someone help review this somewhat trivial change? >> >> Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. >> Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a null race condition src/java.base/share/classes/sun/security/jca/JCAUtil.java line 86: > 84: SecureRandom result = def; > 85: if (result == null) { > 86: synchronized (JCAUtil.class) { Could this lock be avoided if set the value in the Providers update (or when the providers list is updated)? ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From ascarpino at openjdk.java.net Wed Mar 17 21:06:49 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 17 Mar 2021 21:06:49 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 20:09:04 GMT, Valerie Peng wrote: >> Can someone help review this somewhat trivial change? >> >> Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. >> Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a null race condition Marked as reviewed by ascarpino (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From ascarpino at openjdk.java.net Wed Mar 17 21:06:49 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 17 Mar 2021 21:06:49 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 20:13:43 GMT, SalusaSecondus wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed a null race condition > > Not that my review counts towards approval, but this looks good to me (and fixes some issues I've been wrestling with on and off for several years now, so I'm really happy to see this change). I'm fine with the change. The main code path should perform as it did previous to the change and I don't think the lock here is a big deal as it will only be triggered during a provider change. One small delay in a very rare case should be fine ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From luoziyi at openjdk.java.net Wed Mar 17 22:47:08 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Wed, 17 Mar 2021 22:47:08 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v3] In-Reply-To: References: Message-ID: <6YFmAiWYpQJiFbnGYkYDjFvmdWOnfggEpyh1H1yJUzM=.83e5a7fb-7b1d-474c-919b-e1b39f561f0f@github.com> > This is a P2 regression introduced by JDK-8254717. > > In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: > > X-axis: type of `keySpec` > Y-axis: type of `key` > > Before JDK-8254717: > > | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | > |--|--|--| > | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | > | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | > > After JDK-8254717 (Green check is what we want to fix, red cross is the regression): > > | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | > |--|--|--| > | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | > | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | > > This commit fixes the regression. > > > ### Tests > > * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed > * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed Ziyi Luo has updated the pull request incrementally with one additional commit since the last revision: Fix P11RSAKeyFactory and add one more jtreg test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2949/files - new: https://git.openjdk.java.net/jdk/pull/2949/files/e9a76978..065e1138 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2949&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2949&range=01-02 Stats: 132 lines in 3 files changed: 98 ins; 10 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/2949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2949/head:pull/2949 PR: https://git.openjdk.java.net/jdk/pull/2949 From valeriep at openjdk.java.net Thu Mar 18 01:30:48 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 18 Mar 2021 01:30:48 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 21:03:38 GMT, Anthony Scarpino wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed a null race condition > > Marked as reviewed by ascarpino (Reviewer). Thanks all for the review and feedback~ ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From valeriep at openjdk.java.net Thu Mar 18 01:30:49 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 18 Mar 2021 01:30:49 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 20:49:41 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed a null race condition > > src/java.base/share/classes/sun/security/jca/JCAUtil.java line 86: > >> 84: SecureRandom result = def; >> 85: if (result == null) { >> 86: synchronized (JCAUtil.class) { > > Could this lock be avoided if set the value in the Providers update (or when the providers list is updated)? Well, then we have to pay the cost of "new SecureRandom()" at every provider list update when it may not be needed. It's hard to say which way is better... I thought about it and it seems more reasonable to only pay the cost when the SecureRandom object is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From valeriep at openjdk.java.net Thu Mar 18 01:45:50 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 18 Mar 2021 01:45:50 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v2] In-Reply-To: <3SGq07XWj4Ozl8mjNKEzEy7t4uvGmhTuRTE8vC-ZtRQ=.0b7ae5fa-c543-412b-ac29-91db9560fe07@github.com> References: <5alaBL424qbhasmwgzYPzvq4hI05uHeXRES52D_mbRk=.021e85be-2bca-4bbd-ae71-4a71b418697a@github.com> <3SGq07XWj4Ozl8mjNKEzEy7t4uvGmhTuRTE8vC-ZtRQ=.0b7ae5fa-c543-412b-ac29-91db9560fe07@github.com> Message-ID: On Wed, 17 Mar 2021 20:40:16 GMT, Xue-Lei Andrew Fan wrote: >> To minimize the impact, I leave the JCAUtil.getSecureRandom() impl as is. I suppose this is more for JDK internal code which is not required to use the most preferred SecureRandom impl. There are quite a few callers to this method and I feel it's better to leave them out of this change. > >> To minimize the impact, I leave the JCAUtil.getSecureRandom() impl as is. I suppose this is more for JDK internal code which is not required to use the most preferred SecureRandom impl. There are quite a few callers to this method and I feel it's better to leave them out of this change. > > The internal use may be just to avoid to create new instances of SecureRandom. Those use may need to use the latest updated secure random provider as well, for example the use in DSA key pair generation (DSAKeyPairGenerator.java). > > With this update, I think the performance impact should be minimal and we may be able to have a uniform behavior no matter internal or external uses. Maybe. We can do that in a separate changeset... ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From xuelei at openjdk.java.net Thu Mar 18 02:00:50 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 18 Mar 2021 02:00:50 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 20:09:04 GMT, Valerie Peng wrote: >> Can someone help review this somewhat trivial change? >> >> Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. >> Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a null race condition Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From xuelei at openjdk.java.net Thu Mar 18 02:00:50 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 18 Mar 2021 02:00:50 GMT Subject: RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v3] In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 01:27:26 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/jca/JCAUtil.java line 86: >> >>> 84: SecureRandom result = def; >>> 85: if (result == null) { >>> 86: synchronized (JCAUtil.class) { >> >> Could this lock be avoided if set the value in the Providers update (or when the providers list is updated)? > > Well, then we have to pay the cost of "new SecureRandom()" at every provider list update when it may not be needed. It's hard to say which way is better... I thought about it and it seems more reasonable to only pay the cost when the SecureRandom object is needed. It makes sense to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3018 From pkumaraswamy at openjdk.java.net Thu Mar 18 07:12:59 2021 From: pkumaraswamy at openjdk.java.net (Prajwal Kumaraswamy) Date: Thu, 18 Mar 2021 07:12:59 GMT Subject: RFR: 8258753: StartTlsResponse.close() hangs due to synchronization issues Message-ID: **Scenario:** 1. Issue occurs in a muti-threaded environment where SSL socket read() and close() are invoked in parallel. 2. SSL socket read is already called. 2. close() calls waitForCloseNotify() -> decode() ->....-> socketRead0() to read the close_notify acknowledgment. 3. Since there is no synchronization between these read operations, the thread which had already invoked read(), reads the close_notify acknowledgment. 4. The thread (which calls waitForCloseNotify() -> read() ) waits indefinitely in socketRead0() and hangs. 5. Reproduced and tested the fix against a real time MS AD LDAP server. **Additional details:** 1. The issue occurs in JDK 8u261 and above. 2. JDK 8u251 works fine because it has synchronization along with the state of connection maintained. 3. Mach5 run is green. https://mach5.us.oracle.com/mdash/jobs/pkumaraswamy-jdk-jdk-2-20210317-1430-19174037 ------------- Commit messages: - 8258753: StartTlsResponse.close() hangs due to synchronization issues Changes: https://git.openjdk.java.net/jdk/pull/3068/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3068&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258753 Stats: 17 lines in 1 file changed: 8 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3068/head:pull/3068 PR: https://git.openjdk.java.net/jdk/pull/3068 From jlaskey at openjdk.java.net Thu Mar 18 12:59:44 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 18 Mar 2021 12:59:44 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31] In-Reply-To: References: Message-ID: <7yvwMppH8E53dxxutLQCRKg6UpiXwjzobRmjz9hOOHM=.d4b62b25-849e-4539-a207-f136a6e96b52@github.com> On Mon, 15 Mar 2021 23:07:53 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing @since > > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 62: > >> 60: @Retention(RetentionPolicy.RUNTIME) >> 61: @Target(ElementType.TYPE) >> 62: public @interface RandomGeneratorProperties { > > Should the is-deprecated information be stored here? I don't think so. That would require the deprecation state be stored in two places. I think it's sufficient to rely on the presence of @Deprecated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Thu Mar 18 13:04:43 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 18 Mar 2021 13:04:43 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31] In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 23:02:33 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing @since > > src/java.base/share/classes/java/util/Random.java line 135: > >> 133: * number generator which is maintained by method {@link #next}. >> 134: * >> 135: * @implSpec

The invocation {@code new Random(seed)} is equivalent to: > > This is not conventional formatting for an implSpec section. I suggest putting implSpec on its own line and then left-justifying the text as normal. A new paragraph tag is no needed at the beginning of implSpec. Adjusted ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Thu Mar 18 13:11:43 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 18 Mar 2021 13:11:43 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: References: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com> Message-ID: On Tue, 16 Mar 2021 20:37:57 GMT, Tommy Ettinger wrote: >> This is now looking very nicely structured. >> >> The only thing i am unsure are the details around `RandomGenerator` being a service provider interface. The documentation mentions this at various points (mostly as implementation notes), but it's not really called out on `RandomGenerator`. >> >> Trying out the patch, I can implement `RandomGenerator` and register it as a service: >> >> public class AlwaysZero implements RandomGenerator { >> @Override >> public long nextLong() { >> return 0; >> } >> } >> ... >> RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero"); >> >> >> Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not public). If i rename the above to `L32X64MixRandom` an `ExceptionInInitializerError` is produced due to duplicate keys. >> >> I suspect you want to filter out the service providers to those that only declare `RandomGeneratorProperties`, thereby restricting to providers only supplied by the platform. > > Has anyone here benchmarked this? I've run BumbleBench benchmarks (one of the AdoptOpenJDK team's tools, [available here](https://github.com/adoptium/bumblebench)) and I'm skeptical of the original claims in [JEP 356](https://openjdk.java.net/jeps/356), namely: > >> ...a new class of splittable PRNG algorithms (LXM) has also been discovered that are almost as fast [as SplittableRandom]... > > On my machine, L64X128MixRandom's algorithm is 53% slower than SplittableRandom, a halving in performance that I think would be inaccurate to describe as "almost as fast." I've benchmarked on Java 8 HotSpot (Windows 10, x64) and Java 15 OpenJ9 (same machine). On HotSpot, which I think is the main concern, I go from 1021770880 (over 1 billion) random longs per second with SplittableRandom to 479769280 (over 479 million) with my (I believe faithful) implementation of L64X128MixRandom. That is where I observed the 53% reduction. While SplittableRandom specifically seems to perform relatively badly on OpenJ9, with 893283072 longs per second (893 million), other similar random number generators do extremely well on OpenJ9; [LaserRandom](https://github.com/tommyettinger/jdkgdxds/blob/master/src/main/java/com/github/tommyettinger/ds/support/LaserRandom.java) generates 4232752128 random longs per second (4.2 billion) where L64X128MixRandom gets 840015872 (840 million). My benchmark repo is a mess, but if anyone wants to see and verify, [here it is](https://github.com/tommyettinger/assorted-benchmarks/tree/master/src/main/java/net/adoptopenjdk/bumblebench/examples). JMH benchmarks might provide different or just additional useful information; I've only run BumbleBench. > > One could make the argument that getting a random long from a PRNG takes so little time in the first place that it is unlikely to be a bottleneck, and by that logic, LXM is "almost as fast." However, if random generation is not being called often enough for its speed to matter, you are exceedingly unlikely to need so many (over 9 quintillion) parallel streams or such a long period per stream ((2 to the 192) minus (2 to the 64)). LXM is also 1-dimensionally equidistributed, while the foundation it is built on should allow 4-dimensional equidistribution (with the caveat of any LFSR that an all-zero state is impossible), with the same memory use per generator (4 longs), a longer period, and comparable quality using `xoshiro256**`, or possibly `xoshiro256++`, giving up streams but permitting twice as many leaps as LXM has streams if you maintain the same period as L64X128MixRandom. > > If I were implementing a PRNG to operate in a future official version of the JVM, I would definitely look into ways to use AES-NI, and I think the interfaces provided here should be valuable for any similar addition, even if I disagree with the provided implementations of those interfaces. Thank you for your time. > This is now looking very nicely structured. > > The only thing i am unsure are the details around `RandomGenerator` being a service provider interface. The documentation mentions this at various points (mostly as implementation notes), but it's not really called out on `RandomGenerator`. > > Trying out the patch, I can implement `RandomGenerator` and register it as a service: > > ```java > public class AlwaysZero implements RandomGenerator { > @Override > public long nextLong() { > return 0; > } > } > ... > RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero"); > ``` > > Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not public). If i rename the above to `L32X64MixRandom` an `ExceptionInInitializerError` is produced due to duplicate keys. > > I suspect you want to filter out the service providers to those that only declare `RandomGeneratorProperties`, thereby restricting to providers only supplied by the platform. Added the filter. > Has anyone here benchmarked this? I've run BumbleBench benchmarks (one of the AdoptOpenJDK team's tools, [available here](https://github.com/adoptium/bumblebench)) and I'm skeptical of the original claims in [JEP 356](https://openjdk.java.net/jeps/356), namely: > > > ...a new class of splittable PRNG algorithms (LXM) has also been discovered that are almost as fast [as SplittableRandom]... > > On my machine, L64X128MixRandom's algorithm is 53% slower than SplittableRandom, a halving in performance that I think would be inaccurate to describe as "almost as fast." I've benchmarked on Java 8 HotSpot (Windows 10, x64) and Java 15 OpenJ9 (same machine). On HotSpot, which I think is the main concern, I go from 1021770880 (over 1 billion) random longs per second with SplittableRandom to 479769280 (over 479 million) with my (I believe faithful) implementation of L64X128MixRandom. That is where I observed the 53% reduction. While SplittableRandom specifically seems to perform relatively badly on OpenJ9, with 893283072 longs per second (893 million), other similar random number generators do extremely well on OpenJ9; [LaserRandom](https://github.com/tommyettinger/jdkgdxds/blob/master/src/main/java/com/github/tommyettinger/ds/support/LaserRandom.java) generates 4232752128 random longs per second (4.2 billion) where L64X128MixRandom gets 840015872 (840 million). My benchmark repo is a mess, but if anyone wants to see and verify, [here it is](https://github.com/tommyettinger/assorted-benchmarks/tree/master/src/main/java/net/adoptopenjdk/bumblebench/examples). JMH benchmarks might provide different or just additional useful information; I've only run BumbleBench. > > One could make the argument that getting a random long from a PRNG takes so little time in the first place that it is unlikely to be a bottleneck, and by that logic, LXM is "almost as fast." However, if random generation is not being called often enough for its speed to matter, you are exceedingly unlikely to need so many (over 9 quintillion) parallel streams or such a long period per stream ((2 to the 192) minus (2 to the 64)). LXM is also 1-dimensionally equidistributed, while the foundation it is built on should allow 4-dimensional equidistribution (with the caveat of any LFSR that an all-zero state is impossible), with the same memory use per generator (4 longs), a longer period, and comparable quality using `xoshiro256**`, or possibly `xoshiro256++`, giving up streams but permitting twice as many leaps as LXM has streams if you maintain the same period as L64X128MixRandom. > > If I were implementing a PRNG to operate in a future official version of the JVM, I would definitely look into ways to use AES-NI, and I think the interfaces provided here should be valuable for any similar addition, even if I disagree with the provided implementations of those interfaces. Thank you for your time. Thanks for this feedback. -- Guy ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From redestad at openjdk.java.net Thu Mar 18 14:53:45 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Mar 2021 14:53:45 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base In-Reply-To: References: Message-ID: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt wrote: > Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. > > This fixes the issues in the `java.base` package for ease of reviewing. > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124 Marked as reviewed by redestad (Reviewer). src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52: > 50: * from server. > 51: */ > 52: //public static final int DOMAIN_UNMATCH = 3; Maybe this one ought to be removed instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From jlaskey at openjdk.java.net Thu Mar 18 15:08:56 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 18 Mar 2021 15:08:56 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v32] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits: - Merge branch 'master' into 8248862 - Review revisions - Missing @since - Review revisions - Review requested changes - Merge branch 'master' into 8248862 - Remove conflicts - Use isAnnotationPresent - Introduce isDeprecated - Update javadoc - ... and 57 more: https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=31 Stats: 13653 lines in 26 files changed: 11537 ins; 1821 del; 295 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From shade at openjdk.java.net Thu Mar 18 15:10:38 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 18 Mar 2021 15:10:38 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base In-Reply-To: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> References: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> Message-ID: <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com> On Wed, 17 Mar 2021 12:31:22 GMT, Claes Redestad wrote: >> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. >> >> This fixes the issues in the `java.base` package for ease of reviewing. >> >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124 > > src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52: > >> 50: * from server. >> 51: */ >> 52: //public static final int DOMAIN_UNMATCH = 3; > > Maybe this one ought to be removed instead? Yeah, I agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From github.com+76791+alblue at openjdk.java.net Thu Mar 18 16:47:40 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Thu, 18 Mar 2021 16:47:40 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base In-Reply-To: <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com> References: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com> Message-ID: On Thu, 18 Mar 2021 15:08:09 GMT, Aleksey Shipilev wrote: >> src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52: >> >>> 50: * from server. >>> 51: */ >>> 52: //public static final int DOMAIN_UNMATCH = 3; >> >> Maybe this one ought to be removed instead? > > Yeah, I agree. Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From github.com+76791+alblue at openjdk.java.net Thu Mar 18 16:53:40 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Thu, 18 Mar 2021 16:53:40 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base In-Reply-To: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> References: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> Message-ID: On Thu, 18 Mar 2021 14:50:43 GMT, Claes Redestad wrote: >> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. >> >> This fixes the issues in the `java.base` package for ease of reviewing. >> >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124 > > Marked as reviewed by redestad (Reviewer). If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them? ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From redestad at openjdk.java.net Thu Mar 18 16:53:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Mar 2021 16:53:40 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base In-Reply-To: References: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com> Message-ID: <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com> On Thu, 18 Mar 2021 16:42:39 GMT, Alex Blewitt wrote: >> Yeah, I agree. > > Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes. There's another constant with value 3 defined, so I think this is just some left-over. If you prefer separating out the removal to another RFE I'd remove this particular change from this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From github.com+76791+alblue at openjdk.java.net Thu Mar 18 17:02:57 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Thu, 18 Mar 2021 17:02:57 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2] In-Reply-To: References: Message-ID: <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com> > Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. > > This fixes the issues in the `java.base` package for ease of reviewing. > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124 Alex Blewitt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8263658: Use the blessed modifier order in java.base ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2993/files - new: https://git.openjdk.java.net/jdk/pull/2993/files/470f7066..86aa9a34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2993/head:pull/2993 PR: https://git.openjdk.java.net/jdk/pull/2993 From github.com+76791+alblue at openjdk.java.net Thu Mar 18 17:02:57 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Thu, 18 Mar 2021 17:02:57 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2] In-Reply-To: <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com> References: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com> <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com> Message-ID: <3uerJX_48Cm81fytVhYU__vSyWnHNBkBkjVyhvkwAIw=.0d4c85de-ff4e-4d10-883c-156ebc9b13a3@github.com> On Thu, 18 Mar 2021 16:50:39 GMT, Claes Redestad wrote: >> Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes. > > There's another constant with value 3 defined, so I think this is just some left-over. > > If you prefer separating out the removal to another RFE I'd remove this particular change from this PR. Filed #3076 for the removal and updated this PR without it ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From redestad at openjdk.java.net Thu Mar 18 17:08:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Mar 2021 17:08:39 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2] In-Reply-To: References: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> Message-ID: <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com> On Thu, 18 Mar 2021 16:51:35 GMT, Alex Blewitt wrote: > If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them? Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules. A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts. ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From github.com+76791+alblue at openjdk.java.net Thu Mar 18 17:08:40 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Thu, 18 Mar 2021 17:08:40 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2] In-Reply-To: <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com> References: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com> Message-ID: On Thu, 18 Mar 2021 17:03:28 GMT, Claes Redestad wrote: >> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them? > >> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them? > > Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules. > > A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts. I'm happy to either widen the scope of this PR or to submit multiple but I have to rely on the kindness of strangers to create appropriate bugs in the system. On the one hand I don't want to cause a lot of noise but on the other having smaller independent commits (particularly if they hit a lot of files/modules) seems like a more sensible plan to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From jnimeh at openjdk.java.net Thu Mar 18 17:09:42 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 18 Mar 2021 17:09:42 GMT Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 20:40:05 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this change to ECDH. It is a combination of fixing the implementation to not only accept ECPrivateKeyImpl along with a fix to the exception handling. They started as two fixes, but with the exception handling the underlying code changed significantly that made the ECPrivateKey change in a different place. The new exception handling is a result of no longer having the native library. Many of the checks waited until generateSecret() to send the keys to the native library. Now that native is gone, checks can happen when keys are provided to the methods and proper exceptions can be thrown instead of wrapping everything as a ProviderException >> >> thanks, >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > Simpler fix for ECPrivateKey src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 211: > 209: try { > 210: result = deriveKeyImpl(privateKey, privateKeyOps, publicKey); > 211: } catch (Exception e) { Why such a broad exception catch here? It looks like deriveKeyImpl is only explicitly throwing IKE. Are there other unchecked exceptions that you're trying to snag here that I'm missing in the deriveKeyImpl below? ------------- PR: https://git.openjdk.java.net/jdk/pull/2659 From jnimeh at openjdk.java.net Thu Mar 18 17:13:41 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 18 Mar 2021 17:13:41 GMT Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 20:40:05 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this change to ECDH. It is a combination of fixing the implementation to not only accept ECPrivateKeyImpl along with a fix to the exception handling. They started as two fixes, but with the exception handling the underlying code changed significantly that made the ECPrivateKey change in a different place. The new exception handling is a result of no longer having the native library. Many of the checks waited until generateSecret() to send the keys to the native library. Now that native is gone, checks can happen when keys are provided to the methods and proper exceptions can be thrown instead of wrapping everything as a ProviderException >> >> thanks, >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > Simpler fix for ECPrivateKey test/jdk/com/sun/crypto/provider/KeyAgreement/ECKeyCheck.java line 27: > 25: * @test > 26: * @bug 8238911 > 27: * @summary Check that ECPrivateKey's that are not ECPrivateKeyImpl can use Do the bug and summary tags need to be updated to 8261502 and "ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling", respectively? ------------- PR: https://git.openjdk.java.net/jdk/pull/2659 From redestad at openjdk.java.net Thu Mar 18 17:15:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Mar 2021 17:15:38 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2] In-Reply-To: References: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com> <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com> Message-ID: On Thu, 18 Mar 2021 17:06:04 GMT, Alex Blewitt wrote: >>> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them? >> >> Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules. >> >> A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts. > > I'm happy to either widen the scope of this PR or to submit multiple but I have to rely on the kindness of strangers to create appropriate bugs in the system. On the one hand I don't want to cause a lot of noise but on the other having smaller independent commits (particularly if they hit a lot of files/modules) seems like a more sensible plan to me. There's some extra churn in splitting it up, sure, but different modules are often maintained by different people so getting changes that span the entire JDK reviewed might actually take you longer. YMMV. I can assist creating RFEs. ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From github.com+76791+alblue at openjdk.java.net Thu Mar 18 17:23:57 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Thu, 18 Mar 2021 17:23:57 GMT Subject: RFR: 8263825: Remove unused and commented out member from NTLMException Message-ID: Removed commented out value from `NTLMException` ------------- Commit messages: - 8263825: Remove unused and commented out member from NTLMException Changes: https://git.openjdk.java.net/jdk/pull/3076/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3076&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263825 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3076.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3076/head:pull/3076 PR: https://git.openjdk.java.net/jdk/pull/3076 From github.com+76791+alblue at openjdk.java.net Thu Mar 18 17:23:57 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Thu, 18 Mar 2021 17:23:57 GMT Subject: RFR: 8263825: Remove unused and commented out member from NTLMException In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 16:57:59 GMT, Alex Blewitt wrote: > Removed commented out value from `NTLMException` See commentary on #2993 ------------- PR: https://git.openjdk.java.net/jdk/pull/3076 From redestad at openjdk.java.net Thu Mar 18 17:23:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Mar 2021 17:23:57 GMT Subject: RFR: 8263825: Remove unused and commented out member from NTLMException In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 16:58:31 GMT, Alex Blewitt wrote: >> Removed commented out value from `NTLMException` > > See commentary on #2993 Filed [JDK-8263825](https://bugs.openjdk.java.net/browse/JDK-8263825) for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3076 From luoziyi at openjdk.java.net Thu Mar 18 17:30:55 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Thu, 18 Mar 2021 17:30:55 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4] In-Reply-To: References: Message-ID: > This is a P2 regression introduced by JDK-8254717. > > In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: > > X-axis: type of `keySpec` > Y-axis: type of `key` > > Before JDK-8254717: > > | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | > |--|--|--| > | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | > | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | > > After JDK-8254717 (Green check is what we want to fix, red cross is the regression): > > | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | > |--|--|--| > | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | > | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | > > This commit fixes the regression. > > > ### Tests > > * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed > * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed Ziyi Luo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Fix P11RSAKeyFactory and add one more jtreg test - Add one test case for the regression fixed by 8263404 - Fix jcheck whitespace error - 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec ------------- Changes: https://git.openjdk.java.net/jdk/pull/2949/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2949&range=03 Stats: 211 lines in 4 files changed: 162 ins; 15 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/2949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2949/head:pull/2949 PR: https://git.openjdk.java.net/jdk/pull/2949 From redestad at openjdk.java.net Thu Mar 18 17:51:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Mar 2021 17:51:40 GMT Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2] In-Reply-To: <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com> References: <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com> Message-ID: On Thu, 18 Mar 2021 17:02:57 GMT, Alex Blewitt wrote: >> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. >> >> This fixes the issues in the `java.base` package for ease of reviewing. >> >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124 > > Alex Blewitt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2993 From github.com+829871+salusasecondus at openjdk.java.net Thu Mar 18 19:00:41 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Thu, 18 Mar 2021 19:00:41 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4] In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 17:30:55 GMT, Ziyi Luo wrote: >> This is a P2 regression introduced by JDK-8254717. >> >> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow: >> >> X-axis: type of `keySpec` >> Y-axis: type of `key` >> >> Before JDK-8254717: >> >> | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | >> |--|--|--| >> | RSAPrivateKey | Return RSAPrivateKeySpec | Throw `InvalidKeySpecException` | >> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec | >> >> After JDK-8254717 (Green check is what we want to fix, red cross is the regression): >> >> | | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class | >> |--|--|--| >> | RSAPrivateKey | Throw `InvalidKeySpecException` ? | Throw `InvalidKeySpecException` | >> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec | >> >> This commit fixes the regression. >> >> >> ### Tests >> >> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed >> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed > > Ziyi Luo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Fix P11RSAKeyFactory and add one more jtreg test > - Add one test case for the regression fixed by 8263404 > - Fix jcheck whitespace error > - 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec This looks to cover the cases and fixes we talked about. ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From mullan at openjdk.java.net Thu Mar 18 20:12:49 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 18 Mar 2021 20:12:49 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v8] In-Reply-To: References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> Message-ID: <8HIw6ojmLhQ7-5jSLN8M-I3QBzsyNYlaAN2UrZfLqfY=.e3dcb02f-885e-4fcb-bda5-7257c90882d3@github.com> On Thu, 11 Mar 2021 00:06:50 GMT, Weijun Wang wrote: >> This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario 2.2.0. >> >> The first step is an auto-import. The JDK implementation is removed first and Santuario code are imported. Some unrelated files (Ex: encryption) are removed, and package names are renamed to be internal. There are also some bulk changes on company name, comment style, and white spaces. >> >> Next steps are patches applied by JDK. Some are old patches before the last import. Some are new. >> >> Several tests need to be updated because of internal method signature changes. > > Weijun Wang 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 15 additional commits since the last revision: > > - Merge branch 'master' into 8255255 > - reapply 8259535: ECDSA SignatureValue do not always have the specified length > - No more newInstance calls > - Reapply 8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() > - Fix test failures > - Supporting named RSASSA-PSS without parameters > - Reapply 8008744: Rework part of fix for JDK-6741606 > - Reapply 8151893: Add security property to configure XML Signature secure validation mode > > Reapply 8140353: Improve signature checking > - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes > - Reapply 8038913: Bolster XML support (Init.java part) > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/af85e647...60496847 Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1206 From luoziyi at openjdk.java.net Thu Mar 18 20:28:39 2021 From: luoziyi at openjdk.java.net (Ziyi Luo) Date: Thu, 18 Mar 2021 20:28:39 GMT Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4] In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 18:57:57 GMT, SalusaSecondus wrote: >> Ziyi Luo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Fix P11RSAKeyFactory and add one more jtreg test >> - Add one test case for the regression fixed by 8263404 >> - Fix jcheck whitespace error >> - 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec > > This looks to cover the cases and fixes we talked about. @valeriepeng Sorry for the delay. There were unknown Windows build failure during the pre-submit tests that I have to rebase my commits on top of the master tip. This new revision should cover all comments you left before. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/2949 From github.com+829871+salusasecondus at openjdk.java.net Thu Mar 18 21:29:40 2021 From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus) Date: Thu, 18 Mar 2021 21:29:40 GMT Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 16:33:10 GMT, Xue-Lei Andrew Fan wrote: >> This is my implementation for [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables creating of an SSL/TLS key log in the standardized [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format). This is supported by many TLS implementations and also by several parsers such as Wireshark. Supporting this will greatly ease in debugging TLS problems. >> >> (Note: I am covered by the Amazon corporate contribution agreement). > > It is not good practice to leave secret information in debug log. Also, it may be not a good practice to introduce new logger format, including file and NSS format, into the SSLLogger. Someone also may want to introduce log format for MSS or XSS as well. Instead, please consider to make use of the features of Java Logger if you want to write the log to files, or use any special format. @XueleiFan I'd really like to move this forward but I'm uncertain what changes you want me to make. This extra debugging information will be very valuable to those of us debugging Java TLS connections. ------------- PR: https://git.openjdk.java.net/jdk/pull/2896 From darcy at openjdk.java.net Thu Mar 18 21:54:46 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 18 Mar 2021 21:54:46 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v32] In-Reply-To: References: Message-ID: <_uMAp-rI5lz4tzevS6jXiPsD_X6SSqequ5Gd5tc0lg8=.7cceb178-3fdc-46ee-86c4-99b2944d9e04@github.com> On Thu, 18 Mar 2021 15:08:56 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits: > > - Merge branch 'master' into 8248862 > - Review revisions > - Missing @since > - Review revisions > - Review requested changes > - Merge branch 'master' into 8248862 > - Remove conflicts > - Use isAnnotationPresent > - Introduce isDeprecated > - Update javadoc > - ... and 57 more: https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d Changes requested by darcy (Reviewer). src/java.base/share/classes/java/util/random/RandomGenerator.java line 1290: > 1288: * @return a new object that is a copy of this generator > 1289: */ > 1290: LeapableGenerator copy(); Suggest adding an Override annotation here and possibly to inheritDoc the text from Jumpable.copy. src/java.base/share/classes/java/util/random/RandomGenerator.java line 1455: > 1453: * period of this generator > 1454: */ > 1455: void jump(double distance); Suggest Override and inheritDoc combo. src/java.base/share/classes/java/util/random/RandomGenerator.java line 1465: > 1463: * @implSpec The default implementation invokes jump(jumpDistance()). > 1464: */ > 1465: default void jump() { jump(jumpDistance()); } Should be able to avoid defining the jump method in this subinterface. src/java.base/share/classes/java/util/random/RandomGenerator.java line 1486: > 1484: * ({@link Long#MAX_VALUE Long.MAX_VALUE}). > 1485: */ > 1486: default Stream jumps(double distance) { Suggest adding an Override annotation. src/java.base/share/classes/java/util/random/RandomGenerator.java line 1521: > 1519: * {@link ArbitrarilyJumpableGenerator#leapDistance() leapDistance}(). > 1520: */ > 1521: default void leap() { jump(leapDistance()); } Should need to define this method in the subinterface of Leapable. src/java.base/share/classes/java/util/random/RandomGenerator.java line 1538: > 1536: * returns the copy. > 1537: */ > 1538: default ArbitrarilyJumpableGenerator copyAndJump(double distance) { Suggest Override and inheritDoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From weijun at openjdk.java.net Thu Mar 18 22:06:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 18 Mar 2021 22:06:42 GMT Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v8] In-Reply-To: <8HIw6ojmLhQ7-5jSLN8M-I3QBzsyNYlaAN2UrZfLqfY=.e3dcb02f-885e-4fcb-bda5-7257c90882d3@github.com> References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com> <8HIw6ojmLhQ7-5jSLN8M-I3QBzsyNYlaAN2UrZfLqfY=.e3dcb02f-885e-4fcb-bda5-7257c90882d3@github.com> Message-ID: On Thu, 18 Mar 2021 20:10:20 GMT, Sean Mullan wrote: >> Weijun Wang 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 15 additional commits since the last revision: >> >> - Merge branch 'master' into 8255255 >> - reapply 8259535: ECDSA SignatureValue do not always have the specified length >> - No more newInstance calls >> - Reapply 8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() >> - Fix test failures >> - Supporting named RSASSA-PSS without parameters >> - Reapply 8008744: Rework part of fix for JDK-6741606 >> - Reapply 8151893: Add security property to configure XML Signature secure validation mode >> >> Reapply 8140353: Improve signature checking >> - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes >> - Reapply 8038913: Bolster XML support (Init.java part) >> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/e52863e8...60496847 > > Marked as reviewed by mullan (Reviewer). Below is the script to import Santuario 2.2.1 at the beginning. Recorded here so we can reuse it next time. $ cat ~/work/xmlsec/import #! /bin/bash realpath() { [[ $1 = /* ]] && echo "$1" || echo "$PWD/${1#./}" } HERE=$(dirname $(realpath $0)) V=2.2.1 BUNDLE=/Users/weijun/work/xmlsec/xmlsec-$V-source-release.zip # WORK=$(hg root)/src/java.xml.crypto WORK=/Users/weijun/repos/openjdk/x/open/src/java.xml.crypto mkdir -p $WORK/share/classes cd $WORK/share/classes unzip $BUNDLE \ 'xmlsec-'$V'/src/main/java/org/apache/xml/security/*' \ 'xmlsec-'$V'/src/main/java/org/apache/jcp/xml/dsig/internal/*' echo Patching impl... rm -rf com mkdir -p com/sun/org/apache/xml/internal mv xmlsec-$V/src/main/java/org/apache/xml/security com/sun/org/apache/xml/internal/ rm -rf com/sun/org/apache/xml/internal/security/stax/ rm -rf com/sun/org/apache/xml/internal/security/encryption rm -rf com/sun/org/apache/xml/internal/security/binding/ rm -rf com/sun/org/apache/xml/internal/security/configuration/ rm -rf com/sun/org/apache/xml/internal/security/resource/schema/ rm com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayInputStream.java rm com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/EncryptedKeyResolver.java echo Patching provider... rm -rf org mkdir -p org/jcp/xml/dsig mv xmlsec-$V/src/main/java/org/apache/jcp/xml/dsig/internal org/jcp/xml/dsig/ rm -rf xmlsec-$V echo Updating package names... for a in `find com org -type f`; do perl -i -p $HERE/trans.pl $a head -2 $a | grep -q "Licensed to the Apache Software Foundation" && cat < tmptmp && mv tmptmp $a /* * reserved comment block * DO NOT REMOVE OR ALTER! */ EOF done cat < /dev/null make clean-java.xml.crypto make JAVAC_WARNINGS=-Xlint:none java.xml.crypto-java-only sh src/java.xml.crypto/import hg addremove hg diff > .hg/patches/santuario-copy hg revert -a && hg purge EOF x $ cat ~/work/xmlsec/trans.pl #! /usr/bin/perl # Styles s/\t/ /g; s/ +$//; s/bugs.sun.com/bugs.java.com/; s/(.*?)<.code>/{@code $1}/gi; s/

/<pre>{@code/;
s//}/;
s/(20\d\d) Sun Microsystems, Inc/(c) $1, Oracle and/or its affiliates/;
s/Portions copyright/Copyright/;

# Source
s/org.apache.xml.security/com.sun.org.apache.xml.internal.security/g;
s/org.apache.jcp/org.jcp/g;

# Dependencies reimplemented
s/org.slf4j/com.sun.org.slf4j.internal/g;

# Dependencies elsewhere
s/org.apache.xml.dtm/com.sun.org.apache.xml.internal.dtm/;
s/([ "])org.apache.xpath/$1com.sun.org.apache.xpath.internal/;
s/org.apache.xml.utils/com.sun.org.apache.xml.internal.utils/;

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

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

From valeriep at openjdk.java.net  Thu Mar 18 23:20:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 18 Mar 2021 23:20:40 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 18 Mar 2021 17:30:55 GMT, Ziyi Luo  wrote:

>> This is a P2 regression introduced by JDK-8254717.
>> 
>> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
>> 
>> X-axis: type of `keySpec`
>> Y-axis: type of `key`
>> 
>> Before JDK-8254717:
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
>> 
>> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
>> 
>> This commit fixes the regression.
>> 
>> 
>> ### Tests
>> 
>> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
>> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed
>
> Ziyi Luo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Fix P11RSAKeyFactory and add one more jtreg test
>  - Add one test case for the regression fixed by 8263404
>  - Fix jcheck whitespace error
>  - 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec

src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 430:

> 428:             } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
> 429:                 throw new InvalidKeySpecException
> 430:                         ("RSAPrivateCrtKeySpec can only be used with CRT keys");

If we are basing the decision on type of key, it may be clearer to do something like below:
        } else if (key instanceof RSAPrivateKey) {
            if (keySpec.isAssignableFrom(PKCS8_KEYSPEC_CLS)) {
                return keySpec.cast(new PKCS8EncodedKeySpec(key.getEncoded()));
            } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
                if (key instanceof RSAPrivateCrtKey) {
                    RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey)key;
                    return keySpec.cast(new RSAPrivateCrtKeySpec(
                        crtKey.getModulus(),
                        crtKey.getPublicExponent(),
                        crtKey.getPrivateExponent(),
                        crtKey.getPrimeP(),
                        crtKey.getPrimeQ(),
                        crtKey.getPrimeExponentP(),
                        crtKey.getPrimeExponentQ(),
                        crtKey.getCrtCoefficient(),
                        crtKey.getParams()
                    ));
                } else { // RSAPrivateKey (non-CRT)
                    if (!keySpec.isAssignableFrom(RSA_PRIV_KEYSPEC_CLS)) {
                        throw new InvalidKeySpecException
                            ("RSAPrivateCrtKeySpec can only be used with CRT keys");
                    }

                    // fall through to RSAPrivateKey (non-CRT)
                    RSAPrivateKey rsaKey = (RSAPrivateKey) key;
                    return keySpec.cast(new RSAPrivateKeySpec(
                        rsaKey.getModulus(),
                        rsaKey.getPrivateExponent(),
                        rsaKey.getParams()
                    ));
                }
            } else {
                throw new InvalidKeySpecException
                        ("KeySpec must be RSAPrivate(Crt)KeySpec or "
                        + "PKCS8EncodedKeySpec for RSA private keys");
            }

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

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

From valeriep at openjdk.java.net  Thu Mar 18 23:26:42 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 18 Mar 2021 23:26:42 GMT
Subject: Integrated: 8260274: Cipher.init(int,
 key) does not use highest priority provider for random bytes
In-Reply-To: 
References: 
Message-ID: 

On Mon, 15 Mar 2021 20:39:13 GMT, Valerie Peng  wrote:

> Can someone help review this somewhat trivial change?
> 
> Updated JCAUtil class to return the cached SecureRandom object only when the provider configuration has not changed. 
> Added a regression test to check the affected classes, i.e. AlgorithmParameterGenerator, KeyPairGenerator, Cipher, KeyAgreement, KeyGenerator. 
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 434a399b
Author:    Valerie Peng 
URL:       https://git.openjdk.java.net/jdk/commit/434a399b
Stats:     244 lines in 8 files changed: 225 ins; 1 del; 18 mod

8260274: Cipher.init(int, key) does not use highest priority provider for random bytes

Reviewed-by: ascarpino, xuelei

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

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

From github.com+829871+salusasecondus at openjdk.java.net  Fri Mar 19 03:21:40 2021
From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus)
Date: Fri, 19 Mar 2021 03:21:40 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 18 Mar 2021 23:17:51 GMT, Valerie Peng  wrote:

>> Ziyi Luo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Fix P11RSAKeyFactory and add one more jtreg test
>>  - Add one test case for the regression fixed by 8263404
>>  - Fix jcheck whitespace error
>>  - 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec
>
> src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 430:
> 
>> 428:             } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
>> 429:                 throw new InvalidKeySpecException
>> 430:                         ("RSAPrivateCrtKeySpec can only be used with CRT keys");
> 
> If we are basing the decision on type of key, it may be clearer to do something like below:
>         } else if (key instanceof RSAPrivateKey) {
>             if (keySpec.isAssignableFrom(PKCS8_KEYSPEC_CLS)) {
>                 return keySpec.cast(new PKCS8EncodedKeySpec(key.getEncoded()));
>             } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
>                 if (key instanceof RSAPrivateCrtKey) {
>                     RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey)key;
>                     return keySpec.cast(new RSAPrivateCrtKeySpec(
>                         crtKey.getModulus(),
>                         crtKey.getPublicExponent(),
>                         crtKey.getPrivateExponent(),
>                         crtKey.getPrimeP(),
>                         crtKey.getPrimeQ(),
>                         crtKey.getPrimeExponentP(),
>                         crtKey.getPrimeExponentQ(),
>                         crtKey.getCrtCoefficient(),
>                         crtKey.getParams()
>                     ));
>                 } else { // RSAPrivateKey (non-CRT)
>                     if (!keySpec.isAssignableFrom(RSA_PRIV_KEYSPEC_CLS)) {
>                         throw new InvalidKeySpecException
>                             ("RSAPrivateCrtKeySpec can only be used with CRT keys");
>                     }
> 
>                     // fall through to RSAPrivateKey (non-CRT)
>                     RSAPrivateKey rsaKey = (RSAPrivateKey) key;
>                     return keySpec.cast(new RSAPrivateKeySpec(
>                         rsaKey.getModulus(),
>                         rsaKey.getPrivateExponent(),
>                         rsaKey.getParams()
>                     ));
>                 }
>             } else {
>                 throw new InvalidKeySpecException
>                         ("KeySpec must be RSAPrivate(Crt)KeySpec or "
>                         + "PKCS8EncodedKeySpec for RSA private keys");
>             }

I like this flow and think that it's clearer.

One question: Do you think we could use this code almost character for character in the `P11RSAKeyFactory`? The keys handled should be descendants of `RSAPrivateCrtKey`, `RSAPrivateKey`, or `P11PrivateKey` (which would need some special handling). I didn't want to refactor it that much even though I think that it would work because I assume it must have been written to use the underlying PKCS#11 properties for *some* reason (even if I cannot figure out why).

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

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

From mullan at openjdk.java.net  Fri Mar 19 12:48:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 19 Mar 2021 12:48:43 GMT
Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS
 keys
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 18 Mar 2021 21:26:28 GMT, SalusaSecondus  wrote:

>> It is not good practice to leave secret information in debug log. Also, it may be not a good practice to introduce new logger format, including file and NSS format, into the SSLLogger.  Someone also may want to introduce log format for MSS or XSS as well. Instead, please consider to make use of the features of Java Logger if you want to write the log to files, or use any special format.
>
> @XueleiFan I'd really like to move this forward but I'm uncertain what changes you want me to make. This extra debugging information will be very valuable to those of us debugging Java TLS connections.

I am also not comfortable adding this feature to the JDK, especially since every build of the JDK would by default have this feature enabled. Logging sensitive information to log files is not good security practice (there are many references I could cite). I also think it would be too easy to accidentally leave the system property enabled or forget to remove the file.

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:09:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:09:40 GMT
Subject: Integrated: 8263658: Use the blessed modifier order in java.base
In-Reply-To: 
References: 
Message-ID: <8mDze9YmhXvmW4gbfQLalR266LqHkNACv0ggx-z8d9E=.b33aab37-39ce-4e3c-85c4-8f5a6ebc53d7@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt  wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

This pull request has now been integrated.

Changeset: b49c5893
Author:    Alex Blewitt 
Committer: Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/b49c5893
Stats:     139 lines in 28 files changed: 0 ins; 0 del; 139 mod

8263658: Use the blessed modifier order in java.base

Reviewed-by: rriggs, redestad

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt  wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in java.management/naming
Message-ID: 

As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

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

Commit messages:
 - Use the blessed modifier order in java.management/naming

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 18 Mar 2021 19:33:59 GMT, Alex Blewitt  wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.

@cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?

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

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

From redestad at openjdk.java.net  Fri Mar 19 13:11:46 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 13:11:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: 
References: 
 
 
Message-ID: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>

On Fri, 19 Mar 2021 10:20:39 GMT, Alex Blewitt  wrote:

>> Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.
>
> @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?

Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
References: 
 
 
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
Message-ID: 

On Fri, 19 Mar 2021 11:01:45 GMT, Claes Redestad  wrote:

>> @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?
>
> Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.

Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.

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

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

From norman.maurer at googlemail.com  Fri Mar 19 13:15:36 2021
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Fri, 19 Mar 2021 14:15:36 +0100
Subject: Bug with TLSv1.3 session resumption (most likely caused by
 concurrency bug)
In-Reply-To: <231bbe52-fa50-0370-c3d9-6aebaa7863aa@oracle.com>
References: <231bbe52-fa50-0370-c3d9-6aebaa7863aa@oracle.com>
Message-ID: 

I was wondering if there is any update or anything I can help with ?

Bye
Norman 

> Am 04.03.2021 um 18:51 schrieb Jamil Nimeh :
> 
> ?
> I already replied to Norman directly (because apparently I cannot seem to find my Reply-all button before my morning caffeine!).  It does look quite a bit like 8241248 and that issue is in my bug queue.  I haven't started work on it yet, but now that Norman has provided me some links to a reproducer I can give it a spin and see if I can make the bug happen locally (Thanks Norman!)
> 
> --Jamil
> 
>> On 3/4/2021 8:22 AM, Xue-Lei Fan wrote:
>> Forward to security-dev.
>> 
>> Xuelei
>> 
>>> On Mar 4, 2021, at 6:11 AM, Norman Maurer  wrote:
>>> 
>>> Hi there,
>>> 
>>> I think I found a bug in the TLSv1.3 session cache implementation which sometimes can cause failures during session resumption. 
>>> The cause of this sometimes show up as NPE:
>>> 
>>> javax.net.ssl.SSLException: Session has no PSK
>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
>>> at java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537)
>>> at java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528)
>>> at java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583)
>>> at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222)
>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539)
>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282)
>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329)
>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
>>> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>>> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
>>> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
>>> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>>> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>>> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>>> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>>> at java.base/java.lang.Thread.run(Thread.java:834)
>>> java.lang.NullPointerException
>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93)
>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119)
>>> at java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1169)
>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:547)
>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282)
>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329)
>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
>>> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>>> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
>>> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
>>> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>>> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>>> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>>> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>>> at java.base/java.lang.Thread.run(Thread.java:834)
>>> 
>>> 
>>> Other times the NPE is not included but it still fails with something like:
>>> 
>>> Caused by: javax.net.ssl.SSLException: Session has no PSK
>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
>>> at java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537)
>>> at java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528)
>>> at java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583)
>>> at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222)
>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539)
>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282)
>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329)
>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
>>> ... 17 common frames omitted
>>> 
>>> Looking at the first stacktrace this seems to be related to:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8241248
>>> 
>>> 
>>> Unfortunately I don?t have a reproducer which uses the JDK only here but I can reproduce this with Netty that uses OpenSSL on the client side and the JDK SSLEngine on the server side.
>>> I can reproduce this with the latest JDK11 release but can't with JDK15. Also what makes me believe it may be a concurrency bug is that only some handshakes fail. Like 70 out of 2600 fail.
>>> 
>>> While the reproducer also involves netty I am wondering if you would still be interested in it ? It should be quite straight forward to run locally for you.
>>> 
>>> The code that can reproduce it is here:
>>> https://github.com/netty/netty/pull/10994#issuecomment-787976965
>>> 
>>> Also you will need to use this branch:
>>> https://github.com/netty/netty/tree/ssl_cache_revamp
>>> 
>>> 
>>> Please don?t hesitate if you have questions,
>>> Norman
>>> 
>>> 
>>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From redestad at openjdk.java.net  Fri Mar 19 13:30:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 13:30:39 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: 
References: 
 
 
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
 
Message-ID: 

On Fri, 19 Mar 2021 13:08:24 GMT, Alex Blewitt  wrote:

>> Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.
>
> Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.

No, the git commit messages here doesn't matter, the bots will use the PR name when merging into master. It's good form to use reasonably consistent commit messages as you add commits to a PR, but altering commit history is not necessary and might even be disruptive once a PR has been opened.

There's the /summary command you could use to add additional comments to the final commit, see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/summary

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:34:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:34:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: 
References: 
 
 
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
 
 
Message-ID: 

On Fri, 19 Mar 2021 13:28:12 GMT, Claes Redestad  wrote:

>> Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.
>
> No, the git commit messages here doesn't matter, the bots will use the PR name when merging into master. It's good form to use reasonably consistent commit messages as you add commits to a PR, but altering commit history is not necessary and might even be disruptive once a PR has been opened.
> 
> There's the /summary command you could use to add additional comments to the final commit, see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/summary

Thanks @cl4es will adjust my submissions appropriately in the future.

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

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

From redestad at openjdk.java.net  Fri Mar 19 14:13:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 14:13:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt  wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

Overall good - found a few cases where the private modifier is in the wrong place that ought to be fixed as well.

src/java.naming/share/classes/com/sun/jndi/ldap/EventQueue.java line 48:

> 46:  */
> 47: final class EventQueue implements Runnable {
> 48:     static final private boolean debug = false;

Move private to the front?

src/java.naming/share/classes/com/sun/jndi/ldap/EventSupport.java line 116:

> 114:  */
> 115: final class EventSupport {
> 116:     static final private boolean debug = false;

Move private to the front?

src/java.naming/share/classes/com/sun/jndi/ldap/LdapSchemaCtx.java line 389:

> 387:     }
> 388: 
> 389:     static final private class SchemaInfo {

Move private to the front?

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

Changes requested by redestad (Reviewer).

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

From github.com+829871+salusasecondus at openjdk.java.net  Fri Mar 19 14:49:39 2021
From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus)
Date: Fri, 19 Mar 2021 14:49:39 GMT
Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS
 keys
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 19 Mar 2021 12:45:43 GMT, Sean Mullan  wrote:

>> @XueleiFan I'd really like to move this forward but I'm uncertain what changes you want me to make. This extra debugging information will be very valuable to those of us debugging Java TLS connections.
>
> I am also not comfortable adding this feature to the JDK, especially since every build of the JDK would by default have this feature enabled. Logging sensitive information to log files is not good security practice (there are many references I could cite). I also think it would be too easy to accidentally leave the system property enabled or forget to remove the file.

I think that there might be some confusion around the sensitivity of the data being logged. The security impact of this data is almost identical to passing `-Djavax.net.debug=plaintext,packet` to the JVM. This existing setting logs all plaintext (as well as wire-data) to STDERR. The new feature I'm proposing just lets a second application decrypt the wire-data to access the plaintext, which results in the same level of exposed data. (As an improvement over the existing feature, it outputs the data in a standardized format so that it is easier to analyze rather than being in a Java-specific format and co-mingled with all other STDERR output.)

Similar to the existing feature, the data logged only impacts the exact connections that it is enabled for. (These are ephemeral session-specific secrets).

I hope that this helps to ease some concerns and help explain why this exact feature is present in so many existing applications (including OpenSSL, BoringSSL, WolfSSL, s2n, Mozilla, and Chrome, among others).  If you would like to try it with your current Chrome browser, just add ` --ssl-key-log-file=/path/to/chrome_keys.txt` to the command-line. For Firefox, I believe you need to set the `SSLKEYLOGFILE` environment variable to the name of the log-file.

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

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

From hohensee at amazon.com  Fri Mar 19 15:21:27 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 19 Mar 2021 15:21:27 +0000
Subject: [11u] RFR 8259886: Improve SSL session cache performance and
 scalability
In-Reply-To: 
References: 
Message-ID: 

Pushed. In the future, it'd be great if you used "git hg-export" (one of the Skara tools) to generate the base changeset, because it includes the commit metadata we want to preserve in the 11u hg repo.

Thanks,
Paul

?-----Original Message-----
From: security-dev  on behalf of "Hohensee, Paul" 
Date: Wednesday, March 17, 2021 at 1:01 PM
To: Daniel Jeli?ski 
Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" 
Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability

Np, tagged.

-----Original Message-----
From: Daniel Jeli?ski 
Date: Tuesday, March 16, 2021 at 11:40 PM
To: "Hohensee, Paul" 
Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" 
Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability

Thanks again Paul.

Could you sponsor the change? As far as I can tell, I'd need to add a
fix request now, but I don't have access to issue tracker.
Thanks,
Daniel

wt., 16 mar 2021 o 18:59 Hohensee, Paul  napisa?(a):
>
> Looks good! :)
>
> -----Original Message-----
> From: Daniel Jeli?ski 
> Date: Tuesday, March 16, 2021 at 9:49 AM
> To: "Hohensee, Paul" 
> Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" 
> Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability
>
> Thanks Paul for your review and for the hint.
>
> Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html
>
> compared to original, changes to make/test/BuildMicrobenchmark.gmk
> were dropped because file does not exist in jdk11
> compared to previous webrev, CacheBench was re-added.
>
> Testing: Linux x86_64 tier1 and tier2.
> Thanks,
> Daniel
>
> pon., 15 mar 2021 o 18:09 Hohensee, Paul  napisa?(a):
> >
> > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible.
> >
> > Thanks,
> > Paul
> >
> > -----Original Message-----
> > From: security-dev  on behalf of Daniel Jeli?ski 
> > Date: Tuesday, March 9, 2021 at 3:37 PM
> > To: "jdk-updates-dev at openjdk.java.net" 
> > Cc: "security-dev at openjdk.java.net" 
> > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability
> >
> > Hi,
> > Please review this 11u backport; this is the same patch as for head,
> > except for microbenchmark makefile changes that did not apply because
> > the file doesn't exist in 11u, and the actual microbenchmark, which
> > would only add weight for no benefit.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886
> > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html
> >
> > Testing: Linux x86_64 tier1 and tier2.
> >
> > Thanks,
> > Daniel
> >
>



From jamil.j.nimeh at oracle.com  Fri Mar 19 15:34:46 2021
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 19 Mar 2021 08:34:46 -0700
Subject: [External] : Re: Bug with TLSv1.3 session resumption (most likely
 caused by concurrency bug)
In-Reply-To: 
References: <231bbe52-fa50-0370-c3d9-6aebaa7863aa@oracle.com>
 
Message-ID: <5b5e2813-49e6-30b4-5307-e5d3f350045a@oracle.com>

Hi Norman, I've been working a couple other bugs, but I should have some 
time to devote to it next week.

--Jamil

On 3/19/2021 6:15 AM, Norman Maurer wrote:
> I was wondering if there is any update or anything I can help with ?
>
> Bye
> Norman
>
>> Am 04.03.2021 um 18:51 schrieb Jamil Nimeh :
>>
>> ?
>>
>> I already replied to Norman directly (because apparently I cannot 
>> seem to find my Reply-all button before my morning caffeine!).? It 
>> does look quite a bit like 8241248 and that issue is in my bug 
>> queue.? I haven't started work on it yet, but now that Norman has 
>> provided me some links to a reproducer I can give it a spin and see 
>> if I can make the bug happen locally (Thanks Norman!)
>>
>> --Jamil
>>
>> On 3/4/2021 8:22 AM, Xue-Lei Fan wrote:
>>> Forward to security-dev.
>>>
>>> Xuelei
>>>
>>>> On Mar 4, 2021, at 6:11 AM, Norman Maurer 
>>>> >>> > wrote:
>>>>
>>>> Hi there,
>>>>
>>>> I think I found a bug in the TLSv1.3 session cache implementation 
>>>> which sometimes can cause failures during session resumption.
>>>> The cause of this sometimes show up as NPE:
>>>>
>>>> javax.net.ssl.SSLException: Session has no PSK
>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>>> at 
>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
>>>> at 
>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
>>>> at 
>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
>>>> at 
>>>> java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537)
>>>> at 
>>>> java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528)
>>>> at 
>>>> java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583)
>>>> at 
>>>> java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222)
>>>> at 
>>>> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539)
>>>> at 
>>>> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
>>>> at 
>>>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>>> at 
>>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282)
>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329)
>>>> at 
>>>> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
>>>> at 
>>>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
>>>> at 
>>>> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
>>>> at 
>>>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
>>>> at 
>>>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
>>>> at 
>>>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>>>> at 
>>>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>>>> at 
>>>> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>>>> at 
>>>> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>>>> at 
>>>> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>>>> at java.base/java.lang.Thread.run(Thread.java:834)
>>>> java.lang.NullPointerException
>>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93)
>>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119)
>>>> at 
>>>> java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1169)
>>>> at 
>>>> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:547)
>>>> at 
>>>> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
>>>> at 
>>>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>>> at 
>>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282)
>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329)
>>>> at 
>>>> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
>>>> at 
>>>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
>>>> at 
>>>> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>>> at 
>>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
>>>> at 
>>>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
>>>> at 
>>>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
>>>> at 
>>>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>>>> at 
>>>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>>>> at 
>>>> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>>>> at 
>>>> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>>>> at 
>>>> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>>>> at java.base/java.lang.Thread.run(Thread.java:834)
>>>>
>>>>
>>>> Other times the NPE is not included but it still fails with 
>>>> something like:
>>>>
>>>> Caused by: javax.net.ssl.SSLException: Session has no PSK
>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>>> at 
>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
>>>> at 
>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
>>>> at 
>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
>>>> at 
>>>> java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537)
>>>> at 
>>>> java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528)
>>>> at 
>>>> java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583)
>>>> at 
>>>> java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222)
>>>> at 
>>>> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539)
>>>> at 
>>>> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
>>>> at 
>>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
>>>> at 
>>>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>>> at 
>>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282)
>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329)
>>>> at 
>>>> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
>>>> at 
>>>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
>>>> ... 17 common frames omitted
>>>>
>>>> Looking at the first stacktrace this seems to be related to:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8241248 
>>>> 
>>>>
>>>>
>>>> Unfortunately I don?t have a reproducer which uses the JDK only 
>>>> here but I can reproduce this with Netty that uses OpenSSL on the 
>>>> client side and the JDK SSLEngine on the server side.
>>>> I can reproduce this with the latest JDK11 release but can't with 
>>>> JDK15. Also what makes me believe it may be a concurrency bug is 
>>>> that only some handshakes fail. Like 70 out of 2600 fail.
>>>>
>>>> While the reproducer also involves netty I am wondering if you 
>>>> would still be interested in it ? It should be quite straight 
>>>> forward to run locally for you.
>>>>
>>>> The code that can reproduce it is here:
>>>> https://github.com/netty/netty/pull/10994#issuecomment-787976965 
>>>> 
>>>>
>>>> Also you will need to use this branch:
>>>> https://github.com/netty/netty/tree/ssl_cache_revamp 
>>>> 
>>>>
>>>>
>>>> Please don?t hesitate if you have questions,
>>>> Norman
>>>>
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mullan at openjdk.java.net  Fri Mar 19 16:38:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 19 Mar 2021 16:38:38 GMT
Subject: RFR: 8263825: Remove unused and commented out member from
 NTLMException
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Mar 2021 16:57:59 GMT, Alex Blewitt  wrote:

> Removed commented out value from `NTLMException`

Seems fine to me. You should assign yourself to https://bugs.openjdk.java.net/browse/JDK-8263825.

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

Marked as reviewed by mullan (Reviewer).

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

From redestad at openjdk.java.net  Fri Mar 19 16:46:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 16:46:38 GMT
Subject: RFR: 8263825: Remove unused and commented out member from
 NTLMException
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Mar 2021 16:57:59 GMT, Alex Blewitt  wrote:

> Removed commented out value from `NTLMException`

Marked as reviewed by redestad (Reviewer).

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

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

From redestad at openjdk.java.net  Fri Mar 19 16:46:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 16:46:40 GMT
Subject: RFR: 8263825: Remove unused and commented out member from
 NTLMException
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Mar 2021 16:36:05 GMT, Sean Mullan  wrote:

>> Removed commented out value from `NTLMException`
>
> Seems fine to me. You should assign yourself to https://bugs.openjdk.java.net/browse/JDK-8263825.

I don't think Alex has a JBS user yet, so I'll assign the bugs I file on his behalf to me to get it off any dashboards.

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 17:13:58 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 17:13:58 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: 
References: 
Message-ID: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:

  Added more replacements of 'final public' with 'public final'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3078/files
  - new: https://git.openjdk.java.net/jdk/pull/3078/files/f1bc7269..1c900d2d

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

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

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

From redestad at openjdk.java.net  Fri Mar 19 18:02:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:02:41 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: 
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: 

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt  wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

Marked as reviewed by redestad (Reviewer).

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

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

From valeriep at openjdk.java.net  Fri Mar 19 18:24:38 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 19 Mar 2021 18:24:38 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 19 Mar 2021 03:18:35 GMT, SalusaSecondus  wrote:

>> src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 430:
>> 
>>> 428:             } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
>>> 429:                 throw new InvalidKeySpecException
>>> 430:                         ("RSAPrivateCrtKeySpec can only be used with CRT keys");
>> 
>> If we are basing the decision on type of key, it may be clearer to do something like below:
>>         } else if (key instanceof RSAPrivateKey) {
>>             if (keySpec.isAssignableFrom(PKCS8_KEYSPEC_CLS)) {
>>                 return keySpec.cast(new PKCS8EncodedKeySpec(key.getEncoded()));
>>             } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
>>                 if (key instanceof RSAPrivateCrtKey) {
>>                     RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey)key;
>>                     return keySpec.cast(new RSAPrivateCrtKeySpec(
>>                         crtKey.getModulus(),
>>                         crtKey.getPublicExponent(),
>>                         crtKey.getPrivateExponent(),
>>                         crtKey.getPrimeP(),
>>                         crtKey.getPrimeQ(),
>>                         crtKey.getPrimeExponentP(),
>>                         crtKey.getPrimeExponentQ(),
>>                         crtKey.getCrtCoefficient(),
>>                         crtKey.getParams()
>>                     ));
>>                 } else { // RSAPrivateKey (non-CRT)
>>                     if (!keySpec.isAssignableFrom(RSA_PRIV_KEYSPEC_CLS)) {
>>                         throw new InvalidKeySpecException
>>                             ("RSAPrivateCrtKeySpec can only be used with CRT keys");
>>                     }
>> 
>>                     // fall through to RSAPrivateKey (non-CRT)
>>                     RSAPrivateKey rsaKey = (RSAPrivateKey) key;
>>                     return keySpec.cast(new RSAPrivateKeySpec(
>>                         rsaKey.getModulus(),
>>                         rsaKey.getPrivateExponent(),
>>                         rsaKey.getParams()
>>                     ));
>>                 }
>>             } else {
>>                 throw new InvalidKeySpecException
>>                         ("KeySpec must be RSAPrivate(Crt)KeySpec or "
>>                         + "PKCS8EncodedKeySpec for RSA private keys");
>>             }
>
> I like this flow and think that it's clearer.
> 
> One question: Do you think we could use this code almost character for character in the `P11RSAKeyFactory`? The keys handled should be descendants of `RSAPrivateCrtKey`, `RSAPrivateKey`, or `P11PrivateKey` (which would need some special handling). I didn't want to refactor it that much even though I think that it would work because I assume it must have been written to use the underlying PKCS#11 properties for *some* reason (even if I cannot figure out why).

Well, for `P11RSAKeyFactory`, I think some minor modification may be needed given the additional P11PrivateKey type.
I'd expect it to be something like:
        // must be either RSAPrivateKeySpec or RSAPrivateCrtKeySpec
        if (keySpec.isAssignableFrom(RSAPrivateCrtKeySpec.class)) {
            session[0] = token.getObjSession();
            CK_ATTRIBUTE[] attributes = new CK_ATTRIBUTE[] {
                new CK_ATTRIBUTE(CKA_MODULUS),
                new CK_ATTRIBUTE(CKA_PUBLIC_EXPONENT),
                new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT),
                new CK_ATTRIBUTE(CKA_PRIME_1),
                new CK_ATTRIBUTE(CKA_PRIME_2),
                new CK_ATTRIBUTE(CKA_EXPONENT_1),
                new CK_ATTRIBUTE(CKA_EXPONENT_2),
                new CK_ATTRIBUTE(CKA_COEFFICIENT),
            };
            long keyID = key.getKeyID();
            try {
                token.p11.C_GetAttributeValue(session[0].id(), keyID, attributes);
                KeySpec spec = new RSAPrivateCrtKeySpec(
                    attributes[0].getBigInteger(),
                    attributes[1].getBigInteger(),
                    attributes[2].getBigInteger(),
                    attributes[3].getBigInteger(),
                    attributes[4].getBigInteger(),
                    attributes[5].getBigInteger(),
                    attributes[6].getBigInteger(),
                    attributes[7].getBigInteger()
                );
                return keySpec.cast(spec);
            } catch (final PKCS11Exception ex) {
                // bubble this up if RSAPrivateCrtKeySpec is specified
                // otherwise fall through to RSAPrivateKeySpec
                if (!keySpec.isAssignableFrom(RSAPrivateKeySpec.class)) {
                    throw ex;
                }
            }  finally {
                key.releaseKeyID();
            }

            attributes = new CK_ATTRIBUTE[] {
                new CK_ATTRIBUTE(CKA_MODULUS),
                new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT),
            };
            keyID = key.getKeyID();
            try {
                token.p11.C_GetAttributeValue(session[0].id(), keyID, attributes);
            } finally {
                key.releaseKeyID();
            }

            KeySpec spec = new RSAPrivateKeySpec(
                attributes[0].getBigInteger(),
                attributes[1].getBigInteger()
            );
            return keySpec.cast(spec);
        } else { // PKCS#8 handled in superclass
            throw new InvalidKeySpecException("Only RSAPrivate(Crt)KeySpec "
                + "and PKCS8EncodedKeySpec supported for RSA private keys");
        }
    }

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 18:28:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 18:28:46 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
Message-ID: 

Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

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

Commit messages:
 - 8263658: Use the blessed modifier order in java.base

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

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

From naoto at openjdk.java.net  Fri Mar 19 18:33:38 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 18:33:38 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt  wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by naoto (Reviewer).

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

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

From redestad at openjdk.java.net  Fri Mar 19 18:36:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:36:40 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Mar 2021 18:31:02 GMT, Naoto Sato  wrote:

>> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.
>
> Marked as reviewed by naoto (Reviewer).

Can't reuse the bug IDs, sadly. Filed https://bugs.openjdk.java.net/browse/JDK-8263892 (note the new summary name to disambiguate)

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

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

From mstjohns at comcast.net  Fri Mar 19 19:06:28 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Fri, 19 Mar 2021 15:06:28 -0400
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <9d0f4d84-d4af-d780-67ad-fe66dee651a5@comcast.net>

On 3/19/2021 2:24 PM, Valerie Peng wrote:
>
> some* reason (even if I cannot figure out why).
> Well, for `P11RSAKeyFactory`, I think some minor modification may be needed given the additional P11PrivateKey type.
> I'd expect it to be something like:
>          // must be either RSAPrivateKeySpec or RSAPrivateCrtKeySpec
>          if (keySpec.isAssignableFrom(RSAPrivateCrtKeySpec.class)) {
>              session[0] = token.getObjSession();
>              CK_ATTRIBUTE[] attributes = new CK_ATTRIBUTE[] {
>                  new CK_ATTRIBUTE(CKA_MODULUS),
>                  new CK_ATTRIBUTE(CKA_PUBLIC_EXPONENT),
>                  new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT),

If the PKCS11 private key has the CKA_SENSITIVE attribute set to true or 
CKA_EXPORTABLE set to false, you can't retrieve the above attribute.? 
AIRC, the contract for getting a Key from an unextractable PKCS11 
private key is to return a key that implements both PrivateKey and 
RSAKey, but doesn't implement either of the RSAPrivateKey interfaces.?? 
I don't know what the contract is for producing KeySpec's from 
unextractable keys.

Mike


>                  new CK_ATTRIBUTE(CKA_PRIME_1),
>                  new CK_ATTRIBUTE(CKA_PRIME_2),
>                  new CK_ATTRIBUTE(CKA_EXPONENT_1),
>                  new CK_ATTRIBUTE(CKA_EXPONENT_2),
>                  new CK_ATTRIBUTE(CKA_COEFFICIENT),
>              };
>              long keyID = key.getKeyID();
>              try {
>                  token.p11.C_GetAttributeValue(session[0].id(), keyID, attributes);
>                  KeySpec spec = new RSAPrivateCrtKeySpec(
>                      attributes[0].getBigInteger(),
>                      attributes[1].getBigInteger(),
>                      attributes[2].getBigInteger(),
>                      attributes[3].getBigInteger(),
>                      attributes[4].getBigInteger(),
>                      attributes[5].getBigInteger(),
>                      attributes[6].getBigInteger(),
>                      attributes[7].getBigInteger()
>                  );
>                  return keySpec.cast(spec);
>              } catch (final PKCS11Exception ex) {
>                  // bubble this up if RSAPrivateCrtKeySpec is specified
>                  // otherwise fall through to RSAPrivateKeySpec
>                  if (!keySpec.isAssignableFrom(RSAPrivateKeySpec.class)) {
>                      throw ex;
>                  }
>              }  finally {
>                  key.releaseKeyID();
>              }
>
>              attributes = new CK_ATTRIBUTE[] {
>                  new CK_ATTRIBUTE(CKA_MODULUS),
>                  new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT),
>              };
>              keyID = key.getKeyID();
>              try {
>                  token.p11.C_GetAttributeValue(session[0].id(), keyID, attributes);
>              } finally {
>                  key.releaseKeyID();
>              }
>
>              KeySpec spec = new RSAPrivateKeySpec(
>                  attributes[0].getBigInteger(),
>                  attributes[1].getBigInteger()
>              );
>              return keySpec.cast(spec);
>          } else { // PKCS#8 handled in superclass
>              throw new InvalidKeySpecException("Only RSAPrivate(Crt)KeySpec "
>                  + "and PKCS8EncodedKeySpec supported for RSA private keys");
>          }
>      }
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2949



From github.com+829871+salusasecondus at openjdk.java.net  Fri Mar 19 19:44:41 2021
From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus)
Date: Fri, 19 Mar 2021 19:44:41 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 19 Mar 2021 18:21:12 GMT, Valerie Peng  wrote:

>> I like this flow and think that it's clearer.
>> 
>> One question: Do you think we could use this code almost character for character in the `P11RSAKeyFactory`? The keys handled should be descendants of `RSAPrivateCrtKey`, `RSAPrivateKey`, or `P11PrivateKey` (which would need some special handling). I didn't want to refactor it that much even though I think that it would work because I assume it must have been written to use the underlying PKCS#11 properties for *some* reason (even if I cannot figure out why).
>
> Well, for `P11RSAKeyFactory`, I think some minor modification may be needed given the additional P11PrivateKey type.
> I'd expect it to be something like:
>         // must be either RSAPrivateKeySpec or RSAPrivateCrtKeySpec
>         if (keySpec.isAssignableFrom(RSAPrivateCrtKeySpec.class)) {
>             session[0] = token.getObjSession();
>             CK_ATTRIBUTE[] attributes = new CK_ATTRIBUTE[] {
>                 new CK_ATTRIBUTE(CKA_MODULUS),
>                 new CK_ATTRIBUTE(CKA_PUBLIC_EXPONENT),
>                 new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT),
>                 new CK_ATTRIBUTE(CKA_PRIME_1),
>                 new CK_ATTRIBUTE(CKA_PRIME_2),
>                 new CK_ATTRIBUTE(CKA_EXPONENT_1),
>                 new CK_ATTRIBUTE(CKA_EXPONENT_2),
>                 new CK_ATTRIBUTE(CKA_COEFFICIENT),
>             };
>             long keyID = key.getKeyID();
>             try {
>                 token.p11.C_GetAttributeValue(session[0].id(), keyID, attributes);
>                 KeySpec spec = new RSAPrivateCrtKeySpec(
>                     attributes[0].getBigInteger(),
>                     attributes[1].getBigInteger(),
>                     attributes[2].getBigInteger(),
>                     attributes[3].getBigInteger(),
>                     attributes[4].getBigInteger(),
>                     attributes[5].getBigInteger(),
>                     attributes[6].getBigInteger(),
>                     attributes[7].getBigInteger()
>                 );
>                 return keySpec.cast(spec);
>             } catch (final PKCS11Exception ex) {
>                 // bubble this up if RSAPrivateCrtKeySpec is specified
>                 // otherwise fall through to RSAPrivateKeySpec
>                 if (!keySpec.isAssignableFrom(RSAPrivateKeySpec.class)) {
>                     throw ex;
>                 }
>             }  finally {
>                 key.releaseKeyID();
>             }
> 
>             attributes = new CK_ATTRIBUTE[] {
>                 new CK_ATTRIBUTE(CKA_MODULUS),
>                 new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT),
>             };
>             keyID = key.getKeyID();
>             try {
>                 token.p11.C_GetAttributeValue(session[0].id(), keyID, attributes);
>             } finally {
>                 key.releaseKeyID();
>             }
> 
>             KeySpec spec = new RSAPrivateKeySpec(
>                 attributes[0].getBigInteger(),
>                 attributes[1].getBigInteger()
>             );
>             return keySpec.cast(spec);
>         } else { // PKCS#8 handled in superclass
>             throw new InvalidKeySpecException("Only RSAPrivate(Crt)KeySpec "
>                 + "and PKCS8EncodedKeySpec supported for RSA private keys");
>         }
>     }

I think that this code will work, but since there already is [P11RSAPrivateKey and P11RSAPrivateNonCRTKey](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406) (both of which implement the standard `RSAPrivateKey` and `RSAPrivateCrtKey` interfaces respectively), can we just depend on and simplify our code? (My concern is that there is some unknown reason for calling `C_GetAttributeValue` directly here.)

For example (based on the non-P11 code above)
        } else if (key instanceof RSAPrivateKey) {
            if (keySpec.isAssignableFrom(PKCS8_KEYSPEC_CLS)) {
                return keySpec.cast(new PKCS8EncodedKeySpec(key.getEncoded()));
            } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
                if (key instanceof RSAPrivateCrtKey) {
                    RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey)key;
                    return keySpec.cast(new RSAPrivateCrtKeySpec(
                        crtKey.getModulus(),
                        crtKey.getPublicExponent(),
                        crtKey.getPrivateExponent(),
                        crtKey.getPrimeP(),
                        crtKey.getPrimeQ(),
                        crtKey.getPrimeExponentP(),
                        crtKey.getPrimeExponentQ(),
                        crtKey.getCrtCoefficient(),
                        crtKey.getParams()
                    ));
                } else { // RSAPrivateKey (non-CRT)
                    if (!keySpec.isAssignableFrom(RSA_PRIV_KEYSPEC_CLS)) {
                        throw new InvalidKeySpecException
                            ("RSAPrivateCrtKeySpec can only be used with CRT keys");
                    }

                    // fall through to RSAPrivateKey (non-CRT)
                    RSAPrivateKey rsaKey = (RSAPrivateKey) key;
                    return keySpec.cast(new RSAPrivateKeySpec(
                        rsaKey.getModulus(),
                        rsaKey.getPrivateExponent(),
                        rsaKey.getParams()
                    ));
                } else { // New P11 code starts here and handles the P11PrivateKey case
                    throw new InvalidKeySpecException("RSA Private key is not extractable");
                } // End new P11 code
            } else {
                throw new InvalidKeySpecException
                        ("KeySpec must be RSAPrivate(Crt)KeySpec or "
                        + "PKCS8EncodedKeySpec for RSA private keys");
            }

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

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

From iris at openjdk.java.net  Fri Mar 19 20:04:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 19 Mar 2021 20:04:39 GMT
Subject: RFR: 8263892: More modifier order fixes in java.base
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt  wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by iris (Reviewer).

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

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

From weijun at openjdk.java.net  Fri Mar 19 20:11:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 19 Mar 2021 20:11:13 GMT
Subject: RFR: 8255255: Update Apache Santuario (XML Signature) to version
 2.2.1 [v9]
In-Reply-To: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com>
References: <9HSWW2iZvPdRsRM2V485qP8EEVfrr-HliiCLcBmo39M=.59e3740a-3c7e-4081-bbea-45ef41e102cd@github.com>
Message-ID: 

> This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario 2.2.0.
> 
> The first step is an auto-import. The JDK implementation is removed first and Santuario code are imported. Some unrelated files (Ex: encryption) are removed, and package names are renamed to be internal. There are also some bulk changes on company name, comment style, and white spaces.
> 
> Next steps are patches applied by JDK. Some are old patches before the last import. Some are new.
> 
> Several tests need to be updated because of internal method signature changes.

Weijun Wang 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 16 additional commits since the last revision:

 - Merge branch 'master' into 8255255
 - Merge branch 'master' into 8255255
 - reapply 8259535: ECDSA SignatureValue do not always have the specified length
 - No more newInstance calls
 - Reapply 8255559: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI()
 - Fix test failures
 - Supporting named RSASSA-PSS without parameters
 - Reapply 8008744: Rework part of fix for JDK-6741606
 - Reapply 8151893: Add security property to configure XML Signature secure validation mode
   
   Reapply 8140353: Improve signature checking
 - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/d7f9fd9d...006f01c5

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1206/files
  - new: https://git.openjdk.java.net/jdk/pull/1206/files/60496847..006f01c5

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

  Stats: 32247 lines in 1485 files changed: 25411 ins; 3366 del; 3470 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1206.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1206/head:pull/1206

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

From ascarpino at openjdk.java.net  Fri Mar 19 20:34:41 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 19 Mar 2021 20:34:41 GMT
Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey
 impl and revised exception handling [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 18 Mar 2021 17:06:21 GMT, Jamil Nimeh  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simpler fix for ECPrivateKey
>
> src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 211:
> 
>> 209:         try {
>> 210:             result = deriveKeyImpl(privateKey, privateKeyOps, publicKey);
>> 211:         } catch (Exception e) {
> 
> Why such a broad exception catch here?  It looks like deriveKeyImpl is only explicitly throwing IKE.  Are there other unchecked exceptions that you're trying to snag here that I'm missing in the deriveKeyImpl below?

Just being cautious and wrapping anything.  Maybe there will be some exceptions in the math methods that throw could exceptions.

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 21:09:41 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 21:09:41 GMT
Subject: Integrated: 8263825: Remove unused and commented out member from
 NTLMException
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Mar 2021 16:57:59 GMT, Alex Blewitt  wrote:

> Removed commented out value from `NTLMException`

This pull request has now been integrated.

Changeset: 6fa6557d
Author:    Alex Blewitt 
Committer: Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/6fa6557d
Stats:     6 lines in 1 file changed: 0 ins; 6 del; 0 mod

8263825: Remove unused and commented out member from NTLMException

Reviewed-by: mullan, redestad

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 21:09:42 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 21:09:42 GMT
Subject: Integrated: 8263892: More modifier order fixes in java.base
In-Reply-To: 
References: 
Message-ID: <3DMY9iQ9ES67nDcNnpKUWpfQ_3HwoQ-7LSkJ-hZCNtA=.027dd909-930c-4b61-bee3-62345ac73c25@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt  wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

This pull request has now been integrated.

Changeset: 77ebc110
Author:    Alex Blewitt 
Committer: Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/77ebc110
Stats:     19 lines in 5 files changed: 0 ins; 0 del; 19 mod

8263892: More modifier order fixes in java.base

Reviewed-by: naoto, iris, redestad

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

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

From redestad at openjdk.java.net  Fri Mar 19 21:09:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 21:09:41 GMT
Subject: RFR: 8263892: More modifier order fixes in java.base
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt  wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by redestad (Reviewer).

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

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

From jnimeh at openjdk.java.net  Fri Mar 19 21:17:43 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Fri, 19 Mar 2021 21:17:43 GMT
Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey
 impl and revised exception handling [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 23 Feb 2021 20:40:05 GMT, Anthony Scarpino  wrote:

>> Hi,
>> 
>> I need a code review of this change to ECDH.  It is a combination of fixing the implementation to not only accept ECPrivateKeyImpl along with a fix to the exception handling.  They started as two fixes, but with the exception handling the underlying code changed significantly that made the ECPrivateKey change in a different place.  The new exception handling is a result of no longer having the native library.  Many of the checks waited until generateSecret() to send the keys to the native library. Now that native is gone, checks can happen when keys are provided to the methods and proper exceptions can be thrown instead of wrapping everything as a ProviderException
>> 
>> thanks,
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simpler fix for ECPrivateKey

Marked as reviewed by jnimeh (Reviewer).

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

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

From jnimeh at openjdk.java.net  Fri Mar 19 21:17:43 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Fri, 19 Mar 2021 21:17:43 GMT
Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey
 impl and revised exception handling [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 19 Mar 2021 20:29:48 GMT, Anthony Scarpino  wrote:

>> src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 211:
>> 
>>> 209:         try {
>>> 210:             result = deriveKeyImpl(privateKey, privateKeyOps, publicKey);
>>> 211:         } catch (Exception e) {
>> 
>> Why such a broad exception catch here?  It looks like deriveKeyImpl is only explicitly throwing IKE.  Are there other unchecked exceptions that you're trying to snag here that I'm missing in the deriveKeyImpl below?
>
> Just being cautious and wrapping anything.  Maybe there will be some exceptions in the math methods that throw could exceptions.

Fair enough.  I'm OK to leave this as-is.

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

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

From djelinski1 at gmail.com  Fri Mar 19 21:26:50 2021
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Fri, 19 Mar 2021 22:26:50 +0100
Subject: [11u] RFR 8259886: Improve SSL session cache performance and
 scalability
In-Reply-To: 
References: 
 
Message-ID: 

Great, thanks!
I tried to follow the instructions here:
https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
The hg export recipe was not available, so I substituted git format-patch.
I wasn't aware of git hg-export. I think it should be mentioned on that
wiki.
Thanks again,
Daniel

pt., 19 mar 2021, 16:21 u?ytkownik Hohensee, Paul 
napisa?:

> Pushed. In the future, it'd be great if you used "git hg-export" (one of
> the Skara tools) to generate the base changeset, because it includes the
> commit metadata we want to preserve in the 11u hg repo.
>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: security-dev  on behalf of
> "Hohensee, Paul" 
> Date: Wednesday, March 17, 2021 at 1:01 PM
> To: Daniel Jeli?ski 
> Cc: "jdk-updates-dev at openjdk.java.net" ,
> "security-dev at openjdk.java.net" 
> Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and
> scalability
>
> Np, tagged.
>
> -----Original Message-----
> From: Daniel Jeli?ski 
> Date: Tuesday, March 16, 2021 at 11:40 PM
> To: "Hohensee, Paul" 
> Cc: "jdk-updates-dev at openjdk.java.net" ,
> "security-dev at openjdk.java.net" 
> Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and
> scalability
>
> Thanks again Paul.
>
> Could you sponsor the change? As far as I can tell, I'd need to add a
> fix request now, but I don't have access to issue tracker.
> Thanks,
> Daniel
>
> wt., 16 mar 2021 o 18:59 Hohensee, Paul  napisa?(a):
> >
> > Looks good! :)
> >
> > -----Original Message-----
> > From: Daniel Jeli?ski 
> > Date: Tuesday, March 16, 2021 at 9:49 AM
> > To: "Hohensee, Paul" 
> > Cc: "jdk-updates-dev at openjdk.java.net" ,
> "security-dev at openjdk.java.net" 
> > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance
> and scalability
> >
> > Thanks Paul for your review and for the hint.
> >
> > Updated webrev:
> https://djelinski.github.io/8259886-11u/webrev2/index.html
> >
> > compared to original, changes to make/test/BuildMicrobenchmark.gmk
> > were dropped because file does not exist in jdk11
> > compared to previous webrev, CacheBench was re-added.
> >
> > Testing: Linux x86_64 tier1 and tier2.
> > Thanks,
> > Daniel
> >
> > pon., 15 mar 2021 o 18:09 Hohensee, Paul 
> napisa?(a):
> > >
> > > The changes to Cache.java look fine, but please include
> CacheBench.java. I'd like to see 11u to stand on its own without reference
> to later releases, plus I believe the 11u maintainers prefer to backport as
> much of a patch as possible.
> > >
> > > Thanks,
> > > Paul
> > >
> > > -----Original Message-----
> > > From: security-dev  on behalf of
> Daniel Jeli?ski 
> > > Date: Tuesday, March 9, 2021 at 3:37 PM
> > > To: "jdk-updates-dev at openjdk.java.net" <
> jdk-updates-dev at openjdk.java.net>
> > > Cc: "security-dev at openjdk.java.net" 
> > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and
> scalability
> > >
> > > Hi,
> > > Please review this 11u backport; this is the same patch as for head,
> > > except for microbenchmark makefile changes that did not apply because
> > > the file doesn't exist in 11u, and the actual microbenchmark, which
> > > would only add weight for no benefit.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886
> > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html
> > >
> > > Testing: Linux x86_64 tier1 and tier2.
> > >
> > > Thanks,
> > > Daniel
> > >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ascarpino at openjdk.java.net  Fri Mar 19 21:53:54 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 19 Mar 2021 21:53:54 GMT
Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey
 impl and revised exception handling [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I need a code review of this change to ECDH.  It is a combination of fixing the implementation to not only accept ECPrivateKeyImpl along with a fix to the exception handling.  They started as two fixes, but with the exception handling the underlying code changed significantly that made the ECPrivateKey change in a different place.  The new exception handling is a result of no longer having the native library.  Many of the checks waited until generateSecret() to send the keys to the native library. Now that native is gone, checks can happen when keys are provided to the methods and proper exceptions can be thrown instead of wrapping everything as a ProviderException
> 
> thanks,
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  update test bug id

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2659/files
  - new: https://git.openjdk.java.net/jdk/pull/2659/files/aec24cc1..3342e3b2

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

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

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

From luoziyi at openjdk.java.net  Sat Mar 20 17:44:54 2021
From: luoziyi at openjdk.java.net (Ziyi Luo)
Date: Sat, 20 Mar 2021 17:44:54 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v5]
In-Reply-To: 
References: 
Message-ID: <27hpeRtTjW31H5HYtb42usucaa-XtZLekEQLLxseVjU=.1f27499a-a753-4a16-a85e-c1d22cc10397@github.com>

> This is a P2 regression introduced by JDK-8254717.
> 
> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
> 
> X-axis: type of `keySpec`
> Y-axis: type of `key`
> 
> Before JDK-8254717:
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
> 
> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
> 
> This commit fixes the regression.
> 
> 
> ### Tests
> 
> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed

Ziyi Luo has updated the pull request incrementally with one additional commit since the last revision:

  Address Valerie's feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2949/files
  - new: https://git.openjdk.java.net/jdk/pull/2949/files/defbf46b..da25a691

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

  Stats: 89 lines in 2 files changed: 34 ins; 35 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2949.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2949/head:pull/2949

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

From github.com+829871+salusasecondus at openjdk.java.net  Sat Mar 20 17:44:54 2021
From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus)
Date: Sat, 20 Mar 2021 17:44:54 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <0YOaHUY4C0h2H-I7G-Kc-R6rpZCE7CM0G2lWxlRTWpM=.232b2cd5-9697-4584-9f99-8feeb42840ef@github.com>

On Fri, 19 Mar 2021 19:42:10 GMT, SalusaSecondus  wrote:

>> Well, for `P11RSAKeyFactory`, I think some minor modification may be needed given the additional P11PrivateKey type.
>> I'd expect it to be something like:
>>         // must be either RSAPrivateKeySpec or RSAPrivateCrtKeySpec
>>         if (keySpec.isAssignableFrom(RSAPrivateCrtKeySpec.class)) {
>>             session[0] = token.getObjSession();
>>             CK_ATTRIBUTE[] attributes = new CK_ATTRIBUTE[] {
>>                 new CK_ATTRIBUTE(CKA_MODULUS),
>>                 new CK_ATTRIBUTE(CKA_PUBLIC_EXPONENT),
>>                 new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT),
>>                 new CK_ATTRIBUTE(CKA_PRIME_1),
>>                 new CK_ATTRIBUTE(CKA_PRIME_2),
>>                 new CK_ATTRIBUTE(CKA_EXPONENT_1),
>>                 new CK_ATTRIBUTE(CKA_EXPONENT_2),
>>                 new CK_ATTRIBUTE(CKA_COEFFICIENT),
>>             };
>>             long keyID = key.getKeyID();
>>             try {
>>                 token.p11.C_GetAttributeValue(session[0].id(), keyID, attributes);
>>                 KeySpec spec = new RSAPrivateCrtKeySpec(
>>                     attributes[0].getBigInteger(),
>>                     attributes[1].getBigInteger(),
>>                     attributes[2].getBigInteger(),
>>                     attributes[3].getBigInteger(),
>>                     attributes[4].getBigInteger(),
>>                     attributes[5].getBigInteger(),
>>                     attributes[6].getBigInteger(),
>>                     attributes[7].getBigInteger()
>>                 );
>>                 return keySpec.cast(spec);
>>             } catch (final PKCS11Exception ex) {
>>                 // bubble this up if RSAPrivateCrtKeySpec is specified
>>                 // otherwise fall through to RSAPrivateKeySpec
>>                 if (!keySpec.isAssignableFrom(RSAPrivateKeySpec.class)) {
>>                     throw ex;
>>                 }
>>             }  finally {
>>                 key.releaseKeyID();
>>             }
>> 
>>             attributes = new CK_ATTRIBUTE[] {
>>                 new CK_ATTRIBUTE(CKA_MODULUS),
>>                 new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT),
>>             };
>>             keyID = key.getKeyID();
>>             try {
>>                 token.p11.C_GetAttributeValue(session[0].id(), keyID, attributes);
>>             } finally {
>>                 key.releaseKeyID();
>>             }
>> 
>>             KeySpec spec = new RSAPrivateKeySpec(
>>                 attributes[0].getBigInteger(),
>>                 attributes[1].getBigInteger()
>>             );
>>             return keySpec.cast(spec);
>>         } else { // PKCS#8 handled in superclass
>>             throw new InvalidKeySpecException("Only RSAPrivate(Crt)KeySpec "
>>                 + "and PKCS8EncodedKeySpec supported for RSA private keys");
>>         }
>>     }
>
> I think that this code will work, but since there already is [P11RSAPrivateKey and P11RSAPrivateNonCRTKey](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406) (both of which implement the standard `RSAPrivateKey` and `RSAPrivateCrtKey` interfaces respectively), can we just depend on and simplify our code? (My concern is that there is some unknown reason for calling `C_GetAttributeValue` directly here.)
> 
> For example (based on the non-P11 code above)
>         } else if (key instanceof RSAPrivateKey) {
>             if (keySpec.isAssignableFrom(PKCS8_KEYSPEC_CLS)) {
>                 return keySpec.cast(new PKCS8EncodedKeySpec(key.getEncoded()));
>             } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
>                 if (key instanceof RSAPrivateCrtKey) {
>                     RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey)key;
>                     return keySpec.cast(new RSAPrivateCrtKeySpec(
>                         crtKey.getModulus(),
>                         crtKey.getPublicExponent(),
>                         crtKey.getPrivateExponent(),
>                         crtKey.getPrimeP(),
>                         crtKey.getPrimeQ(),
>                         crtKey.getPrimeExponentP(),
>                         crtKey.getPrimeExponentQ(),
>                         crtKey.getCrtCoefficient(),
>                         crtKey.getParams()
>                     ));
>                 } else if (key instanceof RSAPrivateKey) {
>                     if (!keySpec.isAssignableFrom(RSA_PRIV_KEYSPEC_CLS)) {
>                         throw new InvalidKeySpecException
>                             ("RSAPrivateCrtKeySpec can only be used with CRT keys");
>                     }
> 
>                     // fall through to RSAPrivateKey (non-CRT)
>                     RSAPrivateKey rsaKey = (RSAPrivateKey) key;
>                     return keySpec.cast(new RSAPrivateKeySpec(
>                         rsaKey.getModulus(),
>                         rsaKey.getPrivateExponent(),
>                         rsaKey.getParams()
>                     ));
>                 } else { // New P11 code starts here and handles the P11PrivateKey case
>                     throw new InvalidKeySpecException("RSA Private key is not extractable");
>                 } // End new P11 code
>             } else {
>                 throw new InvalidKeySpecException
>                         ("KeySpec must be RSAPrivate(Crt)KeySpec or "
>                         + "PKCS8EncodedKeySpec for RSA private keys");
>             }

I've used your code for both because it looks like a good solution.

One thing which puzzles me is that the following implementation for the P11 code passes all tests and avoids any interaction with P11 library at all. I didn't want to use it because I'm concerned that there is an untested edge-case we'd bump into.

     T implGetPrivateKeySpec(P11Key key, Class keySpec,
            Session[] session) throws PKCS11Exception, InvalidKeySpecException {
        if (key instanceof RSAPrivateKey) {
            try {
                return implGetSoftwareFactory().getKeySpec(key, keySpec);
            } catch (final InvalidKeySpecException  e) {
                throw e;
            } catch (final GeneralSecurityException e) {
                throw new InvalidKeySpecException("Could not generate KeySpec", e);
            }
        } else {
            throw new InvalidKeySpecException("Key is not extractable");
        }
    }

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

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

From github.com+829871+salusasecondus at openjdk.java.net  Sat Mar 20 17:54:39 2021
From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus)
Date: Sat, 20 Mar 2021 17:54:39 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 18 Mar 2021 20:25:59 GMT, Ziyi Luo  wrote:

>> This looks to cover the cases and fixes we talked about.
>
> @valeriepeng Sorry for the delay. There were unknown Windows build failure during the pre-submit tests that I have to rebase my commits on top of the  master tip. This new revision should cover all comments you left before. Thank you!

Mike,

>From what I can find, if you try to get a spec from a non-extractable key you'll get an `InvalidKeySpecException`.
1. `C_GetAttributeValue`will throw a `PKCS11Exception`
2. The `PKCS11Exception` gets caught in [P11KeyFactory](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyFactory.java#L98-L99) which rethrows it as an `InvalidKeySpecException`.

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

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

From mstjohns at comcast.net  Sat Mar 20 18:11:01 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Sat, 20 Mar 2021 14:11:01 -0400
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <386f5c2c-85c1-acd8-3608-aef8f746d96e@comcast.net>

On 3/20/2021 1:54 PM, SalusaSecondus wrote:
> On Thu, 18 Mar 2021 20:25:59 GMT, Ziyi Luo  wrote:
>
>>> This looks to cover the cases and fixes we talked about.
>> @valeriepeng Sorry for the delay. There were unknown Windows build failure during the pre-submit tests that I have to rebase my commits on top of the  master tip. This new revision should cover all comments you left before. Thank you!
> Mike,
>
>  From what I can find, if you try to get a spec from a non-extractable key you'll get an `InvalidKeySpecException`.
> 1. `C_GetAttributeValue`will throw a `PKCS11Exception`
> 2. The `PKCS11Exception` gets caught in [P11KeyFactory](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyFactory.java#L98-L99) which rethrows it as an `InvalidKeySpecException`.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2949

Given that, I'd refactor the code to pull the CKA_SENSITIVE and 
CKA_EXPORTABLE attributes first and throw a more specific message if the 
key is not extractable rather than having to fail twice before throwing 
the error.? (I.e., you try both combos of the attributes and both are 
failing on the inability to pull the private exponent).

Either that or fail early by checking the error code of the first thrown 
PKCS11Exception against CKR_ATTRIBUTE_SENSITIVE.

>       } catch (final PKCS11Exception ex) {
if (ex.getErrorCode() == PKCS11Constants.CKR_ATTRIBUTE_SENSITIVE) {
 ???? throw new InvalidKeySpecException ("Sensitive key may not be 
extracted", ex);
}
>                  // bubble this up if RSAPrivateCrtKeySpec is specified
>                  // otherwise fall through to RSAPrivateKeySpec
>                  if (!keySpec.isAssignableFrom(RSAPrivateKeySpec.class)) {
>                      throw ex;
>                  }
>              }  finally {
>                  key.releaseKeyID();
>              }

Later, Mike


From github.com+829871+salusasecondus at openjdk.java.net  Sat Mar 20 18:46:40 2021
From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus)
Date: Sat, 20 Mar 2021 18:46:40 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Sat, 20 Mar 2021 17:52:00 GMT, SalusaSecondus  wrote:

>> @valeriepeng Sorry for the delay. There were unknown Windows build failure during the pre-submit tests that I have to rebase my commits on top of the  master tip. This new revision should cover all comments you left before. Thank you!
>
> Mike,
> 
> From what I can find, if you try to get a spec from a non-extractable key you'll get an `InvalidKeySpecException`.
> 1. `C_GetAttributeValue`will throw a `PKCS11Exception`
> 2. The `PKCS11Exception` gets caught in [P11KeyFactory](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyFactory.java#L98-L99) which rethrows it as an `InvalidKeySpecException`.

We seem to have a choice and I'm not sure the best way to approach this.

1. We trust the properties in `P11Key` and just ask it if the values are both sensitive and extractable. [1]
2. But if we already trust P11Key, why not also trust that it properly implements the RSAPrivateKey interfaces [2]. This is the strategy used by the snippet I posted earlier (delegating to `implGetSoftwareFactory()`)
3. We don't trust P11Key except to use getKeyId(), this yields the current design where we pull the attributes every time the factory needs them.

We should probably reduce calls to `C_GetAttributeValue` as they may be very slow. At the least they cross the JNI boundary and at worst they interact with a slow piece of hardware (possibly over a network). The current design will have two calls in a worst case, but is likely to have only one call the vast majority of the time.

[1] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L92
[2] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406

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

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

From mstjohns at comcast.net  Sat Mar 20 19:12:12 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Sat, 20 Mar 2021 15:12:12 -0400
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On 3/20/2021 2:46 PM, SalusaSecondus wrote:
> On Sat, 20 Mar 2021 17:52:00 GMT, SalusaSecondus  wrote:
>
>>> @valeriepeng Sorry for the delay. There were unknown Windows build failure during the pre-submit tests that I have to rebase my commits on top of the  master tip. This new revision should cover all comments you left before. Thank you!
>> Mike,
>>
>>  From what I can find, if you try to get a spec from a non-extractable key you'll get an `InvalidKeySpecException`.
>> 1. `C_GetAttributeValue`will throw a `PKCS11Exception`
>> 2. The `PKCS11Exception` gets caught in [P11KeyFactory](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyFactory.java#L98-L99) which rethrows it as an `InvalidKeySpecException`.
> We seem to have a choice and I'm not sure the best way to approach this.
>
> 1. We trust the properties in `P11Key` and just ask it if the values are both sensitive and extractable. [1]
> 2. But if we already trust P11Key, why not also trust that it properly implements the RSAPrivateKey interfaces [2]. This is the strategy used by the snippet I posted earlier (delegating to `implGetSoftwareFactory()`)
> 3. We don't trust P11Key except to use getKeyId(), this yields the current design where we pull the attributes every time the factory needs them.
>
> We should probably reduce calls to `C_GetAttributeValue` as they may be very slow. At the least they cross the JNI boundary and at worst they interact with a slow piece of hardware (possibly over a network). The current design will have two calls in a worst case, but is likely to have only one call the vast majority of the time.
>
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L92
> [2] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2949

Actually, the important lines are 63-66 and 365-373:

 ?* If the components are not accessible, we use a generic class that
 ?* only implements PrivateKey (or SecretKey). Whether the components of a
 ?* key are extractable is automatically determined when the key object is
 ?* created.

> attributes = getAttributes(session, keyID, attributes, new 
> CK_ATTRIBUTE[] {
> ??????????? new CK_ATTRIBUTE(CKA_TOKEN),
> ??????????? new CK_ATTRIBUTE(CKA_SENSITIVE),
> ??????????? new CK_ATTRIBUTE(CKA_EXTRACTABLE),
> ??????? });
> ??????? if (attributes[1].getBoolean() || (attributes[2].getBoolean() 
> == false)) {
> ??????????? return new P11PrivateKey
> ??????????????? (session, keyID, algorithm, keyLength, attributes);
> ??????? }

If the key is non-extractable, then the only attributes will be these 
three and the underlying type will be P11Key.P11PrivateKey rather than 
one of the RSA variants.

Simple check at the top.

Mike



From github.com+829871+salusasecondus at openjdk.java.net  Sat Mar 20 19:27:38 2021
From: github.com+829871+salusasecondus at openjdk.java.net (SalusaSecondus)
Date: Sat, 20 Mar 2021 19:27:38 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Sat, 20 Mar 2021 18:43:34 GMT, SalusaSecondus  wrote:

>> Mike,
>> 
>> From what I can find, if you try to get a spec from a non-extractable key you'll get an `InvalidKeySpecException`.
>> 1. `C_GetAttributeValue`will throw a `PKCS11Exception`
>> 2. The `PKCS11Exception` gets caught in [P11KeyFactory](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyFactory.java#L98-L99) which rethrows it as an `InvalidKeySpecException`.
>
> We seem to have a choice and I'm not sure the best way to approach this.
> 
> 1. We trust the properties in `P11Key` and just ask it if the values are both sensitive and extractable. [1]
> 2. But if we already trust P11Key, why not also trust that it properly implements the RSAPrivateKey interfaces [2]. This is the strategy used by the snippet I posted earlier (delegating to `implGetSoftwareFactory()`)
> 3. We don't trust P11Key except to use getKeyId(), this yields the current design where we pull the attributes every time the factory needs them.
> 
> We should probably reduce calls to `C_GetAttributeValue` as they may be very slow. At the least they cross the JNI boundary and at worst they interact with a slow piece of hardware (possibly over a network). The current design will have two calls in a worst case, but is likely to have only one call the vast majority of the time.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L92
> [2] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406

P11PrivateKey is private so we cannot check that. Our options to figure out if something is sensitive are:
1. See if it doesn't implement `RSAPrivateKey` (this yields the prior snippet with `implGetSoftwareFactory()`)
2. Try to access the attributes directly from the token (this yields the current solution which we're modifying)
3. Check the value of `p11Key.extractable` (which is package-private and thus visible)

The smallest change would be to keep our strategy as 2. While I like it the least (my favorite is number 1) it has the smallest risk of changing some undocumented behavior on a PKCS#11 device that we're unfamiliar with (and not testing because we may not have the hardware costing tens of thousands of dollars). Option 3 somewhat spits the difference between 1 and 2.

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

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

From ssahoo at openjdk.java.net  Mon Mar 22 10:35:59 2021
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Mon, 22 Mar 2021 10:35:59 GMT
Subject: RFR: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
Message-ID: <0HJB8qtw18ObK4vx2igOvWQTeEMGc27LE5SQSHH6XVE=.11ac3413-7b79-44b8-aec1-1e424fe06b09@github.com>

The Test is updated to use positive integer as seed for SecureRandom.

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

Commit messages:
 - 8247895: SHA1PRNGReseed.java is calling setSeed(0)

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

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

From ssahoo at openjdk.java.net  Mon Mar 22 10:52:52 2021
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Mon, 22 Mar 2021 10:52:52 GMT
Subject: RFR: 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java
 failed with Read timed out
Message-ID: 

The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds set on sslServerSocket. This time interval could be inadequate when the machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So the statement has been removed.

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

Commit messages:
 - 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out

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

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

From aefimov at openjdk.java.net  Mon Mar 22 12:16:40 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 22 Mar 2021 12:16:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: 
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: 

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt  wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

`java.naming` module changes look good to me.

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

Marked as reviewed by aefimov (Committer).

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

From akozlov at openjdk.java.net  Mon Mar 22 12:50:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 22 Mar 2021 12:50:14 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
Message-ID: 

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:

 - Merge branch 'master' into jdk-macos
 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch
 - 8262903: [macos_aarch64] Thread::current() called on detached thread
 - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=28
  Stats: 2947 lines in 75 files changed: 2838 ins; 27 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From dfuchs at openjdk.java.net  Mon Mar 22 13:09:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 22 Mar 2021 13:09:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: 
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: 

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt  wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

Marked as reviewed by dfuchs (Reviewer).

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

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

From github.com+76791+alblue at openjdk.java.net  Mon Mar 22 13:41:39 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Mon, 22 Mar 2021 13:41:39 GMT
Subject: Integrated: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt  wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

This pull request has now been integrated.

Changeset: 5262d95b
Author:    Alex Blewitt 
Committer: Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/5262d95b
Stats:     261 lines in 69 files changed: 0 ins; 0 del; 261 mod

8263855: Use the blessed modifier order in java.management/naming

Reviewed-by: redestad, aefimov, dfuchs

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

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

From jlaskey at openjdk.java.net  Mon Mar 22 14:29:05 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 22 Mar 2021 14:29:05 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v33]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Cleaned up ints(), longs(), doubles()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/63094f9d..5e98d915

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=32
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=31-32

  Stats: 782 lines in 4 files changed: 310 ins; 416 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From jlaskey at openjdk.java.net  Mon Mar 22 14:42:49 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 22 Mar 2021 14:42:49 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v32]
In-Reply-To: <_uMAp-rI5lz4tzevS6jXiPsD_X6SSqequ5Gd5tc0lg8=.7cceb178-3fdc-46ee-86c4-99b2944d9e04@github.com>
References: 
 
 <_uMAp-rI5lz4tzevS6jXiPsD_X6SSqequ5Gd5tc0lg8=.7cceb178-3fdc-46ee-86c4-99b2944d9e04@github.com>
Message-ID: 

On Thu, 18 Mar 2021 21:43:16 GMT, Joe Darcy  wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - Review revisions
>>  - Missing @since
>>  - Review revisions
>>  - Review requested changes
>>  - Merge branch 'master' into 8248862
>>  - Remove conflicts
>>  - Use isAnnotationPresent
>>  - Introduce isDeprecated
>>  - Update javadoc
>>  - ... and 57 more: https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1290:
> 
>> 1288:          * @return a new object that is a copy of this generator
>> 1289:          */
>> 1290:         LeapableGenerator copy();
> 
> Suggest adding an Override annotation here and possibly to inheritDoc the text from Jumpable.copy.

Fails due to result variance.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1455:
> 
>> 1453:          *                                  period of this generator
>> 1454:          */
>> 1455:         void jump(double distance);
> 
> Suggest Override and inheritDoc combo.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1465:
> 
>> 1463:          * @implSpec The default implementation invokes jump(jumpDistance()).
>> 1464:          */
>> 1465:         default void jump() { jump(jumpDistance()); }
> 
> Should be able to avoid defining the jump method in this subinterface.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1486:
> 
>> 1484:          * ({@link Long#MAX_VALUE Long.MAX_VALUE}).
>> 1485:          */
>> 1486:         default Stream jumps(double distance) {
> 
> Suggest adding an Override annotation.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1521:
> 
>> 1519:          * {@link ArbitrarilyJumpableGenerator#leapDistance() leapDistance}().
>> 1520:          */
>> 1521:         default void leap() { jump(leapDistance()); }
> 
> Should need to define this method in the subinterface of Leapable.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1538:
> 
>> 1536:          * returns the copy.
>> 1537:          */
>> 1538:         default ArbitrarilyJumpableGenerator copyAndJump(double distance) {
> 
> Suggest Override and inheritDoc.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

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

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

From weijun at openjdk.java.net  Mon Mar 22 15:35:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Mar 2021 15:35:47 GMT
Subject: RFR: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
In-Reply-To: <0HJB8qtw18ObK4vx2igOvWQTeEMGc27LE5SQSHH6XVE=.11ac3413-7b79-44b8-aec1-1e424fe06b09@github.com>
References: <0HJB8qtw18ObK4vx2igOvWQTeEMGc27LE5SQSHH6XVE=.11ac3413-7b79-44b8-aec1-1e424fe06b09@github.com>
Message-ID: 

On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo  wrote:

> The Test is updated to use positive integer as seed for SecureRandom.

Marked as reviewed by weijun (Reviewer).

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

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

From weijun at openjdk.java.net  Mon Mar 22 15:56:59 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Mar 2021 15:56:59 GMT
Subject: RFR: 8263978: Clarify why 0 argument is ignored in
 SecureRandom::setSeed
Message-ID: 

We don't use `digest` anymore but still need to ignore the 0 argument.

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

Commit messages:
 - 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed

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

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

From xuelei at openjdk.java.net  Mon Mar 22 16:01:42 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 22 Mar 2021 16:01:42 GMT
Subject: RFR: 8225438:
 javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed
 out
In-Reply-To: 
References: 
Message-ID: 

On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo  wrote:

> The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds set on sslServerSocket. This time interval could be inadequate when the machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So the statement has been removed.

Marked as reviewed by xuelei (Reviewer).

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

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

From rhalade at openjdk.java.net  Mon Mar 22 17:24:41 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 22 Mar 2021 17:24:41 GMT
Subject: RFR: 8225438:
 javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed
 out
In-Reply-To: 
References: 
Message-ID: 

On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo  wrote:

> The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds set on sslServerSocket. This time interval could be inadequate when the machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So the statement has been removed.

Marked as reviewed by rhalade (Reviewer).

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

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

From rhalade at openjdk.java.net  Mon Mar 22 17:39:39 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 22 Mar 2021 17:39:39 GMT
Subject: RFR: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
In-Reply-To: <0HJB8qtw18ObK4vx2igOvWQTeEMGc27LE5SQSHH6XVE=.11ac3413-7b79-44b8-aec1-1e424fe06b09@github.com>
References: <0HJB8qtw18ObK4vx2igOvWQTeEMGc27LE5SQSHH6XVE=.11ac3413-7b79-44b8-aec1-1e424fe06b09@github.com>
Message-ID: 

On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo  wrote:

> The Test is updated to use positive integer as seed for SecureRandom.

Marked as reviewed by rhalade (Reviewer).

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

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

From hchao at openjdk.java.net  Mon Mar 22 17:53:43 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Mon, 22 Mar 2021 17:53:43 GMT
Subject: RFR: 8225438:
 javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed
 out
In-Reply-To: 
References: 
Message-ID: 

On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo  wrote:

> The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds set on sslServerSocket. This time interval could be inadequate when the machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So the statement has been removed.

Marked as reviewed by hchao (Committer).

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

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

From weijun at openjdk.java.net  Mon Mar 22 18:06:56 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Mar 2021 18:06:56 GMT
Subject: RFR: 8263978: Clarify why 0 argument is ignored in
 SecureRandom::setSeed [v2]
In-Reply-To: 
References: 
Message-ID: 

> We don't use `digest` anymore but still need to ignore the 0 argument.

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

  typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3124/files
  - new: https://git.openjdk.java.net/jdk/pull/3124/files/dd61f386..6bd8b100

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

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

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

From jlaskey at openjdk.java.net  Mon Mar 22 18:14:09 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 22 Mar 2021 18:14:09 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v34]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - RandomGeneratorFactory::all(Class category) @implNote was out of date
 - Clarify all()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/5e98d915..4562dd13

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=33
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=32-33

  Stats: 16 lines in 2 files changed: 3 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From valeriep at openjdk.java.net  Mon Mar 22 18:43:41 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 22 Mar 2021 18:43:41 GMT
Subject: RFR: 8263978: Clarify why 0 argument is ignored in
 SecureRandom::setSeed [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Mar 2021 18:06:56 GMT, Weijun Wang  wrote:

>> We don't use `digest` anymore but still need to ignore the 0 argument.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

src/java.base/share/classes/java/security/SecureRandom.java line 739:

> 737:          * to actually do any seeding. We either keep the object unseeded
> 738:          * (in `new SecureRandom()`) or we seed the object explicitly
> 739:          * (in `new SecureRandom(byte[])`).

Maybe clearer to make it shorter? I removed the "It's critical..." sentence as it seems redundant.
/*
 * Ignore call from super constructor as well as any other calls 
 * unfortunate enough to be passing 0. All SecureRandom
 * constructors call `super(0)` which leads to `setSeed(0)`.
 * We either keep the object unseeded (in `new SecureRandom()`) 
 * or we seed the object explicitly (in `new SecureRandom(byte[])`).
 */

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

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

From valeriep at openjdk.java.net  Mon Mar 22 18:51:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 22 Mar 2021 18:51:40 GMT
Subject: RFR: 8248268: Support KWP in addition to KW
In-Reply-To: 
References: 
Message-ID: 

On Thu, 4 Feb 2021 10:51:12 GMT, Valerie Peng  wrote:

> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
> 
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
> 
> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
> 
> Thanks,
> Valerie

Ping, anyone has time to review this?

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

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

From weijun at openjdk.java.net  Mon Mar 22 19:44:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 22 Mar 2021 19:44:40 GMT
Subject: RFR: 8263978: Clarify why 0 argument is ignored in
 SecureRandom::setSeed [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 22 Mar 2021 18:40:37 GMT, Valerie Peng  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/java.base/share/classes/java/security/SecureRandom.java line 739:
> 
>> 737:          * to actually do any seeding. We either keep the object unseeded
>> 738:          * (in `new SecureRandom()`) or we seed the object explicitly
>> 739:          * (in `new SecureRandom(byte[])`).
> 
> Maybe clearer to make it shorter? I removed the "It's critical..." sentence as it seems redundant.
> /*
>  * Ignore call from super constructor as well as any other calls 
>  * unfortunate enough to be passing 0. All SecureRandom
>  * constructors call `super(0)` which leads to `setSeed(0)`.
>  * We either keep the object unseeded (in `new SecureRandom()`) 
>  * or we seed the object explicitly (in `new SecureRandom(byte[])`).
>  */

Sure I can do that.

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

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

From valeriep at openjdk.java.net  Mon Mar 22 21:43:31 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 22 Mar 2021 21:43:31 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
Message-ID: 

> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
> 
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
> 
> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
  AES/KWP/NoPadding

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2404/files
  - new: https://git.openjdk.java.net/jdk/pull/2404/files/bc912f63..c90fdb1e

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

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

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

From valeriep at openjdk.java.net  Tue Mar 23 00:49:48 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 23 Mar 2021 00:49:48 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: <0YOaHUY4C0h2H-I7G-Kc-R6rpZCE7CM0G2lWxlRTWpM=.232b2cd5-9697-4584-9f99-8feeb42840ef@github.com>
References: 
 
 
 
 
 
 <0YOaHUY4C0h2H-I7G-Kc-R6rpZCE7CM0G2lWxlRTWpM=.232b2cd5-9697-4584-9f99-8feeb42840ef@github.com>
Message-ID: 

On Sat, 20 Mar 2021 17:41:45 GMT, SalusaSecondus  wrote:

>> I think that this code will work, but since there already is [P11RSAPrivateKey and P11RSAPrivateNonCRTKey](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406) (both of which implement the standard `RSAPrivateKey` and `RSAPrivateCrtKey` interfaces respectively), can we just depend on and simplify our code? (My concern is that there is some unknown reason for calling `C_GetAttributeValue` directly here.)
>> 
>> For example (based on the non-P11 code above)
>>         } else if (key instanceof RSAPrivateKey) {
>>             if (keySpec.isAssignableFrom(PKCS8_KEYSPEC_CLS)) {
>>                 return keySpec.cast(new PKCS8EncodedKeySpec(key.getEncoded()));
>>             } else if (keySpec.isAssignableFrom(RSA_PRIVCRT_KEYSPEC_CLS)) {
>>                 if (key instanceof RSAPrivateCrtKey) {
>>                     RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey)key;
>>                     return keySpec.cast(new RSAPrivateCrtKeySpec(
>>                         crtKey.getModulus(),
>>                         crtKey.getPublicExponent(),
>>                         crtKey.getPrivateExponent(),
>>                         crtKey.getPrimeP(),
>>                         crtKey.getPrimeQ(),
>>                         crtKey.getPrimeExponentP(),
>>                         crtKey.getPrimeExponentQ(),
>>                         crtKey.getCrtCoefficient(),
>>                         crtKey.getParams()
>>                     ));
>>                 } else if (key instanceof RSAPrivateKey) {
>>                     if (!keySpec.isAssignableFrom(RSA_PRIV_KEYSPEC_CLS)) {
>>                         throw new InvalidKeySpecException
>>                             ("RSAPrivateCrtKeySpec can only be used with CRT keys");
>>                     }
>> 
>>                     // fall through to RSAPrivateKey (non-CRT)
>>                     RSAPrivateKey rsaKey = (RSAPrivateKey) key;
>>                     return keySpec.cast(new RSAPrivateKeySpec(
>>                         rsaKey.getModulus(),
>>                         rsaKey.getPrivateExponent(),
>>                         rsaKey.getParams()
>>                     ));
>>                 } else { // New P11 code starts here and handles the P11PrivateKey case
>>                     throw new InvalidKeySpecException("RSA Private key is not extractable");
>>                 } // End new P11 code
>>             } else {
>>                 throw new InvalidKeySpecException
>>                         ("KeySpec must be RSAPrivate(Crt)KeySpec or "
>>                         + "PKCS8EncodedKeySpec for RSA private keys");
>>             }
>
> I've used your code for both because it looks like a good solution.
> 
> One thing which puzzles me is that the following implementation for the P11 code passes all tests and avoids any interaction with P11 library at all. I didn't want to use it because I'm concerned that there is an untested edge-case we'd bump into.
> 
>      T implGetPrivateKeySpec(P11Key key, Class keySpec,
>             Session[] session) throws PKCS11Exception, InvalidKeySpecException {
>         if (key instanceof RSAPrivateKey) {
>             try {
>                 return implGetSoftwareFactory().getKeySpec(key, keySpec);
>             } catch (final InvalidKeySpecException  e) {
>                 throw e;
>             } catch (final GeneralSecurityException e) {
>                 throw new InvalidKeySpecException("Could not generate KeySpec", e);
>             }
>         } else {
>             throw new InvalidKeySpecException("Key is not extractable");
>         }
>     }

Well, when the key object has all the attribute values available, things will often work regardless which path you took.

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

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

From valeriep at openjdk.java.net  Tue Mar 23 01:03:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 23 Mar 2021 01:03:40 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Sat, 20 Mar 2021 19:24:45 GMT, SalusaSecondus  wrote:

>> We seem to have a choice and I'm not sure the best way to approach this.
>> 
>> 1. We trust the properties in `P11Key` and just ask it if the values are both sensitive and extractable. [1]
>> 2. But if we already trust P11Key, why not also trust that it properly implements the RSAPrivateKey interfaces [2]. This is the strategy used by the snippet I posted earlier (delegating to `implGetSoftwareFactory()`)
>> 3. We don't trust P11Key except to use getKeyId(), this yields the current design where we pull the attributes every time the factory needs them.
>> 
>> We should probably reduce calls to `C_GetAttributeValue` as they may be very slow. At the least they cross the JNI boundary and at worst they interact with a slow piece of hardware (possibly over a network). The current design will have two calls in a worst case, but is likely to have only one call the vast majority of the time.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L92
>> [2] https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406
>
> P11PrivateKey is private so we cannot check that. Our options to figure out if something is sensitive are:
> 1. See if it doesn't implement `RSAPrivateKey` (this yields the prior snippet with `implGetSoftwareFactory()`)
> 2. Try to access the attributes directly from the token (this yields the current solution which we're modifying)
> 3. Check the value of `p11Key.extractable` (which is package-private and thus visible)
> 
> The smallest change would be to keep our strategy as 2. While I like it the least (my favorite is number 1) it has the smallest risk of changing some undocumented behavior on a PKCS#11 device that we're unfamiliar with (and not testing because we may not have the hardware costing tens of thousands of dollars). Option 3 somewhat spits the difference between 1 and 2.

Or, how about changing the scope of P11PrivateKey/P11RSAPrivateKey/P11RSAPrivateNonCRTKey to pkg private? This way we can take advantage of the info implied by the type of class and avoid the potential double failure of querying the attributes.

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

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

From valeriep at openjdk.java.net  Tue Mar 23 02:28:45 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 23 Mar 2021 02:28:45 GMT
Subject: RFR: 8263978: Clarify why 0 argument is ignored in
 SecureRandom::setSeed [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Mar 2021 18:06:56 GMT, Weijun Wang  wrote:

>> We don't use `digest` anymore but still need to ignore the 0 argument.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Marked as reviewed by valeriep (Reviewer).

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

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

From ssahoo at openjdk.java.net  Tue Mar 23 06:49:45 2021
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Tue, 23 Mar 2021 06:49:45 GMT
Subject: Integrated: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
In-Reply-To: <0HJB8qtw18ObK4vx2igOvWQTeEMGc27LE5SQSHH6XVE=.11ac3413-7b79-44b8-aec1-1e424fe06b09@github.com>
References: <0HJB8qtw18ObK4vx2igOvWQTeEMGc27LE5SQSHH6XVE=.11ac3413-7b79-44b8-aec1-1e424fe06b09@github.com>
Message-ID: 

On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo  wrote:

> The Test is updated to use positive integer as seed for SecureRandom.

This pull request has now been integrated.

Changeset: 5a51d709
Author:    Sibabrata Sahoo 
URL:       https://git.openjdk.java.net/jdk/commit/5a51d709
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8247895: SHA1PRNGReseed.java is calling setSeed(0)

Reviewed-by: weijun, rhalade

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

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

From ssahoo at openjdk.java.net  Tue Mar 23 06:51:41 2021
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Tue, 23 Mar 2021 06:51:41 GMT
Subject: Integrated: 8225438:
 javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed
 out
In-Reply-To: 
References: 
Message-ID: 

On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo  wrote:

> The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds set on sslServerSocket. This time interval could be inadequate when the machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So the statement has been removed.

This pull request has now been integrated.

Changeset: 036ae0ea
Author:    Sibabrata Sahoo 
URL:       https://git.openjdk.java.net/jdk/commit/036ae0ea
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out

Reviewed-by: xuelei, rhalade, hchao

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

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

From aph at openjdk.java.net  Tue Mar 23 09:56:56 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 09:56:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: 
References: 
 
 
Message-ID: <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>

On Fri, 12 Mar 2021 16:32:10 GMT, Andrew Haley  wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
>> 
>>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>>  - workaround JDK-8262895 by disabling subtest
>>  - Fix typo
>>  - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
>>  - JDK-8259937: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Fix after JDK-8259539, partially revert preconditions
>>  - JDK-8260471: bsd_aarch64 part
>>  - JDK-8259539: bsd_aarch64 part
>>  - JDK-8257828: bsd_aarch64 part
>>  - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834
>
>> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
> 
> I think that what you've got now is fine.

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
> 
> On 3/15/21 6:56 PM, Anton Kozlov wrote:
> 
> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley  wrote:
> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
> > > 
> > > 
> > > Robustness, clarity, maintainability, convention. Why not?
> > 
> > 
> > I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`).
> 
> No, no, no! I am not suggesting you change anything else, just that
> you do not define contentless macros. You might as well define it
> to be something, and true is a reasonable default, that's all. It's
> not terribly important, it's just good practice.

I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

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

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

From aph at openjdk.java.net  Tue Mar 23 09:56:57 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 09:56:57 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
References: 
 
 
 <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
Message-ID: 

On Tue, 23 Mar 2021 09:53:54 GMT, Andrew Haley  wrote:

>>> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
>> 
>> I think that what you've got now is fine.
>
>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
>> 
>> On 3/15/21 6:56 PM, Anton Kozlov wrote:
>> 
>> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley  wrote:
>> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
>> > > 
>> > > 
>> > > Robustness, clarity, maintainability, convention. Why not?
>> > 
>> > 
>> > I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`).
>> 
>> No, no, no! I am not suggesting you change anything else, just that
>> you do not define contentless macros. You might as well define it
>> to be something, and true is a reasonable default, that's all. It's
>> not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

So, where are we up to now? Are we done yet?

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

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

From vkempik at openjdk.java.net  Tue Mar 23 11:20:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 11:20:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: 
References: 
 
 
 <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
 
Message-ID: 

On Tue, 23 Mar 2021 09:54:16 GMT, Andrew Haley  wrote:

> So, where are we up to now? Are we done yet?

Hello
we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17

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

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

From jlaskey at openjdk.java.net  Tue Mar 23 11:32:08 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 23 Mar 2021 11:32:08 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v35]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Removed @since from nextDouble ThreadLocalRandom

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/4562dd13..22ea21d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=34
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=33-34

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

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

From ihse at openjdk.java.net  Tue Mar 23 12:52:56 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 23 Mar 2021 12:52:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes still look good. Hope you can get this done now! :)

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

Marked as reviewed by ihse (Reviewer).

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

From erikj at openjdk.java.net  Tue Mar 23 12:52:55 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 23 Mar 2021 12:52:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From akozlov at openjdk.java.net  Tue Mar 23 13:28:52 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 23 Mar 2021 13:28:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 Mar 2021 12:49:34 GMT, Magnus Ihse Bursie  wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Build changes still look good. Hope you can get this done now! :)

> > No, no, no! I am not suggesting you change anything else, just that
> > you do not define contentless macros. You might as well define it
> > to be something, and true is a reasonable default, that's all. It's
> > not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

Sorry, I missed your reply.

R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. 

The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137

But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
and       
https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

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

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

From vkempik at openjdk.java.net  Tue Mar 23 13:47:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 13:47:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 23 Mar 2021 13:26:19 GMT, Anton Kozlov  wrote:

>> Build changes still look good. Hope you can get this done now! :)
>
>> > No, no, no! I am not suggesting you change anything else, just that
>> > you do not define contentless macros. You might as well define it
>> > to be something, and true is a reasonable default, that's all. It's
>> > not terribly important, it's just good practice.
>> 
>> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.
> 
> Sorry, I missed your reply.
> 
> R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. 
> 
> The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
> and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137
> 
> But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
> and       
> https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

Hello
That depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

> 23 ????? 2021 ?., ? 16:39, drej1 ***@***.***> ???????(?):
> 
> 
> So, where are we up to now? Are we done yet?
> 
> Hello
> we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17
> 
> Hi there, will this be also supported backwards? To support java11 LTS version?
> 
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub , or unsubscribe .
>

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

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

From aph at openjdk.java.net  Tue Mar 23 13:56:59 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 13:56:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by aph (Reviewer).

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

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

From aph at openjdk.java.net  Tue Mar 23 14:00:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 14:00:58 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 Mar 2021 13:54:24 GMT, Andrew Haley  wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by aph (Reviewer).

> [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

To the extent that 11u has fixed policies :)  we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

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

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

From vkempik at openjdk.java.net  Tue Mar 23 14:03:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 14:03:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 23 Mar 2021 13:58:03 GMT, Andrew Haley  wrote:

> > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> 
> To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

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

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

From mbeckwit at openjdk.java.net  Tue Mar 23 14:27:53 2021
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 23 Mar 2021 14:27:53 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Tue, 23 Mar 2021 14:01:12 GMT, Vladimir Kempik  wrote:

> > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> > 
> > 
> > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
> 
> @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

Thanks, @theRealAph, and @VladimirKempik . We are on it!

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

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

From mbeckwit at openjdk.java.net  Tue Mar 23 15:27:56 2021
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 23 Mar 2021 15:27:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
Message-ID: <8y8WYVmVF_qrroxDo516Ucz1qWX5kMpPQHeqZgJNI2Q=.004fe86c-2b18-4a90-8499-1a34e64da3db@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by mbeckwit (Author).

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

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

From luhenry at openjdk.java.net  Tue Mar 23 16:23:54 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 23 Mar 2021 16:23:54 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by luhenry (Author).

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

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

From aph at openjdk.java.net  Tue Mar 23 16:36:55 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 16:36:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry  wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by luhenry (Author).

> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> > > 
> > > 
> > > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
> > 
> > 
> > @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)
> 
> Thanks, @theRealAph, and @VladimirKempik . We are on it!

It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

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

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

From ascarpino at openjdk.java.net  Tue Mar 23 16:51:53 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 23 Mar 2021 16:51:53 GMT
Subject: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey
 impl and revised exception handling [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I need a code review of this change to ECDH.  It is a combination of fixing the implementation to not only accept ECPrivateKeyImpl along with a fix to the exception handling.  They started as two fixes, but with the exception handling the underlying code changed significantly that made the ECPrivateKey change in a different place.  The new exception handling is a result of no longer having the native library.  Many of the checks waited until generateSecret() to send the keys to the native library. Now that native is gone, checks can happen when keys are provided to the methods and proper exceptions can be thrown instead of wrapping everything as a ProviderException
> 
> thanks,
> 
> Tony

Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - update test bug id
 - Simpler fix for ECPrivateKey
 - merge with 8261502
 - initial change

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

Changes: https://git.openjdk.java.net/jdk/pull/2659/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2659&range=03
  Stats: 203 lines in 2 files changed: 137 ins; 32 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2659.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2659/head:pull/2659

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

From raell at web.de  Tue Mar 23 17:36:06 2021
From: raell at web.de (raell at web.de)
Date: Tue, 23 Mar 2021 18:36:06 +0100
Subject: RFR: 8262880: Add support for the NSS Key Log Format for
 SSL/TLS keys
References: 
 
 
 
Message-ID: 

Hi all, 

I very much appreciate @SalusaSecondus' idea for providing a key logger. 

For, when working with networks, it's quite natural to analyze message flow 
with help of wireshark. In TLS 1.3 this isn't possible without a key log 
because most parts of the handshake messages are encrypted. So, if both, 
client and server, are Java apps, it isn't possible to trace the message flow 
with wireshark. That's a great disadvantage. 

To give an example: I'm running a https client based on SSLEngine and an 
AsynchronousSocketChannel. The entries in the log provided by javax.net.debug=ssl 
arise from SSLEngine, but the messages itself are sent by the channel. So it is 
not possible to check what messages are actually sent over the network 
(I could have made a programming error in using the data provided by 
the SSLEngine or something could go wrong within the channel). 
Therefore, being able to produce a key log on the Java client side and 
to observe the messages and their content in wireshark, would be very 
helpful.

Concerning the security issue: Of course, holding keys is always a risk. 
But if one stores the output of javax.net.debug in a file, then an attacker 
who has access to the system could read decrypted messages as well. But, of 
course, the implementation of a key logger in Java has to ensure that no 
key log is produced by default but only if it is explicitly enabled 
(similar to javax.net.debug). 

I would be very glad if there would be a chance to implement @SalusaSecondus' 
proposal in some way because a key logger would be really helpful for 
doing networking with Java. 

Regards, 

Ralph 

?
?
?

Gesendet:?Freitag, 19. M?rz 2021 um 13:48 Uhr
Von:?"Sean Mullan" 
An:?security-dev at openjdk.java.net
Betreff:?Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys
On Thu, 18 Mar 2021 21:26:28 GMT, SalusaSecondus  wrote:

>> It is not good practice to leave secret information in debug log. Also, it may be not a good practice to introduce new logger format, including file and NSS format, into the SSLLogger. Someone also may want to introduce log format for MSS or XSS as well. Instead, please consider to make use of the features of Java Logger if you want to write the log to files, or use any special format.
>
> @XueleiFan I'd really like to move this forward but I'm uncertain what changes you want me to make. This extra debugging information will be very valuable to those of us debugging Java TLS connections.

I am also not comfortable adding this feature to the JDK, especially since every build of the JDK would by default have this feature enabled. Logging sensitive information to log files is not good security practice (there are many references I could cite). I also think it would be too easy to accidentally leave the system property enabled or forget to remove the file.

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

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

From ecki at zusammenkunft.net  Tue Mar 23 18:23:13 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 23 Mar 2021 18:23:13 +0000
Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS
 keys
In-Reply-To: 
References: 
 
 
 ,
 
Message-ID: 

Hello,

I agree with the need for such a facility.

Instead, or in addition to a key log a session handshake listener with access to the handshake result (and the master key) would also be useful for auditing, renegotiation limiting and key logging. It can even be used for things like priming introspecting firewalls.

There is not yet a good official platform API with access to that kind of information (and proxying client Hello packages to get the offered ciphers is really ugly). With the API an Adapter which can write NSS Keylogs can be provided by users and you don?t have to worry about having debug logging Code expose secrets.

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
Von: security-dev  im Auftrag von raell at web.de 
Gesendet: Tuesday, March 23, 2021 6:36:06 PM
An: security-dev at openjdk.java.net 
Betreff: Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys

Hi all,

I very much appreciate @SalusaSecondus' idea for providing a key logger.

For, when working with networks, it's quite natural to analyze message flow
with help of wireshark. In TLS 1.3 this isn't possible without a key log
because most parts of the handshake messages are encrypted. So, if both,
client and server, are Java apps, it isn't possible to trace the message flow
with wireshark. That's a great disadvantage.

To give an example: I'm running a https client based on SSLEngine and an
AsynchronousSocketChannel. The entries in the log provided by javax.net.debug=ssl
arise from SSLEngine, but the messages itself are sent by the channel. So it is
not possible to check what messages are actually sent over the network
(I could have made a programming error in using the data provided by
the SSLEngine or something could go wrong within the channel).
Therefore, being able to produce a key log on the Java client side and
to observe the messages and their content in wireshark, would be very
helpful.

Concerning the security issue: Of course, holding keys is always a risk.
But if one stores the output of javax.net.debug in a file, then an attacker
who has access to the system could read decrypted messages as well. But, of
course, the implementation of a key logger in Java has to ensure that no
key log is produced by default but only if it is explicitly enabled
(similar to javax.net.debug).

I would be very glad if there would be a chance to implement @SalusaSecondus'
proposal in some way because a key logger would be really helpful for
doing networking with Java.

Regards,

Ralph





Gesendet: Freitag, 19. M?rz 2021 um 13:48 Uhr
Von: "Sean Mullan" 
An: security-dev at openjdk.java.net
Betreff: Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys
On Thu, 18 Mar 2021 21:26:28 GMT, SalusaSecondus  wrote:

>> It is not good practice to leave secret information in debug log. Also, it may be not a good practice to introduce new logger format, including file and NSS format, into the SSLLogger. Someone also may want to introduce log format for MSS or XSS as well. Instead, please consider to make use of the features of Java Logger if you want to write the log to files, or use any special format.
>
> @XueleiFan I'd really like to move this forward but I'm uncertain what changes you want me to make. This extra debugging information will be very valuable to those of us debugging Java TLS connections.

I am also not comfortable adding this feature to the JDK, especially since every build of the JDK would by default have this feature enabled. Logging sensitive information to log files is not good security practice (there are many references I could cite). I also think it would be too easy to accidentally leave the system property enabled or forget to remove the file.

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

PR: https://git.openjdk.java.net/jdk/pull/2896
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From github.com+829871+salusasecondus at openjdk.java.net  Tue Mar 23 20:15:43 2021
From: github.com+829871+salusasecondus at openjdk.java.net (Greg Rubin)
Date: Tue, 23 Mar 2021 20:15:43 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Mar 2021 21:43:31 GMT, Valerie Peng  wrote:

>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>> 
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
>> 
>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>   AES/KWP/NoPadding

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 41:

> 39:  * and represents AES cipher in KW mode.
> 40:  */
> 41: class AESKeyWrap extends FeedbackCipher {

I see lots of unsupported operations and `encrypt/decryptFinal` ignores their output parameters. Should we be extending `FeedbackCipher` if so much doesn't seem to quite fit?

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 155:

> 153:                 " be at least 16 bytes and multiples of 8");
> 154:         }
> 155:         // assert ptOfs == 0; ct == pt; ctOfs == 0;

Is this a missing code assertion?

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 193:

> 191:         if (!Arrays.equals(ivOut, 0, ICV1.length, this.iv, 0, ICV1.length)) {
> 192:             throw new IllegalBlockSizeException("Integrity check failed");
> 193:         }

It feels like an odd asymmetry that we validate the IV upon decryption in `AESKeyWrap` but the IV is prepended in `KeyWrapCipher.writeIvSemiBlock`.  I'm worried that by separating this logic like this it is easier for us to get it wrong (or break it in the future).

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 69:

> 67:         if (!Arrays.equals(ivAndLen, 0, ICV2.length, icv, 0, ICV2.length)) {
> 68:             throw new IllegalBlockSizeException("Integrity check failed");
> 69:         }

While I cannot find any public discussion of this, I'm always uncomfortable checking the plaintext (prior to authentication) against a known value in non-constant time. I'm worried that this (and the equivalent in the unpadded version) might be a problem in the future.

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 246:

> 244:         int outLen = validateIV(ivAndLen, this.iv);
> 245:         // check padding bytes
> 246:         int padLen = ctLen - outLen;

Can we add an explicit check that `0 <= padLen < SEMI_BLKSIZE`?

src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java line 87:

> 85:      */
> 86:     static final void W_INV(byte[] in, int inLen, byte[] ivOut,
> 87:             SymmetricCipher cipher) {

The asymmetry between `W` not taking an IV but `W_INV` returning an IV also bothers me and seems to make this harder to use safely.

src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 507:

> 505:             } else {
> 506:                 outLen = cipher.encryptFinal(dataBuf, 0, dataIdx, null, -1);
> 507:             }

Can we extract this shared logic (among the different versions of `engineDoFinal`) into a separate helper method so that the different `engineDoFinal` methods just need to handle their specific differences (such as returning `Arrays.copyOf(dataBuf, outLen)` or calling `System.arraycopy(dataBuf, 0, out, outOfs, outLen); return outLen;`).

src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 660:

> 658:     @Override
> 659:     protected byte[] engineWrap(Key key)
> 660:             throws IllegalBlockSizeException, InvalidKeyException {

Is it okay that we can call `cipher.init(Cipher.ENCRYPT_MODE, ...)` and then use it with `cipher.wrap()`?

Also, can we simply delegate the heavy lifting to `engineDoFinal()` (or the new suggested helper method) rather than duplicating this logic here?

test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/NISTWrapKAT.java line 105:

> 103: 
> 104:     @DataProvider
> 105:     public Object[][] testData() {

Can we please add test cases for `AES/KWP/NoPadding` where the input is an even multiple of 8? We've [seen bugs in this case before](https://github.com/pyca/cryptography/issues/4156).

test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java line 50:

> 48: 
> 49:         System.out.println("input len: " + inLen);
> 50:         c.init(Cipher.ENCRYPT_MODE, KEY, new IvParameterSpec(in, 0, ivLen));

Do we have tests for no IV (and thus the default)?
Do we have tests that the null (default) IV matches the results from an explicitly provided default ID?

test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java line 179:

> 177:         System.out.println("Testing " + ALGO);
> 178:         c = Cipher.getInstance(ALGO, "SunJCE");
> 179:         for (int i = 0; i < MAX_KWP_PAD_LEN; i++) {

I see that here (and earlier) we do test all padding lengths. I'd still like some KATs generated by a known good implementation to ensure that we are not just compatible with ourselves.

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

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

From mstjohns at comcast.net  Tue Mar 23 21:01:03 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 23 Mar 2021 17:01:03 -0400
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <7f34b35d-8531-20d4-8e10-ae089c1047f2@comcast.net>

On 3/23/2021 4:15 PM, Greg Rubin wrote:
>> 177:         System.out.println("Testing " + ALGO);
>> 178:         c = Cipher.getInstance(ALGO, "SunJCE");
>> 179:         for (int i = 0; i < MAX_KWP_PAD_LEN; i++) {
> I see that here (and earlier) we do test all padding lengths. I'd still like some KATs generated by a known good implementation to ensure that we are not just compatible with ourselves.


http://csrc.nist.gov/groups/STM/cavp/documents/mac/kwtestvectors.zip has 
the NIST test vectors.? See 
https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/mac/KWVS.pdf 
for details.

Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mstjohns at comcast.net  Tue Mar 23 21:26:06 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 23 Mar 2021 17:26:06 -0400
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
Message-ID: <10e250a4-ad0b-961f-89f9-89ad4f8654aa@comcast.net>

On 3/22/2021 5:43 PM, Valerie Peng wrote:
>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation.
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class.
>>
>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>>
>> Thanks,
>> Valerie

> PR: https://git.openjdk.java.net/jdk/pull/2404

KeyWrapCipher.java:

>       /**
> 212      * Sets the padding mechanism of this cipher. Currently, only
> 213      * "NoPadding" scheme is accepted for this cipher.
> 214      *
> 215      * @param padding the padding mechanism
> 216      *
> 217      * @exception NoSuchPaddingException if the requested padding mechanism
> 218      * does not match the supported padding scheme
> 219      */
> 220     @Override
> 221     protected void engineSetPadding(String padding)
> 222             throws NoSuchPaddingException {
> 223         if ((this.padding == null && !"NoPadding".equalsIgnoreCase(padding)) ||
> 224                 this.padding instanceof PKCS5Padding &&
> 225                 "PKCS5Padding".equalsIgnoreCase(padding)) {
> 226             throw new NoSuchPaddingException();
> 227         }
> 228     }

Shouldn't this be rejecting PKCS5Padding?

Actually, I keep wondering why this isn't? AES/KW/NoPadding, 
AES/KW/KWPPadding and AES/KW/AutoPadding where the latter doesn't take a 
user provided IV, but figures out which of the two default IV values to 
use based on whether the input is a multiple of the blocksize or not?

Decrypting is similar - do the decryption, and check which IV you get to 
figure out padded or not padded.

Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun at openjdk.java.net  Tue Mar 23 22:26:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 23 Mar 2021 22:26:52 GMT
Subject: RFR: 8263978: Clarify why 0 argument is ignored in
 SecureRandom::setSeed [v3]
In-Reply-To: 
References: 
Message-ID: <35i7i__wMoDY8X18FAjfJY7nNMFdVa7XDPgNTWHeY6Q=.6dc128d3-54a2-4190-8775-e082ceb86dad@github.com>

> We don't use `digest` anymore but still need to ignore the 0 argument.

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

  simplify

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3124/files
  - new: https://git.openjdk.java.net/jdk/pull/3124/files/6bd8b100..56dff532

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

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

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

From weijun at openjdk.java.net  Tue Mar 23 22:26:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 23 Mar 2021 22:26:53 GMT
Subject: Integrated: 8263978: Clarify why 0 argument is ignored in
 SecureRandom::setSeed
In-Reply-To: 
References: 
Message-ID: 

On Mon, 22 Mar 2021 15:49:55 GMT, Weijun Wang  wrote:

> We don't use `digest` anymore but still need to ignore the 0 argument.

This pull request has now been integrated.

Changeset: 0b2aa1b6
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/0b2aa1b6
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed

Reviewed-by: valeriep

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

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

From luoziyi at openjdk.java.net  Wed Mar 24 03:25:02 2021
From: luoziyi at openjdk.java.net (Ziyi Luo)
Date: Wed, 24 Mar 2021 03:25:02 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v6]
In-Reply-To: 
References: 
Message-ID: 

> This is a P2 regression introduced by JDK-8254717.
> 
> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
> 
> X-axis: type of `keySpec`
> Y-axis: type of `key`
> 
> Before JDK-8254717:
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
> 
> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
> 
> This commit fixes the regression.
> 
> 
> ### Tests
> 
> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed

Ziyi Luo has updated the pull request incrementally with two additional commits since the last revision:

 - Remove trailing whitespace
 - Refactor P11RSAKeyFactory and improve tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2949/files
  - new: https://git.openjdk.java.net/jdk/pull/2949/files/da25a691..2594ef2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2949&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2949&range=04-05

  Stats: 152 lines in 4 files changed: 95 ins; 23 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2949.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2949/head:pull/2949

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

From raell at web.de  Wed Mar 24 11:38:10 2021
From: raell at web.de (raell at web.de)
Date: Wed, 24 Mar 2021 12:38:10 +0100
Subject: JSSE reference guide issue
References: 
Message-ID: 

Concerning the question:?

>Also the note about TLS 1.3 in the same section isn't entirely clear
to me. What does it mean when the docs say "the contents of stateless
>tickets, in particular, the contents of a NewSessionTicket message,
>depend on the value of jdk.tls.server.enableSessionTicketExtension"?

In TLS 1.3, if stateless session resumption is in use (i.e.?
jdk.tls.server.enableSessionTicketExtension=true) the NewSessionTicket message?
includes all session information (in encrypted format). If session resumption is?
stateful (i.e. jdk.tls.server.enableSessionTicketExtension=false), the?
NewSessionTicket message just contains a key that is used by the server during session?
resumption in order to access the session information from its session cache.?

>why should I care?

The point is: In TLS 1.3 the resumption mode (stateful/stateless) can be configured?
by the property jdk.tls.server.enableSessionTicketExtension (though there is no?
SessionTicketExtension extension in TLS 1.3). But in JDK 14 or later,?
there is usually no need to change the default (=stateless).
?
Regards,?

Ralph?
?
?

Gesendet:?Freitag, 05. Februar 2021 um 08:42 Uhr
Von:?"Daniel Jeli?ski" 
An:?security-dev at openjdk.java.net
Betreff:?JSSE reference guide issue
Hi all,
What's the right spot to report documentation issues?

I've been reading the JSSE reference guide and noticed that in section
"Resuming Session Without Server-Side State"
(https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810)
it says "This feature is not enabled by default", which appears to be
a leftover from Java 13.

Also the note about TLS 1.3 in the same section isn't entirely clear
to me. What does it mean when the docs say "the contents of stateless
tickets, in particular, the contents of a NewSessionTicket message,
depend on the value of jdk.tls.server.enableSessionTicketExtension"?
How exactly does the contents change and why should I care?
Regards,
Daniel

From jjiang at openjdk.java.net  Wed Mar 24 14:35:40 2021
From: jjiang at openjdk.java.net (John Jiang)
Date: Wed, 24 Mar 2021 14:35:40 GMT
Subject: RFR: JDK-8263188: JSSE should fail fast if there isn't supported
 signature algorithm
In-Reply-To: 
References: 
Message-ID: 

On Mon, 8 Mar 2021 15:27:45 GMT, John Jiang  wrote:

> If signature_algorithms extension is present, but the algorithms are unreconginzed or unsupported, JSSE peers should send fatal alert immediately.
> For example, in this case, it's unnecssary to try to produce ServerHello, Certificate and ServerKeyExchange messages.

Could this change be reviewed? Thanks!

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

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

From christoph.langer at sap.com  Wed Mar 24 14:48:22 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 24 Mar 2021 14:48:22 +0000
Subject: [11u] RFR: 8206925: Support the certificate_authorities extension
In-Reply-To: 
References: 
Message-ID: 

Hi Martin,

your backport looks good. I see the new tests pass and our testing does not unveil other regressions. Reviewed.

Oracle has already included this item in 11.0.10 but it fell through the cracks for OpenJDK 11u due to an issue with the updates filter. However, it seems like an important item for TLS 1.3 usability. We have just received a customer request why this wasn?t included in 11u yet, they would need it for their product to move on to TLS 1.3. So I think we should strive for 11.0.11 with this backport. Please label accordingly. Adding @Andrew Haley and @Severin Gehwolf for their opinion on this decision ??

The CSR https://bugs.openjdk.java.net/browse/JDK-8248709 should apply to this backport, please link it to the JBS issue.

Thanks & Best regards
Christoph

From: Doerr, Martin 
Sent: Dienstag, 23. M?rz 2021 16:25
To: jdk-updates-dev at openjdk.java.net; security-dev 
Cc: Lindenmaier, Goetz ; Langer, Christoph 
Subject: [11u] RFR: 8206925: Support the certificate_authorities extension

Hi,

JDK-8206925 was backported to 11.0.10-oracle, but it?s still missing in the Open Source version.
I'd like to backport it for parity.
It does apply cleanly, but I had to modify it, because the following change is not in 11u:
https://bugs.openjdk.java.net/browse/JDK-8215712

Bug:
https://bugs.openjdk.java.net/browse/JDK-8206925

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/827bac238aa0

11u backport:
http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/webrev.00/

Manual change to make it work without JDK-8215712 (SSLStringizer and derived classes don?t take a HandshakeContext in 11u):
http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/8206925_ca_ext_diff.txt

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From djelinski1 at gmail.com  Wed Mar 24 15:29:50 2021
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Wed, 24 Mar 2021 16:29:50 +0100
Subject: JSSE reference guide issue
In-Reply-To: 
References: 
 
Message-ID: 

Thanks Ralph. I figured that out already. However, the docs are
(still) a bit misleading here. Let me quote:

> For TLS 1.3, stateless tickets use the existing PSK resumption extension. Therefore, session resumption **without server-site** state doesn't require these two properties. However, the contents of **stateless** tickets, in particular, the contents of a NewSessionTicket message, depend on the value of jdk.tls.server.enableSessionTicketExtension.
(emphasis mine)

The server can use PSK for either stateful or stateless tickets, and
the choice is solely at the server's discretion, the client has no
choice here. However, the paragraph above suggests that we will not
have any server side state even with
jdk.tls.server.enableSessionTicketExtension=false, and that the
property will only change the stateless session ticket contents in
some unspecified way. I think we should use different wording here.
Regards,
Daniel

?r., 24 mar 2021 o 12:38  napisa?(a):
>
> Concerning the question:
>
> >Also the note about TLS 1.3 in the same section isn't entirely clear
> to me. What does it mean when the docs say "the contents of stateless
> >tickets, in particular, the contents of a NewSessionTicket message,
> >depend on the value of jdk.tls.server.enableSessionTicketExtension"?
>
> In TLS 1.3, if stateless session resumption is in use (i.e.
> jdk.tls.server.enableSessionTicketExtension=true) the NewSessionTicket message
> includes all session information (in encrypted format). If session resumption is
> stateful (i.e. jdk.tls.server.enableSessionTicketExtension=false), the
> NewSessionTicket message just contains a key that is used by the server during session
> resumption in order to access the session information from its session cache.
>
> >why should I care?
>
> The point is: In TLS 1.3 the resumption mode (stateful/stateless) can be configured
> by the property jdk.tls.server.enableSessionTicketExtension (though there is no
> SessionTicketExtension extension in TLS 1.3). But in JDK 14 or later,
> there is usually no need to change the default (=stateless).
>
> Regards,
>
> Ralph
>
>
>
> Gesendet: Freitag, 05. Februar 2021 um 08:42 Uhr
> Von: "Daniel Jeli?ski" 
> An: security-dev at openjdk.java.net
> Betreff: JSSE reference guide issue
> Hi all,
> What's the right spot to report documentation issues?
>
> I've been reading the JSSE reference guide and noticed that in section
> "Resuming Session Without Server-Side State"
> (https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810)
> it says "This feature is not enabled by default", which appears to be
> a leftover from Java 13.
>
> Also the note about TLS 1.3 in the same section isn't entirely clear
> to me. What does it mean when the docs say "the contents of stateless
> tickets, in particular, the contents of a NewSessionTicket message,
> depend on the value of jdk.tls.server.enableSessionTicketExtension"?
> How exactly does the contents change and why should I care?
> Regards,
> Daniel

From xuelei at openjdk.java.net  Wed Mar 24 16:33:39 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 24 Mar 2021 16:33:39 GMT
Subject: RFR: 8258753: StartTlsResponse.close() hangs due to
 synchronization issues
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Mar 2021 07:07:56 GMT, Prajwal Kumaraswamy  wrote:

> **Scenario:**
> 1. Issue occurs in a muti-threaded environment where SSL socket read() and close() are invoked in parallel.
> 2. SSL socket read is already called.
> 2. close() calls waitForCloseNotify() -> decode() ->....-> socketRead0() to read the close_notify acknowledgment.
> 3. Since there is no synchronization between these read operations, the thread which had already invoked read(), reads the close_notify acknowledgment.
> 4. The thread (which calls waitForCloseNotify() -> read() ) waits indefinitely in socketRead0() and hangs.
> 5. Reproduced and tested the fix against a real time MS AD LDAP server.

Marked as reviewed by xuelei (Reviewer).

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

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

From raell at web.de  Wed Mar 24 17:07:58 2021
From: raell at web.de (raell at web.de)
Date: Wed, 24 Mar 2021 18:07:58 +0100
Subject: JSSE reference guide issue
References: 
 
 
Message-ID: 

Hi Daniel,?

I agree that the doc is a bit misleading. Maybe, the TLS 1.2 part can be put into the note:?

----------------------
jdk.tls.server.enableSessionTicketExtension: Enables a server to use stateless session?
tickets. A value of true (default value) enables the use of stateless session tickets,?
false does not.

Note: In TLS 1.2 stateless session tickets will be used only if they are supported by the client.
---------------------

Regards?

Ralph?
?
?

Gesendet:?Mittwoch, 24. M?rz 2021 um 16:29 Uhr
Von:?"Daniel Jeli?ski" 
An:?raell at web.de
Cc:?security-dev at openjdk.java.net
Betreff:?Re: JSSE reference guide issue
Thanks Ralph. I figured that out already. However, the docs are
(still) a bit misleading here. Let me quote:

> For TLS 1.3, stateless tickets use the existing PSK resumption extension. Therefore, session resumption **without server-site** state doesn't require these two properties. However, the contents of **stateless** tickets, in particular, the contents of a NewSessionTicket message, depend on the value of jdk.tls.server.enableSessionTicketExtension.
(emphasis mine)

The server can use PSK for either stateful or stateless tickets, and
the choice is solely at the server's discretion, the client has no
choice here. However, the paragraph above suggests that we will not
have any server side state even with
jdk.tls.server.enableSessionTicketExtension=false, and that the
property will only change the stateless session ticket contents in
some unspecified way. I think we should use different wording here.
Regards,
Daniel

?r., 24 mar 2021 o 12:38  napisa?(a):
>
> Concerning the question:
>
> >Also the note about TLS 1.3 in the same section isn't entirely clear
> to me. What does it mean when the docs say "the contents of stateless
> >tickets, in particular, the contents of a NewSessionTicket message,
> >depend on the value of jdk.tls.server.enableSessionTicketExtension"?
>
> In TLS 1.3, if stateless session resumption is in use (i.e.
> jdk.tls.server.enableSessionTicketExtension=true) the NewSessionTicket message
> includes all session information (in encrypted format). If session resumption is
> stateful (i.e. jdk.tls.server.enableSessionTicketExtension=false), the
> NewSessionTicket message just contains a key that is used by the server during session
> resumption in order to access the session information from its session cache.
>
> >why should I care?
>
> The point is: In TLS 1.3 the resumption mode (stateful/stateless) can be configured
> by the property jdk.tls.server.enableSessionTicketExtension (though there is no
> SessionTicketExtension extension in TLS 1.3). But in JDK 14 or later,
> there is usually no need to change the default (=stateless).
>
> Regards,
>
> Ralph
>
>
>
> Gesendet: Freitag, 05. Februar 2021 um 08:42 Uhr
> Von: "Daniel Jeli?ski" 
> An: security-dev at openjdk.java.net
> Betreff: JSSE reference guide issue
> Hi all,
> What's the right spot to report documentation issues?
>
> I've been reading the JSSE reference guide and noticed that in section
> "Resuming Session Without Server-Side State"
> (https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810)
> it says "This feature is not enabled by default", which appears to be
> a leftover from Java 13.
>
> Also the note about TLS 1.3 in the same section isn't entirely clear
> to me. What does it mean when the docs say "the contents of stateless
> tickets, in particular, the contents of a NewSessionTicket message,
> depend on the value of jdk.tls.server.enableSessionTicketExtension"?
> How exactly does the contents change and why should I care?
> Regards,
> Daniel

From jnimeh at openjdk.java.net  Wed Mar 24 21:26:41 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 24 Mar 2021 21:26:41 GMT
Subject: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS
 keys
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 19 Mar 2021 14:46:38 GMT, Greg Rubin  wrote:

>> I am also not comfortable adding this feature to the JDK, especially since every build of the JDK would by default have this feature enabled. Logging sensitive information to log files is not good security practice (there are many references I could cite). I also think it would be too easy to accidentally leave the system property enabled or forget to remove the file.
>
> I think that there might be some confusion around the sensitivity of the data being logged. The security impact of this data is almost identical to passing `-Djavax.net.debug=plaintext,packet` to the JVM. This existing setting logs all plaintext (as well as wire-data) to STDERR. The new feature I'm proposing just lets a second application decrypt the wire-data to access the plaintext, which results in the same level of exposed data. (As an improvement over the existing feature, it outputs the data in a standardized format so that it is easier to analyze rather than being in a Java-specific format and co-mingled with all other STDERR output.)
> 
> Similar to the existing feature, the data logged only impacts the exact connections that it is enabled for. (These are ephemeral session-specific secrets).
> 
> I hope that this helps to ease some concerns and help explain why this exact feature is present in so many existing applications (including OpenSSL, BoringSSL, WolfSSL, s2n, Mozilla, and Chrome, among others).  If you would like to try it with your current Chrome browser, just add ` --ssl-key-log-file=/path/to/chrome_keys.txt` to the command-line. For Firefox, I believe you need to set the `SSLKEYLOGFILE` environment variable to the name of the log-file.

I agree with Bernd, an API gives us some more flexibility.  I like the functionality provided by a key logging feature, but an API-based approach is more appropriate for the platform, and it more closely resembles what OpenSSL and GnuTLS are doing with callback registration.

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

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

From weijun at openjdk.java.net  Wed Mar 24 21:43:07 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 24 Mar 2021 21:43:07 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params
Message-ID: 

This enhancement contains the following code changes:

1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one.
2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions.
3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec`
4. Tests

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

Commit messages:
 - 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params

Changes: https://git.openjdk.java.net/jdk/pull/3181/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241306
  Stats: 1310 lines in 11 files changed: 1159 ins; 105 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3181.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3181/head:pull/3181

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

From weijun at openjdk.java.net  Wed Mar 24 21:43:07 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 24 Mar 2021 21:43:07 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params
In-Reply-To: 
References: 
Message-ID: 

On Wed, 24 Mar 2021 21:36:21 GMT, Weijun Wang  wrote:

> This enhancement contains the following code changes:
> 
> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one.
> 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions.
> 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec`
> 4. Tests

src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java line 588:

> 586: 
> 587:         public enum DigestAlgorithm {
> 588: //            SHA1("SHA-1", DigestMethod.SHA1, 20),

Do we want to support "SHA-1"? It's considered weak and not the default but the RFC seems to have not disabled it at all.

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

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

From valeriep at openjdk.java.net  Wed Mar 24 22:05:45 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Mar 2021 22:05:45 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 Mar 2021 03:25:02 GMT, Ziyi Luo  wrote:

>> This is a P2 regression introduced by JDK-8254717.
>> 
>> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
>> 
>> X-axis: type of `keySpec`
>> Y-axis: type of `key`
>> 
>> Before JDK-8254717:
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
>> 
>> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
>> 
>> This commit fixes the regression.
>> 
>> 
>> ### Tests
>> 
>> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
>> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed
>
> Ziyi Luo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Refactor P11RSAKeyFactory and improve tests

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java line 285:

> 283:         // If the key is both extractable and not sensitive, then when it was converted into a P11Key
> 284:         // it was also converted into subclass of RSAPrivateKey which encapsulates all of the logic
> 285:         // necessary to retrive the attributes we need. This sub-class will also cache these attributes

nit: retrieve

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

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

From valeriep at openjdk.java.net  Wed Mar 24 22:20:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Mar 2021 22:20:40 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v6]
In-Reply-To: 
References: 
 
Message-ID: <6jlNAQQsYuo6_ZolrmZghu6fG9Uepq1gX4Q5w7gRxjE=.fdc2f5de-6666-4a8b-8695-25fc43aea64f@github.com>

On Wed, 24 Mar 2021 03:25:02 GMT, Ziyi Luo  wrote:

>> This is a P2 regression introduced by JDK-8254717.
>> 
>> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
>> 
>> X-axis: type of `keySpec`
>> Y-axis: type of `key`
>> 
>> Before JDK-8254717:
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
>> 
>> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
>> 
>> This commit fixes the regression.
>> 
>> 
>> ### Tests
>> 
>> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
>> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed
>
> Ziyi Luo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Refactor P11RSAKeyFactory and improve tests

test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java line 91:

> 89:             if (testingSensitiveKeys) {
> 90:                 // Expected exception so swallow it
> 91:                 ex.printStackTrace();

Add a System.out.println() to clarify that this exception stack trace is expected?

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

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

From valeriep at openjdk.java.net  Wed Mar 24 22:31:41 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Mar 2021 22:31:41 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 Mar 2021 03:25:02 GMT, Ziyi Luo  wrote:

>> This is a P2 regression introduced by JDK-8254717.
>> 
>> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
>> 
>> X-axis: type of `keySpec`
>> Y-axis: type of `key`
>> 
>> Before JDK-8254717:
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
>> 
>> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
>> 
>> This commit fixes the regression.
>> 
>> 
>> ### Tests
>> 
>> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
>> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed
>
> Ziyi Luo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Refactor P11RSAKeyFactory and improve tests

test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java line 36:

> 34:  * @test
> 35:  * @bug 8263404
> 36:  * @summary RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec

It'd be clearer to re-word the summary to clear things up, e.g. return RSAPrivateCrtKeySpec for CRT Keys even when RSAPrivateKeySpec is specified for KeyFactory.getKeySpec() calls.

test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java line 38:

> 36:  * @summary RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec
> 37:  * @summary Also checks to ensure that sensitive RSA keys are correctly not exposed
> 38:  * @author Greg Rubin, Ziyi Luo

Latest policy is to not include @author tag.

test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java line 87:

> 85:             if (!(spec instanceof RSAPrivateCrtKeySpec)) {
> 86:                 throw new Exception("Spec should be an instance of RSAPrivateCrtKeySpec");
> 87:             }            

Note that SunPKCS11 provider does not really generate the keys unlike SunRsaSign provider, thus for correctness, you should check it's a CRT key before you impose the instanceof RSAPrivateCrtKeySpec check.

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

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

From github.com+829871+salusasecondus at openjdk.java.net  Wed Mar 24 22:31:42 2021
From: github.com+829871+salusasecondus at openjdk.java.net (Greg Rubin)
Date: Wed, 24 Mar 2021 22:31:42 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v6]
In-Reply-To: <6jlNAQQsYuo6_ZolrmZghu6fG9Uepq1gX4Q5w7gRxjE=.fdc2f5de-6666-4a8b-8695-25fc43aea64f@github.com>
References: 
 
 <6jlNAQQsYuo6_ZolrmZghu6fG9Uepq1gX4Q5w7gRxjE=.fdc2f5de-6666-4a8b-8695-25fc43aea64f@github.com>
Message-ID: <1QCC1EbP0GXKT4zFs_uP0GWiWz0gNsW1I-hiqVtPzlM=.be53f407-a52f-4969-b74e-16a951913826@github.com>

On Wed, 24 Mar 2021 22:17:56 GMT, Valerie Peng  wrote:

>> Ziyi Luo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailing whitespace
>>  - Refactor P11RSAKeyFactory and improve tests
>
> test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java line 91:
> 
>> 89:             if (testingSensitiveKeys) {
>> 90:                 // Expected exception so swallow it
>> 91:                 ex.printStackTrace();
> 
> Add a System.out.println() to clarify that this exception stack trace is expected?

Putting it in `System.err.println()` so that it goes to the same output as the stack trace.

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

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

From valeriep at openjdk.java.net  Wed Mar 24 22:39:42 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Mar 2021 22:39:42 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

On Tue, 23 Mar 2021 01:01:14 GMT, Valerie Peng  wrote:

>> P11PrivateKey is private so we cannot check that. Our options to figure out if something is sensitive are:
>> 1. See if it doesn't implement `RSAPrivateKey` (this yields the prior snippet with `implGetSoftwareFactory()`)
>> 2. Try to access the attributes directly from the token (this yields the current solution which we're modifying)
>> 3. Check the value of `p11Key.extractable` (which is package-private and thus visible)
>> 
>> The smallest change would be to keep our strategy as 2. While I like it the least (my favorite is number 1) it has the smallest risk of changing some undocumented behavior on a PKCS#11 device that we're unfamiliar with (and not testing because we may not have the hardware costing tens of thousands of dollars). Option 3 somewhat spits the difference between 1 and 2.
>
> Or, how about changing the scope of P11PrivateKey/P11RSAPrivateKey/P11RSAPrivateNonCRTKey to pkg private? This way we can take advantage of the info implied by the type of class and avoid the potential double failure of querying the attributes.

Rest of changes look good. Thanks for the update.

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

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

From valeriep at openjdk.java.net  Wed Mar 24 22:39:43 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Mar 2021 22:39:43 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 Mar 2021 03:25:02 GMT, Ziyi Luo  wrote:

>> This is a P2 regression introduced by JDK-8254717.
>> 
>> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
>> 
>> X-axis: type of `keySpec`
>> Y-axis: type of `key`
>> 
>> Before JDK-8254717:
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
>> 
>> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
>> 
>> This commit fixes the regression.
>> 
>> 
>> ### Tests
>> 
>> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
>> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed
>
> Ziyi Luo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Refactor P11RSAKeyFactory and improve tests

test/jdk/sun/security/pkcs11/nss/p11-nss-sensitive.txt line 32:

> 30:   CKM_ECDSA_SHA3_384
> 31:   CKM_ECDSA_SHA3_512
> 32: }

I assume this is to avoid using this special provider for non-RSA impls? Add a comment?

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

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

From github.com+829871+salusasecondus at openjdk.java.net  Wed Mar 24 22:39:44 2021
From: github.com+829871+salusasecondus at openjdk.java.net (Greg Rubin)
Date: Wed, 24 Mar 2021 22:39:44 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 24 Mar 2021 22:35:13 GMT, Valerie Peng  wrote:

>> Ziyi Luo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailing whitespace
>>  - Refactor P11RSAKeyFactory and improve tests
>
> test/jdk/sun/security/pkcs11/nss/p11-nss-sensitive.txt line 32:
> 
>> 30:   CKM_ECDSA_SHA3_384
>> 31:   CKM_ECDSA_SHA3_512
>> 32: }
> 
> I assume this is to avoid using this special provider for non-RSA impls? Add a comment?

This file is copy/pasted from `p11-nss.txt` with only the sensitive modifications at the end. I do not know why those disabled mechanisms are present in the source file.

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

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

From valeriep at openjdk.java.net  Wed Mar 24 22:39:44 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 24 Mar 2021 22:39:44 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v6]
In-Reply-To: <1QCC1EbP0GXKT4zFs_uP0GWiWz0gNsW1I-hiqVtPzlM=.be53f407-a52f-4969-b74e-16a951913826@github.com>
References: 
 
 <6jlNAQQsYuo6_ZolrmZghu6fG9Uepq1gX4Q5w7gRxjE=.fdc2f5de-6666-4a8b-8695-25fc43aea64f@github.com>
 <1QCC1EbP0GXKT4zFs_uP0GWiWz0gNsW1I-hiqVtPzlM=.be53f407-a52f-4969-b74e-16a951913826@github.com>
Message-ID: 

On Wed, 24 Mar 2021 22:24:45 GMT, Greg Rubin  wrote:

>> test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java line 91:
>> 
>>> 89:             if (testingSensitiveKeys) {
>>> 90:                 // Expected exception so swallow it
>>> 91:                 ex.printStackTrace();
>> 
>> Add a System.out.println() to clarify that this exception stack trace is expected?
>
> Putting it in `System.err.println()` so that it goes to the same output as the stack trace.

Sure, you know what I mean.

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

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

From luoziyi at openjdk.java.net  Wed Mar 24 22:51:09 2021
From: luoziyi at openjdk.java.net (Ziyi Luo)
Date: Wed, 24 Mar 2021 22:51:09 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v7]
In-Reply-To: 
References: 
Message-ID: 

> This is a P2 regression introduced by JDK-8254717.
> 
> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
> 
> X-axis: type of `keySpec`
> Y-axis: type of `key`
> 
> Before JDK-8254717:
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
> 
> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
> 
> This commit fixes the regression.
> 
> 
> ### Tests
> 
> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed

Ziyi Luo has updated the pull request incrementally with one additional commit since the last revision:

  Addressing Valerie's feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2949/files
  - new: https://git.openjdk.java.net/jdk/pull/2949/files/2594ef2b..4ec6ff39

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

  Stats: 28 lines in 3 files changed: 18 ins; 7 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2949.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2949/head:pull/2949

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

From valeriep at openjdk.java.net  Thu Mar 25 01:50:44 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Mar 2021 01:50:44 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 Mar 2021 18:39:27 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 41:
> 
>> 39:  * and represents AES cipher in KW mode.
>> 40:  */
>> 41: class AESKeyWrap extends FeedbackCipher {
> 
> I see lots of unsupported operations and `encrypt/decryptFinal` ignores their output parameters. Should we be extending `FeedbackCipher` if so much doesn't seem to quite fit?

I chose to extend FeedbackCipher since we are supporting KW and KWP as cipher modes and given that FeedbackCipher represents "a block cipher in one of its modes", it seems a natural fit. As for the various unsupported operations, those methods aren't currently used and instead of a no-op, I chose to throw UnsupportedOperationException to prevent future accidental use.

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

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

From valeriep at openjdk.java.net  Thu Mar 25 01:56:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Mar 2021 01:56:40 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <6lk4kE3UnIeeoczHFhh92jvSBhP11y5PdQhm4WGK9Sg=.520167ea-a36c-4d64-9056-cd82038116b9@github.com>

On Tue, 23 Mar 2021 18:41:26 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 155:
> 
>> 153:                 " be at least 16 bytes and multiples of 8");
>> 154:         }
>> 155:         // assert ptOfs == 0; ct == pt; ctOfs == 0;
> 
> Is this a missing code assertion?

Hmm, there are some inconsistencies in how the variables are named. I will remove this comment and update the method javadoc accordingly, i.e. ptOfs, ct, ctOfs have all been renamed to dummyN.

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

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

From valeriep at openjdk.java.net  Thu Mar 25 02:12:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Mar 2021 02:12:40 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 Mar 2021 19:56:40 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 69:
> 
>> 67:         if (!Arrays.equals(ivAndLen, 0, ICV2.length, icv, 0, ICV2.length)) {
>> 68:             throw new IllegalBlockSizeException("Integrity check failed");
>> 69:         }
> 
> While I cannot find any public discussion of this, I'm always uncomfortable checking the plaintext (prior to authentication) against a known value in non-constant time. I'm worried that this (and the equivalent in the unpadded version) might be a problem in the future.

This is just IV and length, not plaintext. So, I didn't use the constant time array check. I can switch to the constant time version, it's trivial.

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

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

From valeriep at openjdk.java.net  Thu Mar 25 02:20:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Mar 2021 02:20:40 GMT
Subject: RFR: 8248268: Support KWP in addition to KW
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Mar 2021 18:48:47 GMT, Valerie Peng  wrote:

>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>> 
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
>> 
>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>> 
>> Thanks,
>> Valerie
>
> Ping, anyone has time to review this?

> 
> 
> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at openjdk.java.net):_
> 
> On 3/23/2021 4:15 PM, Greg Rubin wrote:
> 
> > > 177:         System.out.println("Testing " + ALGO);
> > > 178:         c = Cipher.getInstance(ALGO, "SunJCE");
> > > 179:         for (int i = 0; i < MAX_KWP_PAD_LEN; i++) {
> > > I see that here (and earlier) we do test all padding lengths. I'd still like some KATs generated by a known good implementation to ensure that we are not just compatible with ourselves.
> 
> http://csrc.nist.gov/groups/STM/cavp/documents/mac/kwtestvectors.zip has
> the NIST test vectors.? See
> https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/mac/KWVS.pdf
> for details.
> 
> Mike
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 

Sure, I will add some, thanks Mike for the pointers.

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

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

From valeriep at openjdk.java.net  Thu Mar 25 02:20:41 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Mar 2021 02:20:41 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 Mar 2021 19:18:14 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java line 179:
> 
>> 177:         System.out.println("Testing " + ALGO);
>> 178:         c = Cipher.getInstance(ALGO, "SunJCE");
>> 179:         for (int i = 0; i < MAX_KWP_PAD_LEN; i++) {
> 
> I see that here (and earlier) we do test all padding lengths. I'd still like some KATs generated by a known good implementation to ensure that we are not just compatible with ourselves.

Sure, I can add some from the NIST zip which Michael StJohns mentioned to the NISTWrapKAT.java.

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

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

From pkumaraswamy at openjdk.java.net  Thu Mar 25 03:38:41 2021
From: pkumaraswamy at openjdk.java.net (Prajwal Kumaraswamy)
Date: Thu, 25 Mar 2021 03:38:41 GMT
Subject: Integrated: 8258753: StartTlsResponse.close() hangs due to
 synchronization issues
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Mar 2021 07:07:56 GMT, Prajwal Kumaraswamy  wrote:

> **Scenario:**
> 1. Issue occurs in a muti-threaded environment where SSL socket read() and close() are invoked in parallel.
> 2. SSL socket read is already called.
> 2. close() calls waitForCloseNotify() -> decode() ->....-> socketRead0() to read the close_notify acknowledgment.
> 3. Since there is no synchronization between these read operations, the thread which had already invoked read(), reads the close_notify acknowledgment.
> 4. The thread (which calls waitForCloseNotify() -> read() ) waits indefinitely in socketRead0() and hangs.
> 5. Reproduced and tested the fix against a real time MS AD LDAP server.

This pull request has now been integrated.

Changeset: 41555332
Author:    Prajwal Kumaraswamy 
Committer: Xue-Lei Andrew Fan 
URL:       https://git.openjdk.java.net/jdk/commit/41555332
Stats:     17 lines in 1 file changed: 8 ins; 2 del; 7 mod

8258753: StartTlsResponse.close() hangs due to synchronization issues

Reviewed-by: xuelei

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

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

From xuelei at openjdk.java.net  Thu Mar 25 03:40:40 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 25 Mar 2021 03:40:40 GMT
Subject: RFR: 8263743: redundant lock in SSLSocketImpl
In-Reply-To: <8ZKiO4E1g_n5TZvpxwine_ylN96sCa30zpWsruajgxE=.ad78c80d-c9ee-4f60-815c-a891e32abecf@github.com>
References: <8ZKiO4E1g_n5TZvpxwine_ylN96sCa30zpWsruajgxE=.ad78c80d-c9ee-4f60-815c-a891e32abecf@github.com>
Message-ID: 

On Wed, 17 Mar 2021 17:23:03 GMT, Xue-Lei Andrew Fan  wrote:

> Remove redundant lock in SSLSocketImpl.
> 
> In the SSLSocketImpl, there is a socket level lock while reading application data (see readApplicationRecord). 
> 
>                 socketLock.lock(); 
>                 try { 
>                     plainText = decode(buffer); 
>                 } finally { 
>                     socketLock.unlock(); 
>                 } 
> If an application data read is in progress, other calling to SSLSocket APIs (for example getUseClientMode() in a handshake complete listener) could be blocked if socket level locks are used. 
> 
> No new regression test.  Simple fix, hard to trigger the deadlock.

ping ...

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

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

From jnimeh at openjdk.java.net  Thu Mar 25 04:58:37 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 25 Mar 2021 04:58:37 GMT
Subject: RFR: 8263743: redundant lock in SSLSocketImpl
In-Reply-To: <8ZKiO4E1g_n5TZvpxwine_ylN96sCa30zpWsruajgxE=.ad78c80d-c9ee-4f60-815c-a891e32abecf@github.com>
References: <8ZKiO4E1g_n5TZvpxwine_ylN96sCa30zpWsruajgxE=.ad78c80d-c9ee-4f60-815c-a891e32abecf@github.com>
Message-ID: 

On Wed, 17 Mar 2021 17:23:03 GMT, Xue-Lei Andrew Fan  wrote:

> Remove redundant lock in SSLSocketImpl.
> 
> In the SSLSocketImpl, there is a socket level lock while reading application data (see readApplicationRecord). 
> 
>                 socketLock.lock(); 
>                 try { 
>                     plainText = decode(buffer); 
>                 } finally { 
>                     socketLock.unlock(); 
>                 } 
> If an application data read is in progress, other calling to SSLSocket APIs (for example getUseClientMode() in a handshake complete listener) could be blocked if socket level locks are used. 
> 
> No new regression test.  Simple fix, hard to trigger the deadlock.

After reading over the description in the bug I think this looks fine.

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

Marked as reviewed by jnimeh (Reviewer).

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

From xuelei at openjdk.java.net  Thu Mar 25 05:20:39 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 25 Mar 2021 05:20:39 GMT
Subject: Integrated: 8263743: redundant lock in SSLSocketImpl
In-Reply-To: <8ZKiO4E1g_n5TZvpxwine_ylN96sCa30zpWsruajgxE=.ad78c80d-c9ee-4f60-815c-a891e32abecf@github.com>
References: <8ZKiO4E1g_n5TZvpxwine_ylN96sCa30zpWsruajgxE=.ad78c80d-c9ee-4f60-815c-a891e32abecf@github.com>
Message-ID: 

On Wed, 17 Mar 2021 17:23:03 GMT, Xue-Lei Andrew Fan  wrote:

> Remove redundant lock in SSLSocketImpl.
> 
> In the SSLSocketImpl, there is a socket level lock while reading application data (see readApplicationRecord). 
> 
>                 socketLock.lock(); 
>                 try { 
>                     plainText = decode(buffer); 
>                 } finally { 
>                     socketLock.unlock(); 
>                 } 
> If an application data read is in progress, other calling to SSLSocket APIs (for example getUseClientMode() in a handshake complete listener) could be blocked if socket level locks are used. 
> 
> No new regression test.  Simple fix, hard to trigger the deadlock.

This pull request has now been integrated.

Changeset: a678a38d
Author:    Xue-Lei Andrew Fan 
URL:       https://git.openjdk.java.net/jdk/commit/a678a38d
Stats:     7 lines in 1 file changed: 0 ins; 6 del; 1 mod

8263743: redundant lock in SSLSocketImpl

Reviewed-by: jnimeh

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

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

From jlaskey at openjdk.java.net  Thu Mar 25 17:13:51 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 25 Mar 2021 17:13:51 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v36]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  CSR review updates

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/22ea21d2..be9536ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=35
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=34-35

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

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

From akozlov at openjdk.java.net  Thu Mar 25 18:14:06 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:06 GMT
Subject: Integrated: 8253795: Implementation of JEP 391: macOS/AArch64 Port
In-Reply-To: 
References: 
Message-ID: 

On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov  wrote:

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

This pull request has now been integrated.

Changeset: dbc9e4b5
Author:    Anton Kozlov 
Committer: Vladimir Kempik 
URL:       https://git.openjdk.java.net/jdk/commit/dbc9e4b5
Stats:     2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod

8253795: Implementation of JEP 391: macOS/AArch64 Port
8253816: Support macOS W^X
8253817: Support macOS Aarch64 ABI in Interpreter
8253818: Support macOS Aarch64 ABI for compiled wrappers
8253819: Implement os/cpu for macOS/AArch64
8253839: Update tests and JDK code for macOS/Aarch64
8254941: Implement Serviceability Agent for macOS/AArch64
8255776: Change build system for macOS/AArch64
8262903: [macos_aarch64] Thread::current() called on detached thread

Co-authored-by: Vladimir Kempik 
Co-authored-by: Bernhard Urban-Forster 
Co-authored-by: Ludovic Henry 
Co-authored-by: Monica Beckwith 
Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry

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

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

From akozlov at openjdk.java.net  Thu Mar 25 18:14:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:03 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v30]
In-Reply-To: 
References: 
Message-ID: 

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 117 commits:

 - JDK-8261397: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Merge branch 'master' into jdk-macos
 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - ... and 107 more: https://git.openjdk.java.net/jdk/compare/b006f22f...d3629967

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=29
  Stats: 2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From akozlov at openjdk.java.net  Thu Mar 25 18:14:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:03 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 23 Mar 2021 16:33:50 GMT, Andrew Haley  wrote:

>> Marked as reviewed by luhenry (Author).
>
>> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
>> > > 
>> > > 
>> > > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
>> > 
>> > 
>> > @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)
>> 
>> Thanks, @theRealAph, and @VladimirKempik . We are on it!
> 
> It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

The JEP was targeted to JDK17. So I propose to integrate this. 

Thank you all for the reviews, suggestions, discussions, and support!

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

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

From ascarpino at openjdk.java.net  Thu Mar 25 19:23:30 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 25 Mar 2021 19:23:30 GMT
Subject: Integrated: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey
 impl and revised exception handling
In-Reply-To: 
References: 
Message-ID: 

On Sat, 20 Feb 2021 04:25:50 GMT, Anthony Scarpino  wrote:

> Hi,
> 
> I need a code review of this change to ECDH.  It is a combination of fixing the implementation to not only accept ECPrivateKeyImpl along with a fix to the exception handling.  They started as two fixes, but with the exception handling the underlying code changed significantly that made the ECPrivateKey change in a different place.  The new exception handling is a result of no longer having the native library.  Many of the checks waited until generateSecret() to send the keys to the native library. Now that native is gone, checks can happen when keys are provided to the methods and proper exceptions can be thrown instead of wrapping everything as a ProviderException
> 
> thanks,
> 
> Tony

This pull request has now been integrated.

Changeset: 374272fd
Author:    Anthony Scarpino 
URL:       https://git.openjdk.java.net/jdk/commit/374272fd
Stats:     203 lines in 2 files changed: 137 ins; 32 del; 34 mod

8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling

Reviewed-by: jnimeh

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

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

From sean.mullan at oracle.com  Thu Mar 25 20:05:57 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 25 Mar 2021 16:05:57 -0400
Subject: JSSE reference guide issue
In-Reply-To: 
References: 
 
Message-ID: <1c5a3aa2-d137-8c96-0679-89dc62a2ec5b@oracle.com>

 > I've been reading the JSSE reference guide and noticed that in section
 > "Resuming Session Without Server-Side State"
 > 
(https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810)
 > it says "This feature is not enabled by default", which appears to be
 > a leftover from Java 13.

That was fixed in the JDK 16 docs:

https://docs.oracle.com/en/java/javase/16/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810

I have forwarded your other suggestions for improvements to our docs writer.

Thanks,
Sean

On 3/24/21 7:38 AM, raell at web.de wrote:
> Concerning the question:
> 
>> Also the note about TLS 1.3 in the same section isn't entirely clear
> to me. What does it mean when the docs say "the contents of stateless
>> tickets, in particular, the contents of a NewSessionTicket message,
>> depend on the value of jdk.tls.server.enableSessionTicketExtension"?
> 
> In TLS 1.3, if stateless session resumption is in use (i.e.
> jdk.tls.server.enableSessionTicketExtension=true) the NewSessionTicket message
> includes all session information (in encrypted format). If session resumption is
> stateful (i.e. jdk.tls.server.enableSessionTicketExtension=false), the
> NewSessionTicket message just contains a key that is used by the server during session
> resumption in order to access the session information from its session cache.
> 
>> why should I care?
> 
> The point is: In TLS 1.3 the resumption mode (stateful/stateless) can be configured
> by the property jdk.tls.server.enableSessionTicketExtension (though there is no
> SessionTicketExtension extension in TLS 1.3). But in JDK 14 or later,
> there is usually no need to change the default (=stateless).
>   
> Regards,
> 
> Ralph
>   
>   
> 
> Gesendet:?Freitag, 05. Februar 2021 um 08:42 Uhr
> Von:?"Daniel Jeli?ski" 
> An:?security-dev at openjdk.java.net
> Betreff:?JSSE reference guide issue
> Hi all,
> What's the right spot to report documentation issues?
> 
> I've been reading the JSSE reference guide and noticed that in section
> "Resuming Session Without Server-Side State"
> (https://docs.oracle.com/en/java/javase/15/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-64D7EAF6-D2EE-4719-8616-25E2829CF810)
> it says "This feature is not enabled by default", which appears to be
> a leftover from Java 13.
> 
> Also the note about TLS 1.3 in the same section isn't entirely clear
> to me. What does it mean when the docs say "the contents of stateless
> tickets, in particular, the contents of a NewSessionTicket message,
> depend on the value of jdk.tls.server.enableSessionTicketExtension"?
> How exactly does the contents change and why should I care?
> Regards,
> Daniel
> 

From rriggs at openjdk.java.net  Thu Mar 25 20:15:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 25 Mar 2021 20:15:35 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
Message-ID: 

A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.

These  APIs were added early in JDK 17 and are being updated before GA.
This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.

   public boolean isHexDigit(int);
   public int fromHexDigit(int);
   public int fromHexDigits(java.lang.CharSequence);
   public int fromHexDigits(java.lang.CharSequence, int, int);
   public long fromHexDigitsToLong(java.lang.CharSequence);
   public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

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

Commit messages:
 - 8263754: HexFormat 'fromHex' methods should be static

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

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

From valeriep at openjdk.java.net  Thu Mar 25 20:37:27 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Mar 2021 20:37:27 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <3MZZQr2lpI09NsFOAVdudxaUuj5v3tj4udhEzD5cDoU=.76a18ed6-b003-4461-8bd3-985ad8b70437@github.com>

On Tue, 23 Mar 2021 19:57:44 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 246:
> 
>> 244:         int outLen = validateIV(ivAndLen, this.iv);
>> 245:         // check padding bytes
>> 246:         int padLen = ctLen - outLen;
> 
> Can we add an explicit check that `0 <= padLen < SEMI_BLKSIZE`?

Sure, good idea.

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

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

From redestad at openjdk.java.net  Thu Mar 25 21:18:31 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 25 Mar 2021 21:18:31 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: 
References: 
Message-ID: 

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs  wrote:

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

I like the direction. There are a number of orphaned HexFormat instances that can be cleaned up. I might have missed a few. 

Do you intend to do the same thing with the toHexDigit methods?

src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 822:

> 820:         StringBuilder hexNumber = new StringBuilder();
> 821:         for (int i = 0; i < chars.length; i++) {
> 822:             if (HexFormat.isHexDigit(chars[i])) {

`hex` left unused.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4582:

> 4580:                             int pos = 0;
> 4581:                             for (char c: value.toCharArray()) {
> 4582:                                 if (!HexFormat.isHexDigit(c)) {

`hexFmt` created on line 4576 appears to be unused after this.

src/java.base/share/classes/sun/security/x509/AVA.java line 504:

> 502:         throws IOException {
> 503: 
> 504:         HexFormat hex = HexFormat.of();

`hex` left unused.

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

Changes requested by redestad (Reviewer).

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

From valeriep at openjdk.java.net  Thu Mar 25 21:47:27 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Mar 2021 21:47:27 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 Mar 2021 20:09:23 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 507:
> 
>> 505:             } else {
>> 506:                 outLen = cipher.encryptFinal(dataBuf, 0, dataIdx, null, -1);
>> 507:             }
> 
> Can we extract this shared logic (among the different versions of `engineDoFinal`) into a separate helper method so that the different `engineDoFinal` methods just need to handle their specific differences (such as returning `Arrays.copyOf(dataBuf, outLen)` or calling `System.arraycopy(dataBuf, 0, out, outOfs, outLen); return outLen;`).

Right, I agree. Will look into it.

> src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 660:
> 
>> 658:     @Override
>> 659:     protected byte[] engineWrap(Key key)
>> 660:             throws IllegalBlockSizeException, InvalidKeyException {
> 
> Is it okay that we can call `cipher.init(Cipher.ENCRYPT_MODE, ...)` and then use it with `cipher.wrap()`?
> 
> Also, can we simply delegate the heavy lifting to `engineDoFinal()` (or the new suggested helper method) rather than duplicating this logic here?

Right, I will add additional checking on the Cipher.XXX_MODE. Agree with you regarding reducing the code duplication.

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

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

From naoto at openjdk.java.net  Thu Mar 25 21:49:26 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 25 Mar 2021 21:49:26 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: 
References: 
Message-ID: 

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs  wrote:

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

Looks good (with the suggestions by Claes).

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

Marked as reviewed by naoto (Reviewer).

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

From rriggs at openjdk.java.net  Thu Mar 25 21:53:28 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 25 Mar 2021 21:53:28 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 25 Mar 2021 21:05:47 GMT, Claes Redestad  wrote:

>> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
>> 
>> These  APIs were added early in JDK 17 and are being updated before GA.
>> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
>> 
>>    public boolean isHexDigit(int);
>>    public int fromHexDigit(int);
>>    public int fromHexDigits(java.lang.CharSequence);
>>    public int fromHexDigits(java.lang.CharSequence, int, int);
>>    public long fromHexDigitsToLong(java.lang.CharSequence);
>>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4582:
> 
>> 4580:                             int pos = 0;
>> 4581:                             for (char c: value.toCharArray()) {
>> 4582:                                 if (!HexFormat.isHexDigit(c)) {
> 
> `hexFmt` created on line 4576 appears to be unused after this.

The toHexDigit methods need access to the uppercase/lowercase distinction.
So there is no plan to change them.
I'll amend to include the above and re-check for uncaught uses.

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

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

From mbalao at openjdk.java.net  Thu Mar 25 22:13:42 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Thu, 25 Mar 2021 22:13:42 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I'd like to propose a fix for JDK-8261355 [1].
> 
> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
> 
> No regressions observed in jdk/sun/security/pkcs11.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355

Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Avoid overriding buffered bytes with padding in the doFinal call.
 - Only do encryption block-size buffering for NSS
 - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

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

Changes: https://git.openjdk.java.net/jdk/pull/2510/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2510&range=01
  Stats: 245 lines in 2 files changed: 164 ins; 23 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2510.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2510/head:pull/2510

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

From mbalao at openjdk.java.net  Thu Mar 25 22:20:29 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Thu, 25 Mar 2021 22:20:29 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 2 Mar 2021 13:16:24 GMT, Valerie Peng  wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Avoid overriding buffered bytes with padding in the doFinal call.
>>  - Only do encryption block-size buffering for NSS
>>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 595:
> 
>> 593:                     // NSS throws up when called with data not in multiple
>> 594:                     // of blocks. Try to work around this by holding the
>> 595:                     // extra data in padBuffer.
> 
> Well, I am not sure if other PKCS#11 libraries are like NSS which requires input size to be multiple of blocks for every multi-part encryption/decryption calls. We are paying the cost of buffering non-blocksize data ourselves and the associated byte copying as a result. Oh-well.
> 
> With this change, you should also update the implDoFinal() impl which calls paddingObj.setPaddingBytes(byte[], int) for encryption and writes the padding bytes "after" the existing buffered bytes, i.e. padBufferLen. Otherwise, the existing buffered bytes may be overwritten w/ padding bytes and things will fail. The new regression test should cover this scenario also. It currently only tests the changes made to update() calls.

I've pushed a new proposal to limit the performance impact of Java-side buffering to the NSS library. This adds to the previous conditions: the operation has to be encryption and the mechanism must not have native padding. If we realize in the future that other libraries are affected as well, we can easily extend the scope.

In regards to the implDoFinal bug, well spotted! Fixed in this new proposal and the test has been enhanced to cover not only this case but also different padding sizes and different block numbers.

Branch rebased (today) to the latest master.

Look forward to your comments.

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

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

From redestad at openjdk.java.net  Thu Mar 25 22:49:26 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 25 Mar 2021 22:49:26 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: 
References: 
 
 
Message-ID: <9uIY69WYeuDY3CNtYqlCYe_axVevoxXNiCsEgTu0vBk=.68cb70dc-6ee8-4acc-a63e-f7e0a3486b26@github.com>

On Thu, 25 Mar 2021 21:50:46 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4582:
>> 
>>> 4580:                             int pos = 0;
>>> 4581:                             for (char c: value.toCharArray()) {
>>> 4582:                                 if (!HexFormat.isHexDigit(c)) {
>> 
>> `hexFmt` created on line 4576 appears to be unused after this.
>
> The toHexDigit methods need access to the uppercase/lowercase distinction.
> So there is no plan to change them.
> I'll amend to include the above and re-check for uncaught uses.

Hmm, I missed that unfortunate detail. It looks mis-matched to have `fromHex*` be static while `toHex*` variants aren't.

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

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

From valeriep at openjdk.java.net  Thu Mar 25 23:58:26 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 25 Mar 2021 23:58:26 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 Mar 2021 18:47:32 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 193:
> 
>> 191:         if (!Arrays.equals(ivOut, 0, ICV1.length, this.iv, 0, ICV1.length)) {
>> 192:             throw new IllegalBlockSizeException("Integrity check failed");
>> 193:         }
> 
> It feels like an odd asymmetry that we validate the IV upon decryption in `AESKeyWrap` but the IV is prepended in `KeyWrapCipher.writeIvSemiBlock`.  I'm worried that by separating this logic like this it is easier for us to get it wrong (or break it in the future).

Hmm, another alternative is to move this logic to the underlying key wrap impl, i.e. AESKeyWrap and AESKeyWrapPadded, and start saving data after the first 8-byte in KeyWrapCipher class.

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

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

From jlaskey at openjdk.java.net  Fri Mar 26 12:25:43 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 26 Mar 2021 12:25:43 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v37]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  CSR review revisions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/be9536ce..84cc93fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=36
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=35-36

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

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

From chegar at openjdk.java.net  Fri Mar 26 12:42:25 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 26 Mar 2021 12:42:25 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: 
References: 
Message-ID: 

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs  wrote:

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

Marked as reviewed by chegar (Reviewer).

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

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

From rriggs at openjdk.java.net  Fri Mar 26 14:39:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 26 Mar 2021 14:39:47 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static [v2]
In-Reply-To: 
References: 
Message-ID: 

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused HexFormat instances

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3205/files
  - new: https://git.openjdk.java.net/jdk/pull/3205/files/050495a9..042dc18b

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

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

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

From redestad at openjdk.java.net  Fri Mar 26 15:00:31 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 26 Mar 2021 15:00:31 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 26 Mar 2021 14:39:47 GMT, Roger Riggs  wrote:

>> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
>> 
>> These  APIs were added early in JDK 17 and are being updated before GA.
>> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
>> 
>>    public boolean isHexDigit(int);
>>    public int fromHexDigit(int);
>>    public int fromHexDigits(java.lang.CharSequence);
>>    public int fromHexDigits(java.lang.CharSequence, int, int);
>>    public long fromHexDigitsToLong(java.lang.CharSequence);
>>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused HexFormat instances

Marked as reviewed by redestad (Reviewer).

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

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

From fguallini at openjdk.java.net  Fri Mar 26 15:43:43 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Fri, 26 Mar 2021 15:43:43 GMT
Subject: RFR: 8264190: Harden TLS interop tests
Message-ID: 

Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate intermittent failures, this patch updates interop/BaseInteropTest.java in order to validate the server is alive and if not, retry to create a valid server.

In addition, Utilities::isSessionResumed implementation is now comparing equality of first and second session creation time to validate session resumption

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

Commit messages:
 - Harden TLS interop tests

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

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

From fguallini at openjdk.java.net  Fri Mar 26 17:20:44 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Fri, 26 Mar 2021 17:20:44 GMT
Subject: RFR: 8264190: Harden TLS interop tests [v2]
In-Reply-To: 
References: 
Message-ID: 

> Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate intermittent failures, this patch updates interop/BaseInteropTest.java in order to validate the server is alive and if not, retry to create a valid server.
> 
> In addition, Utilities::isSessionResumed implementation is now comparing equality of first and second session creation time to validate session resumption

Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

  no need to check if alive while iterating during accept

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3218/files
  - new: https://git.openjdk.java.net/jdk/pull/3218/files/e9b984b9..474f482d

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

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

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

From valeriep at openjdk.java.net  Fri Mar 26 17:49:32 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 26 Mar 2021 17:49:32 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 Mar 2021 22:51:09 GMT, Ziyi Luo  wrote:

>> This is a P2 regression introduced by JDK-8254717.
>> 
>> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
>> 
>> X-axis: type of `keySpec`
>> Y-axis: type of `key`
>> 
>> Before JDK-8254717:
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
>> 
>> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
>> 
>> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
>> |--|--|--|
>> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
>> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
>> 
>> This commit fixes the regression.
>> 
>> 
>> ### Tests
>> 
>> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
>> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed
>
> Ziyi Luo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing Valerie's feedback

Marked as reviewed by valeriep (Reviewer).

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

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

From luoziyi at openjdk.java.net  Fri Mar 26 17:55:27 2021
From: luoziyi at openjdk.java.net (Ziyi Luo)
Date: Fri, 26 Mar 2021 17:55:27 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 26 Mar 2021 17:46:18 GMT, Valerie Peng  wrote:

>> Ziyi Luo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing Valerie's feedback
>
> Marked as reviewed by valeriep (Reviewer).

@valeriepeng Thanks for the review. Do we need a second reviewer for this PR? Besides, are you willing to sponsor this?

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

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

From darcy at openjdk.java.net  Fri Mar 26 20:03:30 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 26 Mar 2021 20:03:30 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v37]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 26 Mar 2021 12:25:43 GMT, Jim Laskey  wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR review revisions

Marked as reviewed by darcy (Reviewer).

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

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

From valeriep at openjdk.java.net  Fri Mar 26 21:32:29 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 26 Mar 2021 21:32:29 GMT
Subject: RFR: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 26 Mar 2021 17:53:03 GMT, Ziyi Luo  wrote:

>> Marked as reviewed by valeriep (Reviewer).
>
> @valeriepeng Thanks for the review. Do we need a second reviewer for this PR? Besides, are you willing to sponsor this?

I can sponsor this. It looks like you need to do the "/integrate" comment first?

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

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

From valeriep at openjdk.java.net  Fri Mar 26 21:41:30 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 26 Mar 2021 21:41:30 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <7p102pL0ixct2UBM1EMXKvUpD4kom1csTdxldV7oq5g=.5457c9bb-c315-4294-8096-b5bb03933432@github.com>

On Tue, 23 Mar 2021 19:06:30 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java line 87:
> 
>> 85:      */
>> 86:     static final void W_INV(byte[] in, int inLen, byte[] ivOut,
>> 87:             SymmetricCipher cipher) {
> 
> The asymmetry between `W` not taking an IV but `W_INV` returning an IV also bothers me and seems to make this harder to use safely.

Ok, I can update to make W() handles the IV semiblock overwrite.

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

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

From valeriep at openjdk.java.net  Fri Mar 26 21:44:28 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 26 Mar 2021 21:44:28 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <_823lzTnc5DlGx0JvK2vf1QFitCIhJJOqCmkWqlKfxE=.84076ab1-608d-41c6-8910-5c918030715e@github.com>

On Tue, 23 Mar 2021 17:16:04 GMT, Greg Rubin  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>   AES/KWP/NoPadding
>
> test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/NISTWrapKAT.java line 105:
> 
>> 103: 
>> 104:     @DataProvider
>> 105:     public Object[][] testData() {
> 
> Can we please add test cases for `AES/KWP/NoPadding` where the input is an even multiple of 8? We've [seen bugs in this case before](https://github.com/pyca/cryptography/issues/4156).

Sure, there are some more from the NIST zip.

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

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

From valeriep at openjdk.java.net  Fri Mar 26 22:04:26 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 26 Mar 2021 22:04:26 GMT
Subject: RFR: 8248268: Support KWP in addition to KW
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 25 Mar 2021 02:18:06 GMT, Valerie Peng  wrote:

>> Ping, anyone has time to review this?
>
>> 
>> 
>> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at openjdk.java.net):_
>> 
>> On 3/23/2021 4:15 PM, Greg Rubin wrote:
>> 
>> > > 177:         System.out.println("Testing " + ALGO);
>> > > 178:         c = Cipher.getInstance(ALGO, "SunJCE");
>> > > 179:         for (int i = 0; i < MAX_KWP_PAD_LEN; i++) {
>> > > I see that here (and earlier) we do test all padding lengths. I'd still like some KATs generated by a known good implementation to ensure that we are not just compatible with ourselves.
>> 
>> http://csrc.nist.gov/groups/STM/cavp/documents/mac/kwtestvectors.zip has
>> the NIST test vectors.? See
>> https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/mac/KWVS.pdf
>> for details.
>> 
>> Mike
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: 
> 
> Sure, I will add some, thanks Mike for the pointers.

Hi Mike,

Please find comments in line below.

> KeyWrapCipher.java:
> 
> > 212      * Sets the padding mechanism of this cipher. Currently, only
> > 213      * "NoPadding" scheme is accepted for this cipher.
> > 214      *
> > 215      * @param padding the padding mechanism
> > 216      *
> > 217      * @exception NoSuchPaddingException if the requested padding mechanism
> > 218      * does not match the supported padding scheme
> > 219      */
> > 220     @Override
> > 221     protected void engineSetPadding(String padding)
> > 222             throws NoSuchPaddingException {
> > 223         if ((this.padding == null && !"NoPadding".equalsIgnoreCase(padding)) ||
> > 224                 this.padding instanceof PKCS5Padding &&
> > 225                 "PKCS5Padding".equalsIgnoreCase(padding)) {
> > 226             throw new NoSuchPaddingException();
> > 227         }
> > 228     }
> 
> Shouldn't this be rejecting PKCS5Padding?

Right, will fix this and update the javadoc above as well.
 
> Actually, I keep wondering why this isn't? AES/KW/NoPadding,
> AES/KW/KWPPadding and AES/KW/AutoPadding where the latter doesn't take a
> user provided IV, but figures out which of the two default IV values to
> use based on whether the input is a multiple of the blocksize or not?
> 
> Decrypting is similar - do the decryption, and check which IV you get to
> figure out padded or not padded.

The way I view it, both KW and KWP are modes. For interoperability, I referenced the corresponding mechanism definition from PKCS#11 v3.0 and base the java transformation on the corresponding PKCS#11 mechanisms. As for AES/KW/AutoPadding, it's an interesting idea, is there any other provider or library support it? To encrypt data of any size, we can just use AES/KWP/NoPadding. Is there additional benefit for this AutoPadding scheme?

Thanks,
Valerie
> 
> Mike
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 

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

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

From valeriep at openjdk.java.net  Sat Mar 27 00:25:09 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sat, 27 Mar 2021 00:25:09 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v4]
In-Reply-To: 
References: 
Message-ID: 

> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
> 
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
> 
> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Refactor code to reduce code duplication
  Address review comments
  Add more test vectors

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2404/files
  - new: https://git.openjdk.java.net/jdk/pull/2404/files/c90fdb1e..e4fd6ea2

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

  Stats: 465 lines in 6 files changed: 202 ins; 107 del; 156 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404

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

From xuelei at openjdk.java.net  Sun Mar 28 04:16:19 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 28 Mar 2021 04:16:19 GMT
Subject: RFR: 8264329: Z cannot be 1 for Diffie-Hellman key agreement
Message-ID: 

Per NIST SP 800-56A Rev 3 (section 5.7.1), the shared secret cannot be 1 or (p - 1).  This update adds this validation in the JDK provider implementation.

No new regression test, simple update and hard to construct a shared secret of 1 or (p - 1).

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

Commit messages:
 - 8264329: Z cannot be 1 for Diffie-Hellman key agreement

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

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

From wetmore at openjdk.java.net  Sun Mar 28 06:04:01 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Sun, 28 Mar 2021 06:04:01 GMT
Subject: RFR: 8264329: Z cannot be 1 for Diffie-Hellman key agreement
In-Reply-To: 
References: 
Message-ID: 

On Sun, 28 Mar 2021 04:09:38 GMT, Xue-Lei Andrew Fan  wrote:

> Per NIST SP 800-56A Rev 3 (section 5.7.1), the shared secret cannot be 1 or (p - 1).  This update adds this validation in the JDK provider implementation.
> 
> No new regression test, simple update and hard to construct a shared secret of 1 or (p - 1).

src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line 321:

> 319:                 z.equals(modulus.subtract(BigInteger.ONE))) {
> 320:             throw new ProviderException(
> 321:                     "Generated secret is out-of-rang of (1, p -1)");

typo:  rang -> range

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

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

From wetmore at openjdk.java.net  Sun Mar 28 06:10:45 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Sun, 28 Mar 2021 06:10:45 GMT
Subject: RFR: 8264329: Z cannot be 1 for Diffie-Hellman key agreement
In-Reply-To: 
References: 
Message-ID: 

On Sun, 28 Mar 2021 04:09:38 GMT, Xue-Lei Andrew Fan  wrote:

> Per NIST SP 800-56A Rev 3 (section 5.7.1), the shared secret cannot be 1 or (p - 1).  This update adds this validation in the JDK provider implementation.
> 
> No new regression test, simple update and hard to construct a shared secret of 1 or (p - 1).

Marked as reviewed by wetmore (Reviewer).

src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line 316:

> 314:         generateSecret = false;
> 315: 
> 316:         // No further process if z <= 1 or z == (p - 1).

You could mention the spec somewhere in this file.  Always nice to have the spec mentioned that we have impl'd.  Up to you.

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

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

From wetmore at openjdk.java.net  Sun Mar 28 06:10:45 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Sun, 28 Mar 2021 06:10:45 GMT
Subject: RFR: 8264329: Z cannot be 1 for Diffie-Hellman key agreement
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 28 Mar 2021 06:07:39 GMT, Bradford Wetmore  wrote:

>> Per NIST SP 800-56A Rev 3 (section 5.7.1), the shared secret cannot be 1 or (p - 1).  This update adds this validation in the JDK provider implementation.
>> 
>> No new regression test, simple update and hard to construct a shared secret of 1 or (p - 1).
>
> Marked as reviewed by wetmore (Reviewer).

Same comment for the bug report itself.

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

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

From xuelei at openjdk.java.net  Sun Mar 28 20:41:56 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 28 Mar 2021 20:41:56 GMT
Subject: RFR: 8264329: Z cannot be 1 for Diffie-Hellman key agreement [v2]
In-Reply-To: 
References: 
Message-ID: 

> Per NIST SP 800-56A Rev 3 (section 5.7.1), the shared secret cannot be 1 or (p - 1).  This update adds this validation in the JDK provider implementation.
> 
> No new regression test, simple update and hard to construct a shared secret of 1 or (p - 1).

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

  typo correction and more

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3232/files
  - new: https://git.openjdk.java.net/jdk/pull/3232/files/7b05c3a2..0dc833ce

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

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

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

From xuelei at openjdk.java.net  Sun Mar 28 20:41:57 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 28 Mar 2021 20:41:57 GMT
Subject: Integrated: 8264329: Z cannot be 1 for Diffie-Hellman key agreement
In-Reply-To: 
References: 
Message-ID: 

On Sun, 28 Mar 2021 04:09:38 GMT, Xue-Lei Andrew Fan  wrote:

> Per NIST SP 800-56A Rev 3 (section 5.7.1), the shared secret cannot be 1 or (p - 1).  This update adds this validation in the JDK provider implementation.
> 
> No new regression test, simple update and hard to construct a shared secret of 1 or (p - 1).

This pull request has now been integrated.

Changeset: c986457f
Author:    Xue-Lei Andrew Fan 
URL:       https://git.openjdk.java.net/jdk/commit/c986457f
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8264329: Z cannot be 1 for Diffie-Hellman key agreement

Reviewed-by: wetmore

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

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

From xuelei at openjdk.java.net  Mon Mar 29 04:45:29 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 29 Mar 2021 04:45:29 GMT
Subject: RFR: JDK-8263188: JSSE should fail fast if there isn't supported
 signature algorithm [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 16 Mar 2021 23:21:40 GMT, John Jiang  wrote:

>> If signature_algorithms extension is present, but the algorithms are unreconginzed or unsupported, JSSE peers should send fatal alert immediately.
>> For example, in this case, it's unnecssary to try to produce ServerHello, Certificate and ServerKeyExchange messages.
>
> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TLSv1.2 CertificateRequest could fail fast if no common signature scheme and add two tests for TLSv1.2 and TLSv1.3 respectively

Looks good to me.   Thanks!

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

Marked as reviewed by xuelei (Reviewer).

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

From jjiang at openjdk.java.net  Mon Mar 29 05:56:29 2021
From: jjiang at openjdk.java.net (John Jiang)
Date: Mon, 29 Mar 2021 05:56:29 GMT
Subject: RFR: JDK-8263188: JSSE should fail fast if there isn't supported
 signature algorithm [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 29 Mar 2021 04:42:16 GMT, Xue-Lei Andrew Fan  wrote:

>> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TLSv1.2 CertificateRequest could fail fast if no common signature scheme and add two tests for TLSv1.2 and TLSv1.3 respectively
>
> Looks good to me.   Thanks!

@XueleiFan Thanks for your review!
@jnimeh Thanks for your suggestion for writing the tests!

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

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

From jjiang at openjdk.java.net  Mon Mar 29 05:56:32 2021
From: jjiang at openjdk.java.net (John Jiang)
Date: Mon, 29 Mar 2021 05:56:32 GMT
Subject: Integrated: JDK-8263188: JSSE should fail fast if there isn't
 supported signature algorithm
In-Reply-To: 
References: 
Message-ID: <333l4x-RW0UlREgO_-POKahdKYHdr8yyuVuKsQjvrSs=.ffdaf486-d055-4e30-a0b5-2e1b538fb616@github.com>

On Mon, 8 Mar 2021 15:27:45 GMT, John Jiang  wrote:

> If signature_algorithms extension is present, but the algorithms are unreconginzed or unsupported, JSSE peers should send fatal alert immediately.
> For example, in this case, it's unnecssary to try to produce ServerHello, Certificate and ServerKeyExchange messages.

This pull request has now been integrated.

Changeset: 99b4bab3
Author:    John Jiang 
URL:       https://git.openjdk.java.net/jdk/commit/99b4bab3
Stats:     494 lines in 6 files changed: 481 ins; 0 del; 13 mod

8263188: JSSE should fail fast if there isn't supported signature algorithm

Reviewed-by: xuelei

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

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

From fguallini at openjdk.java.net  Mon Mar 29 17:31:59 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Mon, 29 Mar 2021 17:31:59 GMT
Subject: RFR: 8264190: Harden TLS interop tests [v3]
In-Reply-To: 
References: 
Message-ID: 

> Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate intermittent failures, this patch updates interop/BaseInteropTest.java in order to validate the server is alive and if not, retry to create a valid server.
> 
> In addition, Utilities::isSessionResumed implementation is now comparing equality of first and second session creation time to validate session resumption

Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

  Improve JdkServer::close and Utilities::waitFor methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3218/files
  - new: https://git.openjdk.java.net/jdk/pull/3218/files/474f482d..5688014b

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

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

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

From fguallini at openjdk.java.net  Mon Mar 29 17:38:43 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Mon, 29 Mar 2021 17:38:43 GMT
Subject: RFR: 8264190: Harden TLS interop tests [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 29 Mar 2021 17:31:59 GMT, Fernando Guallini  wrote:

>> Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate intermittent failures, this patch updates interop/BaseInteropTest.java in order to validate the server is alive and if not, retry to create a valid server.
>> 
>> In addition, Utilities::isSessionResumed implementation is now comparing equality of first and second session creation time to validate session resumption
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve JdkServer::close and Utilities::waitFor methods

test/jdk/javax/net/ssl/TLSCommon/interop/JdkServer.java line 145:

> 143:     @Override
> 144:     public void close() throws IOException {
> 145:         if (!serverSocket.isClosed()) {

isAlive can be overridden with a more complex implementation, whereas the only default requirement to close the socket in this case is checking it is not already closed.

test/jdk/javax/net/ssl/TLSCommon/interop/Utilities.java line 220:

> 218:      *  Sleeps until the condition is true or getting timeout.
> 219:      */
> 220:     public static  boolean waitFor(Predicate predicate, T t) {

waitFor method was evaluating predicate at least twice with previous implementation even when true

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

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

From rhalade at openjdk.java.net  Mon Mar 29 18:52:38 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 29 Mar 2021 18:52:38 GMT
Subject: RFR: 8264190: Harden TLS interop tests [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 29 Mar 2021 17:31:59 GMT, Fernando Guallini  wrote:

>> Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate intermittent failures, this patch updates interop/BaseInteropTest.java in order to validate the server is alive and if not, retry to create a valid server.
>> 
>> In addition, Utilities::isSessionResumed implementation is now comparing equality of first and second session creation time to validate session resumption
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve JdkServer::close and Utilities::waitFor methods

test/jdk/javax/net/ssl/TLSCommon/interop/BaseInteropTest.java line 236:

> 234:             // Retry operation, server might have failed to bind a port
> 235:             server.signalStop();
> 236:             server = createServer(useCase, executor);

Can you please define MAX_RETRIES and use loop to retry? This will make it flexible for us to update retries if needed and avoid duplicate code.

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

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

From luoziyi at openjdk.java.net  Mon Mar 29 20:18:41 2021
From: luoziyi at openjdk.java.net (Ziyi Luo)
Date: Mon, 29 Mar 2021 20:18:41 GMT
Subject: Integrated: 8263404: RsaPrivateKeySpec is always recognized as
 RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec
In-Reply-To: 
References: 
Message-ID: 

On Thu, 11 Mar 2021 19:51:19 GMT, Ziyi Luo  wrote:

> This is a P2 regression introduced by JDK-8254717.
> 
> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is described as follow:
> 
> X-axis: type of `keySpec`
> Y-axis: type of `key`
> 
> Before JDK-8254717:
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
> 
> After JDK-8254717 (Green check is what we want to fix, red cross is the regression):
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Throw `InvalidKeySpecException` ?  | Throw `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ? | Return RSAPrivateKeyCrtSpec |
> 
> This commit fixes the regression.
> 
> 
> ### Tests
> 
> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` passed
> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed

This pull request has now been integrated.

Changeset: a5d7de23
Author:    Ziyi Luo 
Committer: Valerie Peng 
URL:       https://git.openjdk.java.net/jdk/commit/a5d7de23
Stats:     311 lines in 6 files changed: 253 ins; 24 del; 34 mod

8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec

Co-authored-by: Greg Rubin 
Reviewed-by: valeriep

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

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

From rriggs at openjdk.java.net  Mon Mar 29 20:41:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 29 Mar 2021 20:41:35 GMT
Subject: Integrated: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: 
References: 
Message-ID: 

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs  wrote:

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

This pull request has now been integrated.

Changeset: 8cf1c62c
Author:    Roger Riggs 
URL:       https://git.openjdk.java.net/jdk/commit/8cf1c62c
Stats:     54 lines in 5 files changed: 0 ins; 15 del; 39 mod

8263754: HexFormat 'fromHex' methods should be static

Reviewed-by: redestad, naoto, chegar

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

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

From smarks at openjdk.java.net  Mon Mar 29 21:21:02 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 29 Mar 2021 21:21:02 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: 
References: 
Message-ID: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy  wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`.

(The considerations for the JDK itself are different, though, which is why I support changing the call sites.)

One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.

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

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

From darcy at openjdk.java.net  Mon Mar 29 21:21:02 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Mar 2021 21:21:02 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception
 chaining
Message-ID: 

8264148: Update spec for exceptions retrofitted for exception chaining

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

Commit messages:
 - Respond to review feedback.
 - Respond to review feedback.
 - Merge branch 'master' into 8264148
 - Merge branch 'master' into 8264148
 - 8264148: Update spec for exceptions retrofitted for exception chaining

Changes: https://git.openjdk.java.net/jdk/pull/3182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3182&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264148
  Stats: 84 lines in 22 files changed: 8 ins; 44 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3182/head:pull/3182

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

From darcy at openjdk.java.net  Mon Mar 29 21:21:03 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Mar 2021 21:21:03 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
References: 
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: 

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks  wrote:

>> 8264148: Update spec for exceptions retrofitted for exception chaining
>
> The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`.
> 
> (The considerations for the JDK itself are different, though, which is why I support changing the call sites.)
> 
> One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.

Some discussion of the proposed changes here. While the history with respect to the introduction of the chained exception mechanism may have been relevant in times past, those comments have little utility today. Per guidance from Dr. Deprecator, I've removed deprecation of the redundant methods and only kept deprecation of the mutable field in WriteAbortedException.

The legacy wrapped exception accessing methods in ClassNotFoundException, ExceptionInInitializerError, and UndeclaredThrowableException are equivalent to getCause. The legacy method in PrivilegedActionException returns the same value, but narrowed to Exception rather than Throwable.

Once the rest of the change is agree to, I'll update copyrights and do a CSR for the deprecation and other spec changes.

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

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

From weijun at openjdk.java.net  Tue Mar 30 02:07:06 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Mar 2021 02:07:06 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: 
References: 
Message-ID: 

> This enhancement contains the following code changes:
> 
> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one.
> 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions.
> 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec`
> 4. Tests

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

  update XMLUtils (not used by tests here)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3181/files
  - new: https://git.openjdk.java.net/jdk/pull/3181/files/e459545a..211c491c

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

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

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

From github.com+28367473+jmehrens at openjdk.java.net  Tue Mar 30 04:01:57 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Tue, 30 Mar 2021 04:01:57 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
References: 
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: 

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks  wrote:

> One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.


Agreed. WriteAbortedException should get similar treatment as the others like it:

- http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016908.html
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html
- https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051341.html

The only twist is that we would have to keep the public field as deprecated.

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

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

From jlaskey at openjdk.java.net  Tue Mar 30 11:07:47 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 30 Mar 2021 11:07:47 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v31]
In-Reply-To: <7yvwMppH8E53dxxutLQCRKg6UpiXwjzobRmjz9hOOHM=.d4b62b25-849e-4539-a207-f136a6e96b52@github.com>
References: 
 
 
 <7yvwMppH8E53dxxutLQCRKg6UpiXwjzobRmjz9hOOHM=.d4b62b25-849e-4539-a207-f136a6e96b52@github.com>
Message-ID: <9Es77RTptBxFcVenc1vGjX4aDX0ebTKV75rzZJxR0uo=.35dad54d-1d18-438c-8050-306c6fe66982@github.com>

On Thu, 18 Mar 2021 12:57:16 GMT, Jim Laskey  wrote:

>> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 62:
>> 
>>> 60:     @Retention(RetentionPolicy.RUNTIME)
>>> 61:     @Target(ElementType.TYPE)
>>> 62:     public @interface RandomGeneratorProperties {
>> 
>> Should the is-deprecated information be stored here?
>
> I don't think so. That would require the deprecation state be stored in two places. I think it's sufficient to rely on the presence of @Deprecated.

isDeprecated was added

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

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

From jlaskey at openjdk.java.net  Tue Mar 30 11:12:07 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 30 Mar 2021 11:12:07 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v38]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits:

 - Merge branch 'master' into 8248862
 - CSR review revisions
 - CSR review updates
 - Removed @since from nextDouble ThreadLocalRandom
 - RandomGeneratorFactory::all(Class category) @implNote was out of date
 - Clarify all()
 - Cleaned up ints(), longs(), doubles()
 - Merge branch 'master' into 8248862
 - Review revisions
 - Missing @since
 - ... and 64 more: https://git.openjdk.java.net/jdk/compare/f3726a87...3de42645

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=37
  Stats: 12965 lines in 26 files changed: 11199 ins; 1588 del; 178 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

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

From jlaskey at openjdk.java.net  Tue Mar 30 13:03:49 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 30 Mar 2021 13:03:49 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v39]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Correct return type of RandomGeneratorFactory.of

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/3de42645..0aa49eda

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=38
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=37-38

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

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

From weijun at openjdk.java.net  Tue Mar 30 13:10:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Mar 2021 13:10:26 GMT
Subject: RFR: 8264277: java.xml.crypto module should be granted FilePermission
 and SocketPermission
Message-ID: 

These permissions are needed so that the URIDereferencer is able to read data from a file system or a network. As the test shows, you still have to grant the same type of permission to your application.

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

Depends on: https://git.openjdk.java.net/jdk/pull/3181

Commit messages:
 - 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission

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

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

From rriggs at openjdk.java.net  Tue Mar 30 13:29:23 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 30 Mar 2021 13:29:23 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: 
References: 
Message-ID: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy  wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

I agree that the public field in WriteAbortedException could be remediated.
But it is also mostly harmless.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62:

> 60:     catch (java.lang.reflect.InvocationTargetException ite) {
> 61:         if (ite.getCause() instanceof RuntimeException) {
> 62:             throw (RuntimeException)ite.getCause();

This might be a place to use the new instanceof pattern form:
`if (ite.getCause() instanceof RuntimeException rex)
        throw rex.getCause();
`

src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293:

> 291:             Throwable t = e.getCause();
> 292:             if (t instanceof Exception) {
> 293:                 throw (Exception) t;

Ditto:
 ` if (t instanceof Exception ex) throw ex`

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

Marked as reviewed by rriggs (Reviewer).

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

From github.com+28367473+jmehrens at openjdk.java.net  Tue Mar 30 13:43:22 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Tue, 30 Mar 2021 13:43:22 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: 
References: 
Message-ID: 

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy  wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

src/java.base/share/classes/java/io/WriteAbortedException.java line 86:

> 84:     @Override
> 85:     public Throwable getCause() {
> 86:         return detail;

Use SuppressWarnings??

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

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

From mullan at openjdk.java.net  Tue Mar 30 15:38:11 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 30 Mar 2021 15:38:11 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 30 Mar 2021 02:07:06 GMT, Weijun Wang  wrote:

>> This enhancement contains the following code changes:
>> 
>> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one.
>> 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions.
>> 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec`
>> 4. Tests
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update XMLUtils (not used by tests here)

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 36:

> 34:  * Parameters for the


> 35:  * XML Signature RSASSA-PSS Algorithm. The parameters are expressed as a
> 36:  * {@link PSSParameterSpec} object encapsulated.

I suggest removing "encapsulated", I found use of that word a little confusing. Maybe just "The parameters are represented as a {@link PSSParameterSpec} object." Similar comment about "encapsulated" in other methods.

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 75:

> 73:  * {@code TrailerField}. This is equivalent to the parameter-less signature
> 74:  * method as defined by http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
> 75:  *

Normally I don't like to hardcode defaults (in case they weaken later) but since this is specified by RFC 6931, I don't think we have a choice, and I think we need to use this default for interoperability.

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 89:

> 87:      *
> 88:      * @param spec the input {@code PSSParameterSpec} to be encapsulated
> 89:      */

Should this throw NPE if spec is null?

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 99:

> 97:      * @return the encapsulated {@code PSSParameterSpec} object
> 98:      */
> 99:     public PSSParameterSpec getPSSParameterSpec() {

If an XML Signature contained an RSAPSSParams with no DigestMethod, would this return a PSSParameterSpec with the defaults as specified in the @implSpec?

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 103:

> 101:     }
> 102: 
> 103:     @Override

Since you are overriding `Object.hashCode` and `equals`, I think you should document the specification for that.

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 113:

> 111: 
> 112:     @Override
> 113:     public boolean equals(Object obj) {

Add specification.

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 139:

> 137: 
> 138:     @Override
> 139:     public String toString() {

Add specification.

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

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

From joe.darcy at oracle.com  Tue Mar 30 15:55:20 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 08:55:20 -0700
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: 
References: 
 
Message-ID: <76cee601-67a3-adbd-ea45-ded1f2dc592e@oracle.com>


On 3/30/2021 6:43 AM, jmehrens wrote:
> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy  wrote:
>
>> 8264148: Update spec for exceptions retrofitted for exception chaining
> src/java.base/share/classes/java/io/WriteAbortedException.java line 86:
>
>> 84:     @Override
>> 85:     public Throwable getCause() {
>> 86:         return detail;
> Use SuppressWarnings??


There is no warning to suppress since the detail field is defined in the 
same class.

-Joe


From joe.darcy at oracle.com  Tue Mar 30 16:00:50 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 09:00:50 -0700
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>
References: 
 <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>
Message-ID: <0627b7e4-6db3-50bc-fba5-35877647d038@oracle.com>


On 3/30/2021 6:29 AM, Roger Riggs wrote:
> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy  wrote:
>
>> 8264148: Update spec for exceptions retrofitted for exception chaining
> I agree that the public field in WriteAbortedException could be remediated.
> But it is also mostly harmless.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62:
>
>> 60:     catch (java.lang.reflect.InvocationTargetException ite) {
>> 61:         if (ite.getCause() instanceof RuntimeException) {
>> 62:             throw (RuntimeException)ite.getCause();
> This might be a place to use the new instanceof pattern form:
> `if (ite.getCause() instanceof RuntimeException rex)
>          throw rex.getCause();
> `
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293:
>
>> 291:             Throwable t = e.getCause();
>> 292:             if (t instanceof Exception) {
>> 293:                 throw (Exception) t;
> Ditto:
>   ` if (t instanceof Exception ex) throw ex`
>

I think the use of the new instanceof form would be better left for a 
follow-up refactoring.

Thanks,

-Joe


From weijun at openjdk.java.net  Tue Mar 30 16:37:21 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Mar 2021 16:37:21 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 30 Mar 2021 15:04:29 GMT, Sean Mullan  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update XMLUtils (not used by tests here)
>
> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 36:
> 
>> 34:  * Parameters for the 
>> 35:  * XML Signature RSASSA-PSS Algorithm. The parameters are expressed as a
>> 36:  * {@link PSSParameterSpec} object encapsulated.
> 
> I suggest removing "encapsulated", I found use of that word a little confusing. Maybe just "The parameters are represented as a {@link PSSParameterSpec} object." Similar comment about "encapsulated" in other methods.

OK.

> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 75:
> 
>> 73:  * {@code TrailerField}. This is equivalent to the parameter-less signature
>> 74:  * method as defined by http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
>> 75:  *
> 
> Normally I don't like to hardcode defaults (in case they weaken later) but since this is specified by RFC 6931, I don't think we have a choice, and I think we need to use this default for interoperability.

Yes, we need to support `xMLSignatureFactory.newSignatureMethod(SignatureMethod.RSA_PSS, null)`.

> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 89:
> 
>> 87:      *
>> 88:      * @param spec the input {@code PSSParameterSpec} to be encapsulated
>> 89:      */
> 
> Should this throw NPE if spec is null?

I currently throw one. Do I need to mention it in the spec?

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

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

From weijun at openjdk.java.net  Tue Mar 30 16:43:16 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Mar 2021 16:43:16 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com>

On Tue, 30 Mar 2021 15:31:22 GMT, Sean Mullan  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update XMLUtils (not used by tests here)
>
> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 99:
> 
>> 97:      * @return the encapsulated {@code PSSParameterSpec} object
>> 98:      */
>> 99:     public PSSParameterSpec getPSSParameterSpec() {
> 
> If an XML Signature contained an RSAPSSParams with no DigestMethod, would this return a PSSParameterSpec with the defaults as specified in the @implSpec?

Yes. The `DOMRSAPSSSignatureMethod::unmarshalParams` method will fill the blanks.

> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 103:
> 
>> 101:     }
>> 102: 
>> 103:     @Override
> 
> Since you are overriding `Object.hashCode` and `equals`, I think you should document the specification for that.

OK.

> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 113:
> 
>> 111: 
>> 112:     @Override
>> 113:     public boolean equals(Object obj) {
> 
> Add specification.

OK.

> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 139:
> 
>> 137: 
>> 138:     @Override
>> 139:     public String toString() {
> 
> Add specification.

OK.

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

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

From weijun at openjdk.java.net  Tue Mar 30 16:59:20 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Mar 2021 16:59:20 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <265WkdPb8F66rItSIuZ9ZPZ5cmCmBPJWGgM-gImZRkI=.c41874ed-2d67-4d9e-ae8e-02b6b3c88a89@github.com>

On Tue, 30 Mar 2021 15:34:16 GMT, Sean Mullan  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update XMLUtils (not used by tests here)
>
> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 103:
> 
>> 101:     }
>> 102: 
>> 103:     @Override
> 
> Since you are overriding `Object.hashCode` and `equals`, I think you should document the specification for that.

For `equals` and `hashCode`, the removed internal `org/jcp/xml/dsig/internal/dom/RSAPSSParameterSpec.java` file had them so I kept them. But now I intend to remove both. `HMACParameterSpec` in the same package does not have them. In fact, I felt a little uncomfortable on using the result of `mgfParamsAsString` in `hashCode` and `equals` because even `PSSParameterSpec` and `MGF1ParameterSpec` have not implemented them.

As for `toString`, I'm not sure if there needs a spec (and I don't want to specify the output format). `PSSParameterSpec` and `MGF1ParameterSpec` implemented it with no spec. The documentation at https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/security/spec/MGF1ParameterSpec.html also only list it in the "Methods declared in class java.lang.Object" with all other `Object` methods no matter if it's overridden or not.

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

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

From smarks at openjdk.java.net  Tue Mar 30 17:06:32 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 30 Mar 2021 17:06:32 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: 
References: 
Message-ID: 

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy  wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

Marked as reviewed by smarks (Reviewer).

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

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

From mullan at openjdk.java.net  Tue Mar 30 18:31:22 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 30 Mar 2021 18:31:22 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 30 Mar 2021 16:34:45 GMT, Weijun Wang  wrote:

>> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 89:
>> 
>>> 87:      *
>>> 88:      * @param spec the input {@code PSSParameterSpec} to be encapsulated
>>> 89:      */
>> 
>> Should this throw NPE if spec is null?
>
> I currently throw one. Do I need to mention it in the spec?

Yes, unless it is specified more generally somewhere else in the API. (Ex: "all methods that take parameters with a `null` value throw `NullPointerException` unless otherwise specified").

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

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

From mullan at openjdk.java.net  Tue Mar 30 18:41:29 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 30 Mar 2021 18:41:29 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: <265WkdPb8F66rItSIuZ9ZPZ5cmCmBPJWGgM-gImZRkI=.c41874ed-2d67-4d9e-ae8e-02b6b3c88a89@github.com>
References: 
 
 
 <265WkdPb8F66rItSIuZ9ZPZ5cmCmBPJWGgM-gImZRkI=.c41874ed-2d67-4d9e-ae8e-02b6b3c88a89@github.com>
Message-ID: 

On Tue, 30 Mar 2021 16:56:22 GMT, Weijun Wang  wrote:

>> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 103:
>> 
>>> 101:     }
>>> 102: 
>>> 103:     @Override
>> 
>> Since you are overriding `Object.hashCode` and `equals`, I think you should document the specification for that.
>
> For `equals` and `hashCode`, the removed internal `org/jcp/xml/dsig/internal/dom/RSAPSSParameterSpec.java` file had them so I kept them. But now I intend to remove both. `HMACParameterSpec` in the same package does not have them. In fact, I felt a little uncomfortable on using the result of `mgfParamsAsString` in `hashCode` and `equals` because even `PSSParameterSpec` and `MGF1ParameterSpec` have not implemented them.
> 
> As for `toString`, I'm not sure if there needs a spec (and I don't want to specify the output format). `PSSParameterSpec` and `MGF1ParameterSpec` implemented it with no spec. The documentation at https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/security/spec/MGF1ParameterSpec.html also only list it in the "Methods declared in class java.lang.Object" with all other `Object` methods no matter if it's overridden or not.

I agree with removing `equals` and `hashCode`. For `toString` I think what you have implemented is compliant with Object.toString() so I'm ok with not adding a specific specification for that.

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

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

From mullan at openjdk.java.net  Tue Mar 30 18:44:22 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 30 Mar 2021 18:44:22 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com>
References: 
 
 
 <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com>
Message-ID: 

On Tue, 30 Mar 2021 16:39:37 GMT, Weijun Wang  wrote:

>> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 99:
>> 
>>> 97:      * @return the encapsulated {@code PSSParameterSpec} object
>>> 98:      */
>>> 99:     public PSSParameterSpec getPSSParameterSpec() {
>> 
>> If an XML Signature contained an RSAPSSParams with no DigestMethod, would this return a PSSParameterSpec with the defaults as specified in the @implSpec?
>
> There are other fields in `RSASSAParams`, so if there is no DigestMethod, it will be SHA-256 but the other fields (like SaltLength or TrailerField) will still be read if they exist.
> 
> If there is no `RSASSAParams` at all or if it's empty, then the defaults will be returned.

I wonder if the @implSpec is clear enough that this will be returned. I might suggest adding a similar @implSpec in this method that basically states what you said above.

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

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

From arjan.tijms at gmail.com  Thu Mar  4 22:09:05 2021
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 04 Mar 2021 22:09:05 -0000
Subject: TLS 1.3 Post-handshake authentication
In-Reply-To: 
References: 
 
Message-ID: 

Hi,

On Thu, Mar 4, 2021 at 10:48 PM Xue-Lei Fan  wrote:

> 
>
> Hi Arjan,
>
> Did you have a chance to read RFC 8740?  Post-Handshake authentication in
> HTTP/2 is not allowed for TLS 1.3.  Is there a concern for the use case you
> mentioned?
>

Servlet supports both HTTP/1.1 and HTTP/2. The concern here is for
HTTP/1.1. We'll likely exclude client-cert for HTTP/2.

Kind regards,
Arjan Tijms







>
>
> Xuelei
> ------------------------------
> *From:* jdk-dev  on behalf of arjan tijms <
> arjan.tijms at gmail.com>
> *Sent:* Thursday, March 4, 2021 12:57 PM
> *To:* jdk-dev at openjdk.java.net 
> *Subject:* TLS 1.3 Post-handshake authentication
>
> Hi,
>
> I noticed the following issue was recently closed:
>
> https://bugs.openjdk.java.net/browse/JDK-8206923
>
> For the Servlet spec this is however a very important feature, to the point
> that for the Servlet TCK we would need to explicitly allow vendors to use
> TLS 1.2 for the client-cert authentication mechanism test.
>
> Servlet needs this post-handshake authentication, since it allows the
> server to have protected/secured resources on a URL basis. During the
> handshake the URL that the client wishes to request is not yet available,
> so the server is unable to determine at that point whether it requires the
> client to present a certificate.
>
> Only when the request is being serviced can the server determine this, and
> respond with a certificate request. This however fails when using TLS 1.3,
> since it's not implemented in Java.
>
> The issue mentions that it might be implemented on request, so hereby I
> would like to request this.
>
> Kind regards,
> Arjan Tijms (Servlet spec committer)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Mon Mar 15 17:10:32 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 15 Mar 2021 17:10:32 -0000
Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys
Message-ID: 

Hi,

JDK-8243559 is backported to 11.0.12-oracle. I'd like to backport it for parity.

I had to integrate changes to the test VerifyCACerts.java manually:
- Add bug ID.
- Adapt COUNT.
- Compute new CHECKSUM.
- Remove verisigntsaca and thawtepremiumserverca in the last hunk.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8243559

Original change:
https://github.com/openjdk/jdk/commit/dbfeb90d

11u backport:
http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Tue Mar 16 10:39:29 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 16 Mar 2021 10:39:29 +0000
Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys
In-Reply-To: <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com>
References: 
 <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com>
Message-ID: 

Hi Severin,

sorry, seems like I had pasted the wrong one. Here's the correct one:
http://cr.openjdk.java.net/~mdoerr/8243559_root_ca_11u/webrev.00/

Best regards,
Martin


> -----Original Message-----
> From: Severin Gehwolf 
> Sent: Dienstag, 16. M?rz 2021 11:21
> To: Doerr, Martin ; jdk-updates-
> dev at openjdk.java.net; security-dev 
> Cc: Lindenmaier, Goetz ; Langer, Christoph
> 
> Subject: Re: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys
> 
> Hi Martin,
> 
> On Mon, 2021-03-15 at 17:10 +0000, Doerr, Martin wrote:
> > 11u backport:
> > http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/
> 
> This doesn't look like the right webrev to me. Could you please double-
> check?
> 
> Thanks,
> Severin


From martin.doerr at sap.com  Tue Mar 16 14:20:50 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 16 Mar 2021 14:20:50 +0000
Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys
In-Reply-To: 
References: 
 <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com>
 
 
Message-ID: 

Hi Severin,

thank you for the review!

Best regards,
Martin


> -----Original Message-----
> From: Severin Gehwolf 
> Sent: Dienstag, 16. M?rz 2021 15:12
> To: Doerr, Martin ; jdk-updates-
> dev at openjdk.java.net; security-dev 
> Cc: Lindenmaier, Goetz ; Langer, Christoph
> 
> Subject: Re: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys
> 
> On Tue, 2021-03-16 at 10:39 +0000, Doerr, Martin wrote:
> > http://cr.openjdk.java.net/~mdoerr/8243559_root_ca_11u/webrev.00/
> 
> This looks good to me.
> 
> Thanks,
> Severin


From martin.doerr at sap.com  Tue Mar 23 15:24:43 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 23 Mar 2021 15:24:43 +0000
Subject: [11u] RFR: 8206925: Support the certificate_authorities extension
Message-ID: 

Hi,

JDK-8206925 was backported to 11.0.10-oracle, but it's still missing in the Open Source version.
I'd like to backport it for parity.
It does apply cleanly, but I had to modify it, because the following change is not in 11u:
https://bugs.openjdk.java.net/browse/JDK-8215712

Bug:
https://bugs.openjdk.java.net/browse/JDK-8206925

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/827bac238aa0

11u backport:
http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/webrev.00/

Manual change to make it work without JDK-8215712 (SSLStringizer and derived classes don't take a HandshakeContext in 11u):
http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/8206925_ca_ext_diff.txt

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Wed Mar 24 16:41:29 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 24 Mar 2021 16:41:29 +0000
Subject: [11u] RFR: 8206925: Support the certificate_authorities extension
In-Reply-To: 
References: 
 
Message-ID: 

Hi Christoph,

thank you for the review and checking the tests!

I agree. We should try to deliver it with 11.0.11 if possible.
I?ve added the CSR to my backport comment and labeled the issue with jdk11u-critical-request.

Best regards,
Martin


From: Langer, Christoph 
Sent: Mittwoch, 24. M?rz 2021 15:48
To: Doerr, Martin ; jdk-updates-dev at openjdk.java.net; security-dev ; Severin Gehwolf ; Andrew Haley 
Cc: Lindenmaier, Goetz 
Subject: RE: [11u] RFR: 8206925: Support the certificate_authorities extension

Hi Martin,

your backport looks good. I see the new tests pass and our testing does not unveil other regressions. Reviewed.

Oracle has already included this item in 11.0.10 but it fell through the cracks for OpenJDK 11u due to an issue with the updates filter. However, it seems like an important item for TLS 1.3 usability. We have just received a customer request why this wasn?t included in 11u yet, they would need it for their product to move on to TLS 1.3. So I think we should strive for 11.0.11 with this backport. Please label accordingly. Adding @Andrew Haley and @Severin Gehwolf for their opinion on this decision ??

The CSR https://bugs.openjdk.java.net/browse/JDK-8248709 should apply to this backport, please link it to the JBS issue.

Thanks & Best regards
Christoph

From: Doerr, Martin >
Sent: Dienstag, 23. M?rz 2021 16:25
To: jdk-updates-dev at openjdk.java.net; security-dev >
Cc: Lindenmaier, Goetz >; Langer, Christoph >
Subject: [11u] RFR: 8206925: Support the certificate_authorities extension

Hi,

JDK-8206925 was backported to 11.0.10-oracle, but it?s still missing in the Open Source version.
I'd like to backport it for parity.
It does apply cleanly, but I had to modify it, because the following change is not in 11u:
https://bugs.openjdk.java.net/browse/JDK-8215712

Bug:
https://bugs.openjdk.java.net/browse/JDK-8206925

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/827bac238aa0

11u backport:
http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/webrev.00/

Manual change to make it work without JDK-8215712 (SSLStringizer and derived classes don?t take a HandshakeContext in 11u):
http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/8206925_ca_ext_diff.txt

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Tue Mar 30 12:01:12 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 30 Mar 2021 12:01:12 +0000
Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE
Message-ID: 

Hi,

JDK-8254631 is backported to 11.0.12-oracle. I'd like to backport it for parity.
It applies cleanly, but the javadoc parts don't compile with 11u. They are not compatible with 11u and are documented to be dropped in the CSR (linked below).
As also documented in the CSR, the old behavior can get restored by specifying the property: jdk.tls.alpnCharset=UTF-8

Bug:
https://bugs.openjdk.java.net/browse/JDK-8254631

Original change:
https://git.openjdk.java.net/jdk/commit/fe5cccc1

11u CSR:
https://bugs.openjdk.java.net/browse/JDK-8264177

11u backport:
http://cr.openjdk.java.net/~mdoerr/8254631_ALPN_11u/webrev.00/

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From darcy at openjdk.java.net  Tue Mar 30 20:03:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 30 Mar 2021 20:03:18 GMT
Subject: Integrated: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: 
References: 
Message-ID: 

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy  wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

This pull request has now been integrated.

Changeset: 815248ab
Author:    Joe Darcy 
URL:       https://git.openjdk.java.net/jdk/commit/815248ab
Stats:     84 lines in 22 files changed: 8 ins; 44 del; 32 mod

8264148: Update spec for exceptions retrofitted for exception chaining

Reviewed-by: rriggs, smarks

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

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

From weijun at openjdk.java.net  Tue Mar 30 20:28:12 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Mar 2021 20:28:12 GMT
Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for
 RSASSA-PSS params [v2]
In-Reply-To: 
References: 
 
 
 <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com>
 
Message-ID: 

On Tue, 30 Mar 2021 18:41:45 GMT, Sean Mullan  wrote:

>> There are other fields in `RSASSAParams`, so if there is no DigestMethod, it will be SHA-256 but the other fields (like SaltLength or TrailerField) will still be read if they exist.
>> 
>> If there is no `RSASSAParams` at all or if it's empty, then the defaults will be returned.
>
> I wonder if the @implSpec is clear enough that this will be returned. I might suggest adding a similar @implSpec in this method that basically states what you said above.

I'm not sure if it's appropriate to specify the default value in this method. As long as there is an `RSAPSSParameterSpec` object, there must be a non-null `PSSParameterSpec` inside and it is the one that was used to construct this object.

I am thinking if we can append the following to the `@implNote` in the class spec:
 * One can obtain this default value using the following expression:
 * 
 * XMLSignatureFactory.getInstance()
 *      .newSignatureMethod(SignatureMethod.RSA_PSS, null)
 *      .getParameterSpec()
 * 

but this makes it more like an `@implNote` instead of an `@implSpec`.

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

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

From valeriep at openjdk.java.net  Tue Mar 30 20:54:34 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Mar 2021 20:54:34 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao 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:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 265:

> 263:                 // NSS requires block-sized updates in multi-part operations.
> 264:                 reqBlockUpdates = ((tokenLabel[0] == 'N' && tokenLabel[1] == 'S'
> 265:                         && tokenLabel[2] == 'S') ? true : false);

IIRC, depending on how the impl is registered, engineSetPadding(String) may not always be called. It's probably safer to set this in engineInit(...)?

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

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

From valeriep at openjdk.java.net  Tue Mar 30 21:22:21 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Mar 2021 21:22:21 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 639:

> 637:                     // returned to the caller. None of this is necessary for
> 638:                     // encryption: encrypted data can be safely returned upon a
> 639:                     // implUpdate call.

nit: all of the "unencrypted" -> "decrypted". I think this is a bit too verbose? Could we trim it down more, e.g. for decrypting with update() calls, up to a block of input is held inside padBuffer as it may contain padding bytes when no more data is supplied when doFinal() is called.

It should be clear that this does not apply for encryption, so there should be no need to state that.

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

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

From valeriep at openjdk.java.net  Tue Mar 30 21:27:16 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Mar 2021 21:27:16 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 654:

> 652:             }
> 653:             // update 'padBuffer' if using our own padding impl.
> 654:             if (paddingObj != null) {

nit: if (paddingObj != null && newPadBufferLen > 0)?

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

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

From valeriep at openjdk.java.net  Tue Mar 30 21:53:33 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Mar 2021 21:53:33 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 606:

> 604:                     // NSS throws up when called with data not in multiple
> 605:                     // of blocks. Try to work around this by holding the
> 606:                     // extra data in padBuffer.

nit: The comment looks a little bit strange. This particular block of code is for handling existing buffered data buffered in earlier update() calls. The comment however is more about 'reqBlockUpdates' itself. How about merging this with the comment for 'reqBlockUpdates' field and then changing this comment to what this particular block of code does.

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

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

From valeriep at openjdk.java.net  Tue Mar 30 22:15:23 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Mar 2021 22:15:23 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: <-nQA2Ne5zGoySwymZnaGeLMIq5pOh8RDwAjLfeNfhQM=.8f75ad51-f0b7-4b7a-aa70-2ae8d0034467@github.com>

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 819:

> 817:                     int startOff = 0;
> 818:                     if (reqBlockUpdates) {
> 819:                         startOff = bytesBuffered;

Shouldn't the starting offset be the number of bytes in padBuffer, i.e. padBufferLen?

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

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

From valeriep at openjdk.java.net  Tue Mar 30 22:15:24 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 30 Mar 2021 22:15:24 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: <-nQA2Ne5zGoySwymZnaGeLMIq5pOh8RDwAjLfeNfhQM=.8f75ad51-f0b7-4b7a-aa70-2ae8d0034467@github.com>
References: 
 
 <-nQA2Ne5zGoySwymZnaGeLMIq5pOh8RDwAjLfeNfhQM=.8f75ad51-f0b7-4b7a-aa70-2ae8d0034467@github.com>
Message-ID: 

On Tue, 30 Mar 2021 22:10:11 GMT, Valerie Peng  wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Avoid overriding buffered bytes with padding in the doFinal call.
>>  - Only do encryption block-size buffering for NSS
>>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 819:
> 
>> 817:                     int startOff = 0;
>> 818:                     if (reqBlockUpdates) {
>> 819:                         startOff = bytesBuffered;
> 
> Shouldn't the starting offset be the number of bytes in padBuffer, i.e. padBufferLen?

Then no need for the assert(...) to check the starting offset value.

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

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

From valeriep at openjdk.java.net  Wed Mar 31 00:10:23 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 31 Mar 2021 00:10:23 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 910:

> 908:                 if (paddingObj != null) {
> 909:                     int actualPadLen = paddingObj.setPaddingBytes(padBuffer,
> 910:                             0, requiredOutLen - bytesBuffered);

Shouldn't the starting offset be 'padBufferLen'?

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

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

From valeriep at openjdk.java.net  Wed Mar 31 00:20:19 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 31 Mar 2021 00:20:19 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 912:

> 910:                             0, requiredOutLen - bytesBuffered);
> 911:                     k = token.p11.C_EncryptUpdate(session.id(),
> 912:                             0, padBuffer, 0, actualPadLen,

actualPadLen => actualPadLen + startOfs?

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

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

From hchao at openjdk.java.net  Wed Mar 31 06:36:50 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 31 Mar 2021 06:36:50 GMT
Subject: RFR: 8260693: Provide the support for specifying a signer in keytool
 -genkeypair
Message-ID: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com>

Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate.
CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325

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

Commit messages:
 - 8260693: Provide the support for specifying a signer in keytool -genkeypair

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

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

From fguallini at openjdk.java.net  Wed Mar 31 10:53:34 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Wed, 31 Mar 2021 10:53:34 GMT
Subject: RFR: 8264190: Harden TLS interop tests [v4]
In-Reply-To: 
References: 
Message-ID: 

> Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate intermittent failures, this patch updates interop/BaseInteropTest.java in order to validate the server is alive and if not, retry to create a valid server.
> 
> In addition, Utilities::isSessionResumed implementation is now comparing equality of first and second session creation time to validate session resumption

Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

  add max_retries count, move shell methods to ProcUtils and add win methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3218/files
  - new: https://git.openjdk.java.net/jdk/pull/3218/files/5688014b..b29e4886

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

  Stats: 143 lines in 3 files changed: 93 ins; 42 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3218.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3218/head:pull/3218

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

From fguallini at openjdk.java.net  Wed Mar 31 10:58:29 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Wed, 31 Mar 2021 10:58:29 GMT
Subject: RFR: 8264190: Harden TLS interop tests [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 29 Mar 2021 18:45:47 GMT, Rajan Halade  wrote:

>> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve JdkServer::close and Utilities::waitFor methods
>
> test/jdk/javax/net/ssl/TLSCommon/interop/BaseInteropTest.java line 236:
> 
>> 234:             // Retry operation, server might have failed to bind a port
>> 235:             server.signalStop();
>> 236:             server = createServer(useCase, executor);
> 
> Can you please define MAX_RETRIES and use loop to retry? This will make it flexible for us to update retries if needed and avoid duplicate code.

Done, also retries value can be now overridden by subclasses if we wanted. In addition, moved Utilities::shell and shellProc to ProcUtils class which is a better location and added support for running win commands

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

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

From weijun at openjdk.java.net  Wed Mar 31 13:39:16 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 31 Mar 2021 13:39:16 GMT
Subject: RFR: 8260693: Provide the support for specifying a signer in
 keytool -genkeypair
In-Reply-To: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com>
References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com>
Message-ID: 

On Wed, 31 Mar 2021 06:30:01 GMT, Hai-May Chao  wrote:

> Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate.
> CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325

Some comments on the CSR:
1. In the "Solution" section, we might need to point out that since there is no standard way to create a certificate request in this case (because the request must be signed by the owner's private key) we will not be able to enhance `-certreq` and `-gencert` to achieve the goal.
2. In the "Specification" section, "It is a required option...". I would prefer "This is especially useful when...". Also, we should not mention "JKS" since there can be other keystores using different key passwords. Just say "It can be specified if the private key of the signer entry is protected by a different password from the store password". Or you can look at how `-keypass` is described in other commands.
3. I don't think it's necessary to list `X448` and `X25519` in the "Default key size" section since that's the only key size for the algorithms. We only need to say `255 (when using -genkeypair and -keyalg is "EdDSA" or "XDH")`.

src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 114:

> 112:     }
> 113: 
> 114:     /**

The original constructor can be modified to call `this(keyType,sigAlg,providerName,null,null)`. This is also a good time to modify `public CertAndKeyGen (String keyType, String sigAlg)` to call `this(keyType,sigAlg,null)`. Also please simplify the method javadoc.

src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 234:

> 232:             if (sigAlg == null) {
> 233:                 throw new IllegalArgumentException(
> 234:                         "Cannot derive signature algorithm from "

The text of the exception should be updated because a different key could be used.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1930:

> 1928:         }
> 1929: 
> 1930:         if (reqSigner && signerAlias == null) {

What if we do not use a `reqSigner` flag? Will the error message be misleading. I guess it will something like "Cannot derive a signature algorithm from the key algorithm". My opinion is that it's quite enough.

If we keep it, we will have to maintain it.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1941:

> 1939:             signerFlag = true;
> 1940: 
> 1941:             if (keyStore.containsAlias(signerAlias) == false) {

It's probably more precise to make sure the entry is a `PrivateKeyEntry` because we have other entries like `TrustedCertificateEntry` and `SecretKeyEntry`. Or you can double check this below to ensure both `signerPrivateKey` and `signerCert` are non null.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1951:

> 1949:                     (PrivateKey)recoverKey(signerAlias, storePass, signerKeyPass).fst;
> 1950:             Certificate signerCert = keyStore.getCertificate(signerAlias);
> 1951:             byte[] encoded = signerCert.getEncoded();

Most likely `signerCert` is already a `X509CertImpl`.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2013:

> 2011:         }
> 2012: 
> 2013:         X509Certificate[] chain = new X509Certificate[1];

Since the chain might contain one, I'd suggest we just declare a `newCert` here. When signer flag is not on, we can simply get the chain with `new Certificate[] {newCert}`.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2025:

> 2023:                     ("Generating.keysize.bit.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.validality.days.for"));
> 2024:             if (groupName != null) {
> 2025:                 keysize = KeyUtil.getKeySize(privKey);

Don't understand why `keysize` only needs to be calculated when there is no signer flag. In fact, we can just always use the `getKeySize` output below.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2043:

> 2041:         if (signerFlag) {
> 2042:             Certificate[] signerChain = keyStore.getCertificateChain(signerAlias);
> 2043:             Certificate[] tmpChain = new X509Certificate[signerChain.length + 1];

This is not a temp chain, it's the final chain.

src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 312:

> 310:                 "Generating {0} bit {1} key pair and self-signed certificate ({2}) with a validity of {3} days\n\tfor: {4}"},
> 311:         {"Generating.keysize.bit.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.an.entry.specified.by.the.signer.option.with.a.validity.of.validality.days.for",
> 312:                 "Generating {0} bit {1} key pair and a certificate ({2}) issued by an entry specified by the -signer option with a validity of {3} days\n\tfor: {4}"},

How about printing out signer's alias?

src/java.base/share/classes/sun/security/util/KeyUtil.java line 102:

> 100:             size = pubk.getParams().getP().bitLength();
> 101:         } else if (key instanceof XECKey) {
> 102:             String name = ((NamedParameterSpec)((XECKey) key).getParams()).getName();

I hope the params is always `NamedParameterSpec` but would rather be safe to check instanceof first.

test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 230:

> 228:     }
> 229: 
> 230:     static void testSignerJKS() throws Exception {

Please add some comments on why testing with JKS is necessary.

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

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

From valeriep at openjdk.java.net  Wed Mar 31 16:55:23 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 31 Mar 2021 16:55:23 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: <2KhtRp_kHPcx_YIF67BL1e2ldskod81nRSrjbUXFbUU=.3743305b-76e0-4d83-9680-e2504ed34e17@github.com>

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 68:

> 66:         ByteBuffer cipherText =
> 67:                 ByteBuffer.allocate(((inputSize / 16 ) + 1) * 16);
> 68:         byte[] tmp = new byte[16];

Seems no need to do new byte[] given how it's used.

test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 78:

> 76:                         updateLength);
> 77:                 if (tmp != null)
> 78:                     cipherText.put(tmp);

nit: either use "{ }" or move cipherText.put() call to the same line as if-check.

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

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

From valeriep at openjdk.java.net  Wed Mar 31 17:03:08 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 31 Mar 2021 17:03:08 GMT
Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption
 when the underlying mechanism has no padding [v2]
In-Reply-To: 
References: 
 
Message-ID: <7Rw1crXLanfl1cKWHtYq6Xqw-cOemmPfAgmj_fZ_2r8=.032a9f40-89c8-429a-96ad-843022ea5837@github.com>

On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> I'd like to propose a fix for JDK-8261355 [1].
>> 
>> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Avoid overriding buffered bytes with padding in the doFinal call.
>  - Only do encryption block-size buffering for NSS
>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding

test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 97:

> 95:             throw new Exception("Cross-provider cipher test failed.");
> 96:         }
> 97:     }

Why not just use the byte[] forms for the Cipher.doFinal() and simplify this part, i.e. line 86-96?

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

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

From xuelei at openjdk.java.net  Wed Mar 31 21:00:43 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 31 Mar 2021 21:00:43 GMT
Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without
 producing any further output
Message-ID: 

As described in the bug, by connecting the SSLEngine with a misbehaving peer SSL implementation, it can get into a state where it calling `wrap` reports getStatus == OK, getHandshakeStatus === NEED_WRAP but still doesn't produce any further output.   It happens when the output bound is not empty.

The handshake status could have more precise status if the out bound.  The patch was confirmed by the bug submitter.

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

Commit messages:
 - 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output

Changes: https://git.openjdk.java.net/jdk/pull/3292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3292&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263779
  Stats: 44 lines in 3 files changed: 21 ins; 1 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3292/head:pull/3292

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

From ascarpino at openjdk.java.net  Wed Mar 31 21:54:28 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 31 Mar 2021 21:54:28 GMT
Subject: RFR: 8262316: Reducing locks in RSA Blinding
Message-ID: 

Hi,

I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation.  The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using.  The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used.  Performance doubles under high load.

thanks

Tony

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

Commit messages:
 - change putIfAbsent usage to minimize competing threads
 - add loop to check the queue on reset
 - add comment, cleanup
 - minor update
 - queue idea

Changes: https://git.openjdk.java.net/jdk/pull/3296/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3296&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262316
  Stats: 82 lines in 1 file changed: 39 ins; 16 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3296.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3296/head:pull/3296

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