From Matthew.Carter at microsoft.com Thu Jun 1 00:59:37 2023 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Thu, 1 Jun 2023 00:59:37 +0000 Subject: Read only KeyStores? Message-ID: Currently on Windows to access the local machine KeyStores (Windows-MY-LOCALMACHINE and Windows-ROOT-LOCALMACHINE) you need administrator privileges. To reduce the need to grant admin privileges to Java applications, I'm proposing that we allow the application to access readonly versions of the KeyStores. I'm considering this feature mainly for Windows but am open to general support. However, when looking at how to do this I see two obvious options, but am asking for other options that may fit the API better 1. Simply duplicate the service strings and append "-READONLY". 2. Get the Provider.Service instance and construct a new KeyStore with a parameter to indicate readonly access. Personally, I'm not fond of (1) as its parameterizing the KeyStore string [I already did this with "-LOCALMACHINE"]. However, (2) won't work as the KeyStore constructor (KeyStoreSpi, Provider, String type) is protected Is it possible to change the protection on the constructor, or provide a new constructor? (given that the String type is redundant as it should always be "KeyStore") Any thoughts/concerns about this ? Cheers Mat Sent from Outlook -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Thu Jun 1 04:31:49 2023 From: ecki at zusammenkunft.net (Bernd) Date: Thu, 1 Jun 2023 06:31:49 +0200 Subject: Read only KeyStores? In-Reply-To: References: Message-ID: <52B098D6-BB7A-5242-AEF2-00F24250FF37@hxcore.ol> An HTML attachment was scrubbed... URL: From ssahoo at openjdk.org Thu Jun 1 07:37:38 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 1 Jun 2023 07:37:38 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v4] In-Reply-To: References: Message-ID: > Additional Tests for KEM API. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Comments addressed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14113/files - new: https://git.openjdk.org/jdk/pull/14113/files/610156ce..f70d1498 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=02-03 Stats: 53 lines in 3 files changed: 27 ins; 16 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/14113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14113/head:pull/14113 PR: https://git.openjdk.org/jdk/pull/14113 From ssahoo at openjdk.org Thu Jun 1 07:37:39 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 1 Jun 2023 07:37:39 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v3] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 13:00:15 GMT, Weijun Wang wrote: >> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: >> >> 8308711: Comment addressed > > test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 45: > >> 43: * X448 produce keysize of 64 bytes which is larger in it's class >> 44: * secp521r1 produce keysize of 64 bytes which is larger in it's class >> 45: */ > > I don't quite understand what the comment mean. Removed this comment. > test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 64: > >> 62: private static KeyPair genKeyPair(String algo, String curveId) throws Exception { >> 63: KeyPairGenerator kpg = KeyPairGenerator.getInstance(algo); >> 64: kpg.initialize(new ECGenParameterSpec(curveId)); > > Although `ECGenParameterSpec` is a `NamedParameterSpec`, we usually don't create XDH keys using it. How about following the same style in `KemTest` and only call `initialize` when it's EC. For XDH, just use `X448` as the `algo` and there is no need to initialize it. Done. > test/jdk/javax/crypto/KEM/KemTest.java line 129: > >> 127: Asserts.assertEQ(encT.encapsulationSize(), decT.encapsulationSize()); >> 128: Asserts.assertEQ(encT.secretSize(), enc.key().getEncoded().length); >> 129: Asserts.assertEQ(encT.secretSize(), decT.secretSize()); > > Since the decapsulator also has `secretSize` and `encapsulationSize` methods, you can add some more lines testing the output of them as well. Done. > test/jdk/javax/crypto/KEM/KemTest.java line 195: > >> 193: Callable task = () -> { >> 194: return kem.newEncapsulator(kp.getPublic()); >> 195: }; > > Just use `() -> kem.newEncapsulator(kp.getPublic())`. Same on lines 229, 262, 300. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1212714688 PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1212715230 PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1212715626 PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1212715868 From adinn at openjdk.org Thu Jun 1 12:21:10 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 1 Jun 2023 12:21:10 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 16:17:14 GMT, Andrew Haley wrote: >> This provides a solid speedup of about 3-4x over the Java implementation. >> >> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. >> >> Benchmarks: >> >> >> ThunderX (2, I think): >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s >> >> Apple M1: >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s >> Poly1305DigestBench.upd... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Review comments src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7135: > 7133: regs = (regs.remaining() + U_0HI + U_1HI).begin(); > 7134: > 7135: // U_2:U_1:U_0 += (U_1HI >> 2) This comment and the next one both need correcting. They mention U_0HI and U_1HI and, as the previous comment says, those registers are dead. What actually happens here is best summarized as // U_2:U_1:U_0 += (U2 >> 2) * 5 or, if we actually want to be clearer about the current encoding which does it in several steps // rscratch1 = (U2 >> 2) // U2 = U2[1:0] // U_2:U_1:U_0 += rscratch1 // U_2:U_1:U_0 += (rscratch1 << 2) i.e. any bits that are set from 130 upwards are masked off, treated as an integer in their own right, multiplied by 5 and the result added back in at the bottom to update the 130 bit result U2[1:0]:U1[63:0]:U0[63:0]. I'm not sure whether this provides an opportunity for you to optimize this by doing the multiply by five earlier i.e. replace the code with this version // rscratch1 = (U2 >> 2) * 5 __ lsr(rscratch1, U_2, 2); __ add(rscratch1, rscratch1, scratch1, Assembler::LSL, 2); // U2 = U2[1:0] __ andr(U_2, U_2, (u8)3); // U2:U1:U0 += rscratch1 __ adds(U_0, U_0, rscratch1); __ adcs(U_1, U_1, zr); __ adc(U_2, U_2, zr); The obvious concern is that the multiply of rscratch1 by 5 might overflow 64 bits. Is that why you have implemented two add and carry steps? If so then why is it legitimate to do the multiply by 5 up front in the final reduction that follows the loop? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1213062966 From duke at openjdk.org Thu Jun 1 12:34:53 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 1 Jun 2023 12:34:53 GMT Subject: Integrated: 8298127: HSS/LMS Signature Verification In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:16:34 GMT, Ferenc Rakoczi wrote: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. This pull request has now been integrated. Changeset: 050425b1 Author: Ferenc Rakoczi Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/050425b141d710659928020dd89f94ed46c056a6 Stats: 924 lines in 5 files changed: 919 ins; 0 del; 5 mod 8298127: HSS/LMS Signature Verification Reviewed-by: weijun, mullan ------------- PR: https://git.openjdk.org/jdk/pull/13691 From mpowers at openjdk.org Thu Jun 1 14:13:25 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 1 Jun 2023 14:13:25 GMT Subject: Integrated: JDK-8307794 Test for HSS/LMS Signature Verification In-Reply-To: References: Message-ID: <5f85wGg74fdu2_HPb6GzXPxyr6xy1bpZ9Wg7xj5jh4A=.df14e942-2cf5-4fd2-a4df-c945426d7546@github.com> On Thu, 11 May 2023 19:06:59 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8307794 This pull request has now been integrated. Changeset: d9871764 Author: Mark Powers Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/d987176412b0a1812c9b99aaaeaf65ac96fa05be Stats: 4567 lines in 3 files changed: 4567 ins; 0 del; 0 mod 8307794: Test for HSS/LMS Signature Verification Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/13940 From weijun at openjdk.org Thu Jun 1 14:21:12 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 Jun 2023 14:21:12 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v4] In-Reply-To: References: Message-ID: <09juljZS00pF-a2baEfa_c0rfK_9XBTAVtbFDQrjyek=.faf92faf-f9c4-4c3a-98c7-fb4ae969993a@github.com> On Thu, 1 Jun 2023 07:37:38 GMT, Sibabrata Sahoo wrote: >> Additional Tests for KEM API. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Comments addressed test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 79: > 77: sk.getEncoded())); > 78: Asserts.assertTrue(Arrays.equals(d.decapsulate(enc.encapsulation()).getEncoded(), > 79: enc.key().getEncoded())); Do you really mean to test this 3 times? If so, add a comment. test/jdk/javax/crypto/KEM/KemTest.java line 138: > 136: decT.decapsulate(enc.encapsulation()).getEncoded().length); > 137: Asserts.assertEQ(decT.decapsulate(enc.encapsulation()).getEncoded().length, > 138: enc.key().getEncoded().length); Try adding a test on the `encapsulationSize()` method on the decapsulator. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1213229215 PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1213232120 From weijun at openjdk.org Thu Jun 1 14:38:09 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 Jun 2023 14:38:09 GMT Subject: RFR: 8308592: Update CA interop test certificates [v3] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: On Wed, 31 May 2023 22:46:53 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > 8308592: remove unused imports After this change, do all tests look exactly the same with only different URLs and CA alias names? If yes, can we just combine them into one test? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14252#issuecomment-1572175941 From weijun at openjdk.org Thu Jun 1 14:51:10 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 Jun 2023 14:51:10 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 07:37:38 GMT, Sibabrata Sahoo wrote: >> Additional Tests for KEM API. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Comments addressed Looks good to me. Thanks! ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14113#pullrequestreview-1455667123 From ssahoo at openjdk.org Thu Jun 1 14:51:14 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 1 Jun 2023 14:51:14 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v4] In-Reply-To: <09juljZS00pF-a2baEfa_c0rfK_9XBTAVtbFDQrjyek=.faf92faf-f9c4-4c3a-98c7-fb4ae969993a@github.com> References: <09juljZS00pF-a2baEfa_c0rfK_9XBTAVtbFDQrjyek=.faf92faf-f9c4-4c3a-98c7-fb4ae969993a@github.com> Message-ID: <7SxnmI5FFr_knBO6RwTbOLZEKG5Ry5UyJFJyS8YH5tY=.56c06244-77e1-4935-b19e-8f47e84f54f8@github.com> On Thu, 1 Jun 2023 14:16:23 GMT, Weijun Wang wrote: >> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: >> >> Comments addressed > > test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 79: > >> 77: sk.getEncoded())); >> 78: Asserts.assertTrue(Arrays.equals(d.decapsulate(enc.encapsulation()).getEncoded(), >> 79: enc.key().getEncoded())); > > Do you really mean to test this 3 times? If so, add a comment. Yes.. Thats a valid case to ensure repeated calls don't change anything. I can add a comment there. > test/jdk/javax/crypto/KEM/KemTest.java line 138: > >> 136: decT.decapsulate(enc.encapsulation()).getEncoded().length); >> 137: Asserts.assertEQ(decT.decapsulate(enc.encapsulation()).getEncoded().length, >> 138: enc.key().getEncoded().length); > > Try adding a test on the `encapsulationSize()` method on the decapsulator. It is there L-130,131, Do you want any specific case? Asserts.assertEQ(encT.encapsulationSize(), enc.encapsulation().length); Asserts.assertEQ(encT.encapsulationSize(), decT.encapsulationSize()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1213272940 PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1213270800 From weijun at openjdk.org Thu Jun 1 14:51:15 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 Jun 2023 14:51:15 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v4] In-Reply-To: <7SxnmI5FFr_knBO6RwTbOLZEKG5Ry5UyJFJyS8YH5tY=.56c06244-77e1-4935-b19e-8f47e84f54f8@github.com> References: <09juljZS00pF-a2baEfa_c0rfK_9XBTAVtbFDQrjyek=.faf92faf-f9c4-4c3a-98c7-fb4ae969993a@github.com> <7SxnmI5FFr_knBO6RwTbOLZEKG5Ry5UyJFJyS8YH5tY=.56c06244-77e1-4935-b19e-8f47e84f54f8@github.com> Message-ID: On Thu, 1 Jun 2023 14:44:53 GMT, Sibabrata Sahoo wrote: >> test/jdk/javax/crypto/KEM/KemTest.java line 138: >> >>> 136: decT.decapsulate(enc.encapsulation()).getEncoded().length); >>> 137: Asserts.assertEQ(decT.decapsulate(enc.encapsulation()).getEncoded().length, >>> 138: enc.key().getEncoded().length); >> >> Try adding a test on the `encapsulationSize()` method on the decapsulator. > > It is there L-130,131, Do you want any specific case? > Asserts.assertEQ(encT.encapsulationSize(), enc.encapsulation().length); > Asserts.assertEQ(encT.encapsulationSize(), decT.encapsulationSize()); Oh sorry, I just looked at the left side of `assertEQ`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1213273898 From asemenov at openjdk.org Thu Jun 1 15:01:37 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 1 Jun 2023 15:01:37 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v4] In-Reply-To: References: Message-ID: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14033/files - new: https://git.openjdk.org/jdk/pull/14033/files/d5b70cb2..b423bd4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=02-03 Stats: 7 lines in 2 files changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From aph at openjdk.org Thu Jun 1 15:03:13 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 1 Jun 2023 15:03:13 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 12:16:45 GMT, Andrew Dinn wrote: > This comment and the next one both need correcting. They mention U_0HI and U_1HI and, as the previous comment says, those registers are dead. > > What actually happens here is best summarized as > > // U_2:U_1:U_0 += (U2 >> 2) * 5 > > or, if we actually want to be clearer about the current encoding which does it in several steps > > // rscratch1 = (U2 >> 2) // U2 = U2[1:0] // U_2:U_1:U_0 += rscratch1 // U_2:U_1:U_0 += (rscratch1 << 2) > > i.e. any bits that are set from 130 upwards are masked off, treated as an integer in their own right, multiplied by 5 and the result added back in at the bottom to update the 130 bit result U2[1:0]:U1[63:0]:U0[63:0]. OK. > I'm not sure whether this provides an opportunity for you to optimize this by doing the multiply by five earlier i.e. replace the code with this version I'm not sure either, which is why it's done in two separate steps. I think you may be right, but it's a bit late to be optimizing this version any further. That would require careful analysis and a redo of all the testing. > The obvious concern is that the multiply of rscratch1 by 5 might overflow 64 bits. Is that why you have implemented two add and carry steps? Indeed. > If so then why is it legitimate to do the multiply by 5 up front in the final reduction that follows the loop? I assume that you're referring to the multiply by 5 in // Further reduce modulo 2^130 - 5 __ lsr(rscratch1, U_2, 2); __ add(rscratch1, rscratch1, rscratch1, Assembler::LSL, 2); // rscratch1 = U_2 * 5 ` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1213294906 From asemenov at openjdk.org Thu Jun 1 15:07:11 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 1 Jun 2023 15:07:11 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v3] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 13:52:39 GMT, Weijun Wang wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/java.security.jgss/share/native/libj2gss/gssapi.h line 47: > >> 45: >> 46: // Condition was copied from >> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h > > In the current version of the file above, it's written as > > #if defined(__APPLE__) && (defined(__ppc__) ||... > > Is it better? done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1213297788 From weijun at openjdk.org Thu Jun 1 15:07:12 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 Jun 2023 15:07:12 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v3] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:02:16 GMT, Artem Semenov wrote: >> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47: >> >>> 45: >>> 46: // Condition was copied from >>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h >> >> In the current version of the file above, it's written as >> >> #if defined(__APPLE__) && (defined(__ppc__) ||... >> >> Is it better? > > done I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1213300305 From aph at openjdk.org Thu Jun 1 16:09:07 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 1 Jun 2023 16:09:07 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:00:26 GMT, Andrew Haley wrote: > This comment and the next one both need correcting. They mention U_0HI and U_1HI and, as the previous comment says, those registers are dead. > > What actually happens here is best summarized as > > // U_2:U_1:U_0 += (U2 >> 2) * 5 > > or, if we actually want to be clearer about the current encoding which does it in several steps > > // rscratch1 = (U2 >> 2) // U2 = U2[1:0] // U_2:U_1:U_0 += rscratch1 // U_2:U_1:U_0 += (rscratch1 << 2) > > i.e. any bits that are set from 130 upwards are masked off, treated as an integer in their own right, multiplied by 5 and the result added back in at the bottom to update the 130 bit result U2[1:0]:U1[63:0]:U0[63:0]. OK. > I'm not sure whether this provides an opportunity for you to optimize this by doing the multiply by five earlier i.e. replace the code with this version I'm not sure either, which is why it's done in two separate steps. I think you may be right, but it's a bit late to be optimizing this version any further. That would require careful analysis and a redo of all the testing. > The obvious concern is that the multiply of rscratch1 by 5 might overflow 64 bits. Is that why you have implemented two add and carry steps? Indeed. > If so then why is it legitimate to do the multiply by 5 up front in the final reduction that follows the loop? I assume that you're referring to the multiply by 5 in // Further reduce modulo 2^130 - 5 __ lsr(rscratch1, U_2, 2); __ add(rscratch1, rscratch1, rscratch1, Assembler::LSL, 2); // rscratch1 = U_2 * 5 `U_2`, at this point, has only a few lower set bits. This is because `U_2` was previously ANDed with 3, and subsequently was the target of adc(U_2, U_2, zr). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1213382344 From aph at openjdk.org Thu Jun 1 16:16:32 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 1 Jun 2023 16:16:32 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v5] In-Reply-To: References: Message-ID: > This provides a solid speedup of about 3-4x over the Java implementation. > > I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. > > Benchmarks: > > > ThunderX (2, I think): > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s > > Apple M1: > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s > Poly1305DigestBench.updateBytes 256 th... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14085/files - new: https://git.openjdk.org/jdk/pull/14085/files/93a03c62..87c1eff7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=03-04 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14085/head:pull/14085 PR: https://git.openjdk.org/jdk/pull/14085 From macarte at openjdk.org Thu Jun 1 16:56:05 2023 From: macarte at openjdk.org (Mat Carter) Date: Thu, 1 Jun 2023 16:56:05 GMT Subject: RFR: 8306688: Support Windows serialized keystores (SST files) In-Reply-To: References: Message-ID: On Fri, 26 May 2023 21:09:35 GMT, Mat Carter wrote: > Added ability to load keystores from SST files on Windows. Example usage: > > KeyStore keyStore = KeyStore.getInstance("Windows-SST"); > try (FileInputStream fis = new FileInputStream("mykeystore.sst")) { > keyStore.load(fis, null); > } > > Note that its not limited to file streams, it can be any stream. > > The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional > > tier1 tests for linux/macos/Windows for x86_64 The SunMSCAPI CKeyStore which implements KeyStoreSpi does nothing in the engineStore, ie. its essential a NOP (No Operation), so right now the dev cannot overwrite original SST file ------------- PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1572417325 From rhalade at openjdk.org Thu Jun 1 16:59:06 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 Jun 2023 16:59:06 GMT Subject: RFR: 8308592: Update CA interop test certificates [v3] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: On Wed, 31 May 2023 22:46:53 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > 8308592: remove unused imports > There are few minor differences but most of them will all look the same. I kept them separate so we can treat each CA differently and run / problem list at granular level. I will try to reduce the duplicate code further. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14252#issuecomment-1572424021 From weijun at openjdk.org Thu Jun 1 17:10:06 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 Jun 2023 17:10:06 GMT Subject: RFR: 8306688: Support Windows serialized keystores (SST files) In-Reply-To: References: Message-ID: <47yid3oo6aAdOJgx59J7JEygPx4bau0i_nyjl9Fesbg=.a563ecb9-e1c4-4e2e-8601-5e16b6f3ab95@github.com> On Fri, 26 May 2023 21:09:35 GMT, Mat Carter wrote: > Added ability to load keystores from SST files on Windows. Example usage: > > KeyStore keyStore = KeyStore.getInstance("Windows-SST"); > try (FileInputStream fis = new FileInputStream("mykeystore.sst")) { > keyStore.load(fis, null); > } > > Note that its not limited to file streams, it can be any stream. > > The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional > > tier1 tests for linux/macos/Windows for x86_64 But the `store` method works on an output stream. Once you've created a `new FileOutputStream(fileName)`, even if you do nothing later, the file is already overwritten. Try keytool with your new keystore type and see what happens if you make any modification, say, `keytool -changealias`. (I haven't tried. I haven't tried your code on a Windows machine yet). ------------- PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1572451281 From macarte at openjdk.org Thu Jun 1 17:14:08 2023 From: macarte at openjdk.org (Mat Carter) Date: Thu, 1 Jun 2023 17:14:08 GMT Subject: RFR: 8306688: Support Windows serialized keystores (SST files) In-Reply-To: References: Message-ID: On Fri, 26 May 2023 21:09:35 GMT, Mat Carter wrote: > Added ability to load keystores from SST files on Windows. Example usage: > > KeyStore keyStore = KeyStore.getInstance("Windows-SST"); > try (FileInputStream fis = new FileInputStream("mykeystore.sst")) { > keyStore.load(fis, null); > } > > Note that its not limited to file streams, it can be any stream. > > The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional > > tier1 tests for linux/macos/Windows for x86_64 Thanks for the explanation, I understand your point now. I'll make changes to support writing to the SST ------------- PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1572458983 From weijun at openjdk.org Thu Jun 1 17:21:04 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 Jun 2023 17:21:04 GMT Subject: RFR: 8306688: Support Windows serialized keystores (SST files) In-Reply-To: References: Message-ID: On Fri, 26 May 2023 21:09:35 GMT, Mat Carter wrote: > Added ability to load keystores from SST files on Windows. Example usage: > > KeyStore keyStore = KeyStore.getInstance("Windows-SST"); > try (FileInputStream fis = new FileInputStream("mykeystore.sst")) { > keyStore.load(fis, null); > } > > Note that its not limited to file streams, it can be any stream. > > The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional > > tier1 tests for linux/macos/Windows for x86_64 If you thinking it's worth implementing the write side, that's good. What happens if you put a private key entry there? Is it also supported? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1572474757 From duke at openjdk.org Thu Jun 1 17:58:07 2023 From: duke at openjdk.org (Bernd) Date: Thu, 1 Jun 2023 17:58:07 GMT Subject: RFR: 8306688: Support Windows serialized keystores (SST files) In-Reply-To: References: Message-ID: <8kpJ0UEyuAkdmC4e6_zD5p-9mLyW_s7J3GnVSRFue4U=.210ff507-f228-4537-8ffd-78d679c26694@github.com> On Fri, 26 May 2023 21:09:35 GMT, Mat Carter wrote: > Added ability to load keystores from SST files on Windows. Example usage: > > KeyStore keyStore = KeyStore.getInstance("Windows-SST"); > try (FileInputStream fis = new FileInputStream("mykeystore.sst")) { > keyStore.load(fis, null); > } > > Note that its not limited to file streams, it can be any stream. > > The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional > > tier1 tests for linux/macos/Windows for x86_64 Can a SST file actually contain keys? According to the Powershell page you linked it only exports certs. ------------- PR Review: https://git.openjdk.org/jdk/pull/14187#pullrequestreview-1456015518 From mullan at openjdk.org Thu Jun 1 19:32:06 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 1 Jun 2023 19:32:06 GMT Subject: RFR: 8308592: Update CA interop test certificates [v3] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: On Wed, 31 May 2023 22:46:53 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > 8308592: remove unused imports I suggest changing the title and description of the bug as the fix is more significant than updating a few expired certificates. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14252#issuecomment-1572656304 From rhalade at openjdk.org Thu Jun 1 20:09:39 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 Jun 2023 20:09:39 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v4] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: 8308592: Framework for CA interoperability testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14252/files - new: https://git.openjdk.org/jdk/pull/14252/files/71811873..ca76cf3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=02-03 Stats: 695 lines in 16 files changed: 144 ins; 406 del; 145 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From rhalade at openjdk.org Thu Jun 1 20:14:28 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 Jun 2023 20:14:28 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v5] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: minor cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14252/files - new: https://git.openjdk.org/jdk/pull/14252/files/ca76cf3d..8a919ded Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=03-04 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From mullan at openjdk.org Thu Jun 1 20:28:18 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 1 Jun 2023 20:28:18 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v4] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: On Thu, 1 Jun 2023 20:09:39 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > 8308592: Framework for CA interoperability testing test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 28: > 26: * @param revocationMode revocation checking mode to use > 27: */ > 28: public CAInterop(String revocationMode){ You could have instead added a static method to `ValidatePathWithURL`. test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 33: > 31: } if ("OCSP".equalsIgnoreCase(revocationMode)) { > 32: ValidatePathWithURL.enableOCSPOnly(); > 33: }else { Nit: space after `}`. test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 47: > 45: * @throws Exception thrown when certificate can't be validated as valid or revoked > 46: */ > 47: public void validate(String caAlias, Seems like you could also add this as a static method to `ValidatePathWithURL` and then you don't need this class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213642143 PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213640495 PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213644110 From mullan at openjdk.org Thu Jun 1 20:28:14 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 1 Jun 2023 20:28:14 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v3] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: <4EjfbY-ORUruEOvD2MpgYtAfr69Dj1MtV2saA22WIuo=.566f8586-645a-4b3d-80d6-d7ea4533cbe3@github.com> On Wed, 31 May 2023 22:46:53 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > 8308592: remove unused imports test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java line 40: > 38: * @library /test/lib > 39: * @build jtreg.SkippedException > 40: * @build ValidatePathWithURL You could include these on one @build line. test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithURL.java line 62: > 60: public static void enableOCSPOnly() { > 61: System.setProperty("com.sun.security.enableCRLDP", "false"); > 62: Security.setProperty("ocsp.enable", "true"); Technically I think you could avoid setting these properties (and running in othervm mode) and instead init your `SSLContext` with a `TrustManager` and a `CertPathTrustManagerParameters` containing a `PKIXParameters` with a `PKIXRevocationChecker` configured with the desired revocation settings. However, AFAIK, you can't pass in an `SSLContext` via the `HttpsURLConnection` API, so you would need to use `HttpsClient` instead (which is only available in Java 11 and up). However, I think this is something to consider as a future enhancement, as you have more control over the various TLS settings. test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithURL.java line 99: > 97: // certain that test certificate anchors to trusted CA for VALID certificate > 98: // if the connection is successful > 99: Certificate[] chain = httpsURLConnection.getServerCertificates(); Mostly FYI - but another way to get the chain is to call the `getCertPath()` method of the thrown `CertPathValidatorException`. This doesn't include the root though. test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithURL.java line 109: > 107: System.out.println("Finding intermediate certificate issued by CA"); > 108: for (Certificate cert: chain){ > 109: if(cert instanceof X509Certificate certificate) { Nit: space after `if`. test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithURL.java line 158: > 156: throw new SkippedException("Network setup issue, skip this test", e); > 157: } finally { > 158: if(httpsURLConnection != null) { Nit: space after `if`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213598274 PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213621334 PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213634860 PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213635463 PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213636840 From rhalade at openjdk.org Thu Jun 1 21:00:55 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 Jun 2023 21:00:55 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v6] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: <9GzFFVWtH5vTq9_wlDYi1Ib5oDAHVFbdDMRQMu4Svko=.4f44987a-6686-4e55-982a-2422fc949d61@github.com> > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14252/files - new: https://git.openjdk.org/jdk/pull/14252/files/8a919ded..9d42b594 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=04-05 Stats: 78 lines in 16 files changed: 10 ins; 27 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From rhalade at openjdk.org Thu Jun 1 21:00:58 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 Jun 2023 21:00:58 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v4] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: On Thu, 1 Jun 2023 20:25:16 GMT, Sean Mullan wrote: >> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: >> >> 8308592: Framework for CA interoperability testing > > test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 47: > >> 45: * @throws Exception thrown when certificate can't be validated as valid or revoked >> 46: */ >> 47: public void validate(String caAlias, > > Seems like you could also add this as a static method to `ValidatePathWithURL` and then you don't need this class. Would prefer to leave it as a separate class for better readability. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213671356 From rhalade at openjdk.org Thu Jun 1 21:01:01 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 Jun 2023 21:01:01 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v3] In-Reply-To: <4EjfbY-ORUruEOvD2MpgYtAfr69Dj1MtV2saA22WIuo=.566f8586-645a-4b3d-80d6-d7ea4533cbe3@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> <4EjfbY-ORUruEOvD2MpgYtAfr69Dj1MtV2saA22WIuo=.566f8586-645a-4b3d-80d6-d7ea4533cbe3@github.com> Message-ID: On Thu, 1 Jun 2023 20:15:10 GMT, Sean Mullan wrote: >> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: >> >> 8308592: remove unused imports > > test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithURL.java line 99: > >> 97: // certain that test certificate anchors to trusted CA for VALID certificate >> 98: // if the connection is successful >> 99: Certificate[] chain = httpsURLConnection.getServerCertificates(); > > Mostly FYI - but another way to get the chain is to call the `getCertPath()` method of the thrown `CertPathValidatorException`. This doesn't include the root though. Thanks! This will allow me to validate anchor on revoked/expired certificate as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14252#discussion_r1213667728 From valeriep at openjdk.org Thu Jun 1 21:07:21 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 1 Jun 2023 21:07:21 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Sat, 27 May 2023 06:24:36 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao As someone who is familiar with the Cipher convention, it's clearer to apply the Cipher convention across the board, i.e. for Mac and SecretKeyFactory too. For example: For SecretKeyFactory.PBEWithHmacSHA1AndAES_128, use `CKM_PKCS5_PBKD2 (required CKM_SHA_1_HMAC)` instead of `CKM_PKCS5_PBKD2 and CKM_SHA_1_HMAC`. The listed mechanism is the one the impl maps to or based on. The required mechanism is for auxiliary functionalities. Putting the auxiliary one inside the required brackets seems clearer than combining them with the "and" word. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1572781909 From rhalade at openjdk.org Thu Jun 1 21:46:25 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 Jun 2023 21:46:25 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v7] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: Fix typos and reformat code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14252/files - new: https://git.openjdk.org/jdk/pull/14252/files/9d42b594..e64e32fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=05-06 Stats: 22 lines in 7 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From duke at openjdk.org Thu Jun 1 22:10:22 2023 From: duke at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 1 Jun 2023 22:10:22 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 22:06:04 GMT, Francisco Ferrari Bihurriet wrote: >> src/java.base/share/classes/sun/security/util/PBEUtil.java line 105: >> >>> 103: "needed for decryption"); >>> 104: } >>> 105: } >> >> Isn't there also default value for iteration count? 'params' can be PBEParameterSpec (line 82) but its salt and iteration count values aren't used comparing to the IvParameterSpec inside. Seems a bit inconsistent? > > @valeriepeng: I agree, `DEFAULT_ITERATIONS` should be used here and only here, so we consistently initialize any defaults in a single place. We'll update that. There are cases in which _salt_ and _iteration count_ come from the _key_ (`javax.crypto.interfaces.PBEKey`), so `PBES2Params.initialize()` shouldn't try to extract them from `params` (when it is `PBEParameterSpec`). To solve the inconsistency, and in line with your other comment, let's allow `params` to only be `IvParameterSpec`. But let's still receive it as `AlgorithmParameterSpec`, so we can check its type here (and make it simpler for callers), where only `IvParameterSpec` is allowed (plus `null` when encrypting). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1213728625 From duke at openjdk.org Thu Jun 1 22:10:21 2023 From: duke at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 1 Jun 2023 22:10:21 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 22:03:44 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/java.base/share/classes/sun/security/util/PBEUtil.java line 105: > >> 103: "needed for decryption"); >> 104: } >> 105: } > > Isn't there also default value for iteration count? 'params' can be PBEParameterSpec (line 82) but its salt and iteration count values aren't used comparing to the IvParameterSpec inside. Seems a bit inconsistent? @valeriepeng: I agree, `DEFAULT_ITERATIONS` should be used here and only here, so we consistently initialize any defaults in a single place. We'll update that. > src/java.base/share/classes/sun/security/util/PBEUtil.java line 182: > >> 180: // salt should be non-null per PBEParameterSpec >> 181: iCountInit = check(pbeParams.getIterationCount()); >> 182: saltInit = check(pbeParams.getSalt()); > > Why not override params with the IvParameterSpec inside the PBEParameterSpec here? Then the PBES2Params.initialize(...) method does not need to handle PBEParameterSpec type? Seems more consistent this way. @valeriepeng: I agree, the only downside I see is that we'll need to do the same `pbeParams.getParameterSpec()` extraction before [this `PBES2Params.initialize()` call](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java#L144-L146). But for this case, it's clearly more consistent to have the extraction here. We'll address this in the next iteration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1213728201 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1213728793 From duke at openjdk.org Thu Jun 1 23:50:20 2023 From: duke at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 1 Jun 2023 23:50:20 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 23:42:24 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 221: > >> 219: // for the underlying cipher is equal to the PBE service key length. >> 220: // Otherwise, initialization fails. >> 221: return svcPbeKi.keyLen; > > This method "Returns the key size of the given key object in bits. " > How do you ensure that this key is the one used in the initialization? This method may also throw InvalidKeyException though, With this impl, even if passing a null key, this would return an int value and not detecting the key is invalid. @valeriepeng: the rationale behind this decision is based on the only usage of `engineGetKeySize()`, which corresponds to a [`crypto.policy=limited` _Cryptographic Jurisdiction Policy_](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/conf/security/java.security#L906-L942). Here, `engineGetKeySize()` is employed to check the key during the _Cipher_ initialization (see [`Cipher.java:1463`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1463), [`Cipher.java:1110`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1110), [`Cipher.java:1139`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1139)). So, what we can assert is that if the key size isn't going to be `svcPbeKi.keyLen`, then that very sa me _Cipher_ initialization will later fail anyway. There also is a previous precedent set by _SunJCE_: https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java#L214-L216 https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java#L377-L379 https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e//src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java#L355-L358 https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e//src/java.base/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java#L367-L371 NOTE: by passing `-Djava.security.properties=<(echo crypto.policy=limited)` as a JVM argument to [`test/jdk/sun/security/pkcs11/Cipher/PBECipher.java`](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java#L191), I could reproduce a failure of the [older implementation using the underlying cipher](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java#L210-L215): if we pass a `com.sun.crypto.provider.PBEKey` of the [`PBE` → `PBEWithMD5AndDES`](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java#L279) algorithm, the [underlying `AES` cipher's `P11SecretKeyFactory.convertKey()` call](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/src/jdk.crypto.cryptoki/share/classes/sun/security/pk cs11/P11Cipher.java#L1021-L1022) fails because this algorithm is not registered in the `P11SecretKeyFactory.keyInfo` map, so [`ki` is `null` here](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L292-L295), resulting in `InvalidKeyException: Cannot use a PBEWithMD5AndDES key for a AES service`. I've also found a failure for the current implementation when using `crypto.policy=limited`, I will investigate this further tomorrow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1213781875 From duke at openjdk.org Fri Jun 2 00:11:17 2023 From: duke at openjdk.org (Francisco Ferrari Bihurriet) Date: Fri, 2 Jun 2023 00:11:17 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 21:04:32 GMT, Valerie Peng wrote: > For example: For SecretKeyFactory.PBEWithHmacSHA1AndAES_128, use `CKM_PKCS5_PBKD2 (required CKM_SHA_1_HMAC)` instead of `CKM_PKCS5_PBKD2 and CKM_SHA_1_HMAC`. Ah, ok, now I see. Unfortunately I don't yet have a JBS user, but I'll send the updated text to @martinuy so he can quickly update [JDK-8308719](https://bugs.openjdk.org/browse/JDK-8308719) when he is back on Monday. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1572944221 From duke at openjdk.org Fri Jun 2 00:36:23 2023 From: duke at openjdk.org (Francisco Ferrari Bihurriet) Date: Fri, 2 Jun 2023 00:36:23 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 21:04:32 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > As someone who is familiar with the Cipher convention, it's clearer to apply the Cipher convention across the board, i.e. for Mac and SecretKeyFactory too. > For example: For SecretKeyFactory.PBEWithHmacSHA1AndAES_128, use > `CKM_PKCS5_PBKD2 (required CKM_SHA_1_HMAC)` instead of `CKM_PKCS5_PBKD2 and CKM_SHA_1_HMAC`. > > The listed mechanism is the one the impl maps to or based on. The required mechanism is for auxiliary functionalities. Putting the auxiliary one inside the required brackets seems clearer than combining them with the "and" word. @valeriepeng: if the following format looks good to you, I'll pass the update to @martinuy:
Java Algorithm PKCS#11 Mechanisms
Cipher.PBEWithHmacSHA1AndAES_128 CKM_AES_CBC_PAD, CKM_AES_CBC (requires CKM_PKCS5_PBKD2 and CKM_SHA_1_HMAC)
[…] […]
Mac.HmacPBESHA1 CKM_SHA_1_HMAC (requires CKM_PBA_SHA1_WITH_SHA1_HMAC)
[…] […]
SecretKeyFactory.HmacPBESHA1 CKM_PBA_SHA1_WITH_SHA1_HMAC
[…] […]
SecretKeyFactory.PBKDF2WithHmacSHA224 CKM_PKCS5_PBKD2 (requires CKM_SHA224_HMAC)
------------- PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1572960218 From andrew at openjdk.org Fri Jun 2 01:05:45 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 2 Jun 2023 01:05:45 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory Message-ID: Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties. There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required. This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`. As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK. The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true. A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream. ------------- Commit messages: - 8309330: Allow java.security to be extended via a properties directory Changes: https://git.openjdk.org/jdk/pull/14277/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309330 Stats: 132 lines in 3 files changed: 123 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14277.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14277/head:pull/14277 PR: https://git.openjdk.org/jdk/pull/14277 From duke at openjdk.org Fri Jun 2 01:17:21 2023 From: duke at openjdk.org (Francisco Ferrari Bihurriet) Date: Fri, 2 Jun 2023 01:17:21 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 23:47:46 GMT, Francisco Ferrari Bihurriet wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 221: >> >>> 219: // for the underlying cipher is equal to the PBE service key length. >>> 220: // Otherwise, initialization fails. >>> 221: return svcPbeKi.keyLen; >> >> This method "Returns the key size of the given key object in bits. " >> How do you ensure that this key is the one used in the initialization? This method may also throw InvalidKeyException though, With this impl, even if passing a null key, this would return an int value and not detecting the key is invalid. > > @valeriepeng: the rationale behind this decision is based on the only usage of `engineGetKeySize()`, which corresponds to a [`crypto.policy=limited` _Cryptographic Jurisdiction Policy_](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/conf/security/java.security#L906-L942). Here, `engineGetKeySize()` is employed to check the key during the _Cipher_ initialization (see [`Cipher.java:1463`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1463), [`Cipher.java:1110`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1110), [`Cipher.java:1139`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1139)). So, what we can assert is that if the key size isn't going to be `svcPbeKi.keyLen`, then that very same _Cipher_ initialization will later fail anyway. > > There also is a previous precedent set by _SunJCE_: > https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java#L214-L216 > https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java#L377-L379 > https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e//src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java#L355-L358 > https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e//src/java.base/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java#L367-L371 > > NOTE: by passing `-Djava.security.properties=<(echo crypto.policy=limited)` as a JVM argument to [`test/jdk/sun/security/pkcs11/Cipher/PBECipher.java`](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java#L191), I could reproduce a failure of the [older implementation using the underlying cipher](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java#L210-L215): if we pass a `com.sun.crypto.provider.PBEKey` of the [`PBE` → `PBEWithMD5AndDES`](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/src/java.base/share/classes... I can confirm that the failures I was seeing were caused by the `128` bits key size limit here: https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/conf/security/policy/limited/default_local.policy#L13 If I set that to `512`, [`test/jdk/sun/security/pkcs11/Cipher/PBECipher.java`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java) passes with `crypto.policy=limited`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1213815957 From abakhtin at openjdk.org Fri Jun 2 02:04:11 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Fri, 2 Jun 2023 02:04:11 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 00:57:49 GMT, Andrew John Hughes wrote: > Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties. > > There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required. > > This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`. > > As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK. > > The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true. > > A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream. src/java.base/share/classes/java/security/Security.java line 138: > 136: try { > 137: extraPropDir = PropertyExpander.expand(extraPropDir); > 138: stream = Files.find(Path.of(extraPropDir), Integer.MAX_VALUE, Hi @gnu-andrew , The order of the files, returned by File::find is not defined. Different property files can change the same security properties, and only the latest changes will be applied. So the order of the property files is important but seems not controlled by the propertiesDir option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14277#discussion_r1213841747 From ssahoo at openjdk.org Fri Jun 2 05:46:27 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Fri, 2 Jun 2023 05:46:27 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v5] In-Reply-To: References: Message-ID: > Additional Tests for KEM API. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Comment added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14113/files - new: https://git.openjdk.org/jdk/pull/14113/files/f70d1498..c452e8a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14113/head:pull/14113 PR: https://git.openjdk.org/jdk/pull/14113 From mbaesken at openjdk.org Fri Jun 2 08:09:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 2 Jun 2023 08:09:32 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage Message-ID: There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). ------------- Commit messages: - JDK-8309340 Changes: https://git.openjdk.org/jdk/pull/14280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309340 Stats: 20 lines in 2 files changed: 11 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14280/head:pull/14280 PR: https://git.openjdk.org/jdk/pull/14280 From ssahoo at openjdk.org Fri Jun 2 08:16:19 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Fri, 2 Jun 2023 08:16:19 GMT Subject: Integrated: 8308711: Develop additional Tests for KEM implementation In-Reply-To: References: Message-ID: On Wed, 24 May 2023 07:02:55 GMT, Sibabrata Sahoo wrote: > Additional Tests for KEM API. This pull request has now been integrated. Changeset: aeb53e67 Author: Sibabrata Sahoo URL: https://git.openjdk.org/jdk/commit/aeb53e67f944da17d806212b32444ebb4ce2c02e Stats: 542 lines in 3 files changed: 542 ins; 0 del; 0 mod 8308711: Develop additional Tests for KEM implementation Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/14113 From adinn at openjdk.org Fri Jun 2 09:57:06 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 2 Jun 2023 09:57:06 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v5] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 16:16:32 GMT, Andrew Haley wrote: >> This provides a solid speedup of about 3-4x over the Java implementation. >> >> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. >> >> Benchmarks: >> >> >> ThunderX (2, I think): >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s >> >> Apple M1: >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s >> Poly1305DigestBench.upd... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Review comments This is ok to push now the comments have been corrected. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14085#pullrequestreview-1457031979 From adinn at openjdk.org Fri Jun 2 09:57:09 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 2 Jun 2023 09:57:09 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 16:06:40 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7135: >> >>> 7133: regs = (regs.remaining() + U_0HI + U_1HI).begin(); >>> 7134: >>> 7135: // U_2:U_1:U_0 += (U_1HI >> 2) >> >> This comment and the next one both need correcting. They mention U_0HI and U_1HI and, as the previous comment says, those registers are dead. >> >> What actually happens here is best summarized as >> >> // U_2:U_1:U_0 += (U2 >> 2) * 5 >> >> or, if we actually want to be clearer about the current encoding which does it in several steps >> >> // rscratch1 = (U2 >> 2) >> // U2 = U2[1:0] >> // U_2:U_1:U_0 += rscratch1 >> // U_2:U_1:U_0 += (rscratch1 << 2) >> >> i.e. any bits that are set from 130 upwards are masked off, treated as an integer in their own right, multiplied by 5 and the result added back in at the bottom to update the 130 bit result U2[1:0]:U1[63:0]:U0[63:0]. >> >> I'm not sure whether this provides an opportunity for you to optimize this by doing the multiply by five earlier i.e. replace the code with this version >> >> // rscratch1 = (U2 >> 2) * 5 >> __ lsr(rscratch1, U_2, 2); >> __ add(rscratch1, rscratch1, scratch1, Assembler::LSL, 2); >> // U2 = U2[1:0] >> __ andr(U_2, U_2, (u8)3); >> // U2:U1:U0 += rscratch1 >> __ adds(U_0, U_0, rscratch1); >> __ adcs(U_1, U_1, zr); >> __ adc(U_2, U_2, zr); >> >> The obvious concern is that the multiply of rscratch1 by 5 might overflow 64 bits. Is that why you have implemented two add and carry steps? If so then why is it legitimate to do the multiply by 5 up front in the final reduction that follows the loop? > >> This comment and the next one both need correcting. They mention U_0HI and U_1HI and, as the previous comment says, those registers are dead. >> >> What actually happens here is best summarized as >> >> // U_2:U_1:U_0 += (U2 >> 2) * 5 >> >> or, if we actually want to be clearer about the current encoding which does it in several steps >> >> // rscratch1 = (U2 >> 2) // U2 = U2[1:0] // U_2:U_1:U_0 += rscratch1 // U_2:U_1:U_0 += (rscratch1 << 2) >> >> i.e. any bits that are set from 130 upwards are masked off, treated as an integer in their own right, multiplied by 5 and the result added back in at the bottom to update the 130 bit result U2[1:0]:U1[63:0]:U0[63:0]. > > OK. > >> I'm not sure whether this provides an opportunity for you to optimize this by doing the multiply by five earlier i.e. replace the code with this version > > I'm not sure either, which is why it's done in two separate steps. I think you may be right, but it's a bit late to be optimizing this version any further. That would require careful analysis and a redo of all the testing. > >> The obvious concern is that the multiply of rscratch1 by 5 might overflow 64 bits. Is that why you have implemented two add and carry steps? > > Indeed. > >> If so then why is it legitimate to do the multiply by 5 up front in the final reduction that follows the loop? > > I assume that you're referring to the multiply by 5 in > > > // Further reduce modulo 2^130 - 5 > __ lsr(rscratch1, U_2, 2); > __ add(rscratch1, rscratch1, rscratch1, Assembler::LSL, 2); // rscratch1 = U_2 * 5 > > > `U_2`, at this point, has only a few lower set bits. This is because `U_2` was previously ANDed with 3, and subsequently twice was the target of adc(U_2, U_2, zr). So I think that `U_2 <= 6`. Yes, of course, you are right that 0<= U_2 < 6 at the point where that second multiply by 5 occurs (i.e. after the loop). I believe it is safe to use the same optimization inside the loop for reasons given below. Of course it is a bit late to change this now and retest but if my reasoning is correct then we could consider updating this post release and, maybe, a backport. The only thing that needs to be determined is what value could sit in U2 when we enter the loop. That's the only important case because we already agreed that at the loop back edge that 0 <= U2 < 6. The incoming value for U2 at loop entry is derived by the following subsequence of the instruction stream __ adcs(S_1, U_1, S_1); __ adc(S_2, U_2, zr); // A.1 __ add(S_2, S_2, 1); // A.2 . . . wide_mul(U_1, U_1HI, S_0, R_1); wide_madd(U_1, U_1HI, S_1, R_0); wide_madd(U_1, U_1HI, S_2, RR_1); // B . . . __ andr(U_2, R_0, 3); // C __ mul(U_2, S_2, U_2); // D . . . __ adc(U_2, U_1HI, U_2); // E At A.1 we know that 0 <= U_2 <= 3 (since it was initialized by unpack26) So, at A.2 we know that 0 <= S2 <= 5 At B we know that 0 <= RR_1 <= (2^60 - 2^2) = FFFFFFF_FFFFFFFC (top 4 and bottom 2 bits of RR_1 are clear) So 0 <= U1_HI < 5 * FFFFFFF_FFFFFFFC = 4FFFFFFF_FFFFFFEC At C we know 0 <= U_2 <= 3 At D we know 0 <= U_2 <= 15 So at E we know that 0 <= U_2 <= 4FFFFFFF_FFFFFFEC + 15 + 1 So, the highest possible value for U_2 at loop entry is 50000000_00000002. Clearly we can shift this down by two and add without any danger of overflowing 50000000_00000002 >> 2 + 50000000_00000002 = 64000000_00000002 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1214167215 From adinn at openjdk.org Fri Jun 2 10:02:09 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 2 Jun 2023 10:02:09 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4] In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 09:51:57 GMT, Andrew Dinn wrote: >>> This comment and the next one both need correcting. They mention U_0HI and U_1HI and, as the previous comment says, those registers are dead. >>> >>> What actually happens here is best summarized as >>> >>> // U_2:U_1:U_0 += (U2 >> 2) * 5 >>> >>> or, if we actually want to be clearer about the current encoding which does it in several steps >>> >>> // rscratch1 = (U2 >> 2) // U2 = U2[1:0] // U_2:U_1:U_0 += rscratch1 // U_2:U_1:U_0 += (rscratch1 << 2) >>> >>> i.e. any bits that are set from 130 upwards are masked off, treated as an integer in their own right, multiplied by 5 and the result added back in at the bottom to update the 130 bit result U2[1:0]:U1[63:0]:U0[63:0]. >> >> OK. >> >>> I'm not sure whether this provides an opportunity for you to optimize this by doing the multiply by five earlier i.e. replace the code with this version >> >> I'm not sure either, which is why it's done in two separate steps. I think you may be right, but it's a bit late to be optimizing this version any further. That would require careful analysis and a redo of all the testing. >> >>> The obvious concern is that the multiply of rscratch1 by 5 might overflow 64 bits. Is that why you have implemented two add and carry steps? >> >> Indeed. >> >>> If so then why is it legitimate to do the multiply by 5 up front in the final reduction that follows the loop? >> >> I assume that you're referring to the multiply by 5 in >> >> >> // Further reduce modulo 2^130 - 5 >> __ lsr(rscratch1, U_2, 2); >> __ add(rscratch1, rscratch1, rscratch1, Assembler::LSL, 2); // rscratch1 = U_2 * 5 >> >> >> `U_2`, at this point, has only a few lower set bits. This is because `U_2` was previously ANDed with 3, and subsequently twice was the target of adc(U_2, U_2, zr). So I think that `U_2 <= 6`. > > Yes, of course, you are right that 0<= U_2 < 6 at the point where that second multiply by 5 occurs (i.e. after the loop). > > I believe it is safe to use the same optimization inside the loop for reasons given below. Of course it is a bit late to change this now and retest but if my reasoning is correct then we could consider updating this post release and, maybe, a backport. > > The only thing that needs to be determined is what value could sit in U2 when we enter the loop. That's the only important case because we already agreed that at the loop back edge that 0 <= U2 < 6. > > The incoming value for U2 at loop entry is derived by the following subsequence of the instruction stream > > __ adcs(S_1, U_1, S_1); > __ adc(S_2, U_2, zr); // A.1 > __ add(S_2, S_2, 1); // A.2 > . . . > wide_mul(U_1, U_1HI, S_0, R_1); wide_madd(U_1, U_1HI, S_1, R_0); wide_madd(U_1, U_1HI, S_2, RR_1); // B > . . . > __ andr(U_2, R_0, 3); // C > __ mul(U_2, S_2, U_2); // D > . . . > > __ adc(U_2, U_1HI, U_2); // E > > At A.1 we know that 0 <= U_2 <= 3 (since it was initialized by unpack26) > So, at A.2 we know that 0 <= S2 <= 5 > > At B we know that 0 <= RR_1 <= (2^60 - 2^2) = FFFFFFF_FFFFFFFC (top 4 and bottom 2 bits of RR_1 are clear) > So 0 <= U1_HI < 5 * FFFFFFF_FFFFFFFC = 4FFFFFFF_FFFFFFEC > > At C we know 0 <= U_2 <= 3 > > At D we know 0 <= U_2 <= 15 > > So at E we know that 0 <= U_2 <= 4FFFFFFF_FFFFFFEC + 15 + 1 > > So, the highest possible value for U_2 at loop entry is 50000000_00000002. > > Clearly we can shift this down by two and add without any danger of overflowing > > 50000000_00000002 >> 2 + 50000000_00000002 = 64000000_00000002 Ah, no scratch that. I have made a wrong assumption at B. The value of U1_HI is bounded by the sum of the 3 multiplies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1214174121 From adinn at openjdk.org Fri Jun 2 11:05:06 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 2 Jun 2023 11:05:06 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4] In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 09:58:59 GMT, Andrew Dinn wrote: >> Yes, of course, you are right that 0<= U_2 < 6 at the point where that second multiply by 5 occurs (i.e. after the loop). >> >> I believe it is safe to use the same optimization inside the loop for reasons given below. Of course it is a bit late to change this now and retest but if my reasoning is correct then we could consider updating this post release and, maybe, a backport. >> >> The only thing that needs to be determined is what value could sit in U2 when we enter the loop. That's the only important case because we already agreed that at the loop back edge that 0 <= U2 < 6. >> >> The incoming value for U2 at loop entry is derived by the following subsequence of the instruction stream >> >> __ adcs(S_1, U_1, S_1); >> __ adc(S_2, U_2, zr); // A.1 >> __ add(S_2, S_2, 1); // A.2 >> . . . >> wide_mul(U_1, U_1HI, S_0, R_1); wide_madd(U_1, U_1HI, S_1, R_0); wide_madd(U_1, U_1HI, S_2, RR_1); // B >> . . . >> __ andr(U_2, R_0, 3); // C >> __ mul(U_2, S_2, U_2); // D >> . . . >> >> __ adc(U_2, U_1HI, U_2); // E >> >> At A.1 we know that 0 <= U_2 <= 3 (since it was initialized by unpack26) >> So, at A.2 we know that 0 <= S2 <= 5 >> >> At B we know that 0 <= RR_1 <= (2^60 - 2^2) = FFFFFFF_FFFFFFFC (top 4 and bottom 2 bits of RR_1 are clear) >> So 0 <= U1_HI < 5 * FFFFFFF_FFFFFFFC = 4FFFFFFF_FFFFFFEC >> >> At C we know 0 <= U_2 <= 3 >> >> At D we know 0 <= U_2 <= 15 >> >> So at E we know that 0 <= U_2 <= 4FFFFFFF_FFFFFFEC + 15 + 1 >> >> So, the highest possible value for U_2 at loop entry is 50000000_00000002. >> >> Clearly we can shift this down by two and add without any danger of overflowing >> >> 50000000_00000002 >> 2 + 50000000_00000002 = 64000000_00000002 > > Ah, no scratch that. I have made a wrong assumption at B. The value of U1_HI is bounded by the sum of the 3 64 bit * 64 bit multiplies. I think there is still a proof of validity to be salvaged though. We compute a 128 bit product: U1_HI:U1 = S_0 * R_1 + S_1 * R_0 + S_2 * RR_1 We know that R_0 and R_1 have four top bits clear and S2 <= 5. So, I think we can guarantee that the top word of the 128 bit product is small enough to not to overflow when we do the shift. Even if we assume S_0, S_1 and RR_1 have the maximum possible value we have S_0 * R_1 <= (2^64 - 1) * (2^60 - 1) S_1 * R_0 <= (2^64 - 1) * (2^60 - 1) S_2 * RR_1 <= 5 * (2^64 - 1) So, the top word U1_HI is bounded by at most (2 * (2^60 - 1)) + 5. That leaves more than enough room to guarantee that the shift and add will not overflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1214230004 From weijun at openjdk.org Fri Jun 2 11:57:05 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 2 Jun 2023 11:57:05 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 00:57:49 GMT, Andrew John Hughes wrote: > Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties. > > There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required. > > This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`. > > As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK. > > The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true. > > A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream. src/java.base/share/classes/java/security/Security.java line 139: > 137: extraPropDir = PropertyExpander.expand(extraPropDir); > 138: stream = Files.find(Path.of(extraPropDir), Integer.MAX_VALUE, > 139: ((path, attrs) -> attrs.isRegularFile())); You might want to exclude those files starting with `.` . Some OSes automatically generate them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14277#discussion_r1214279512 From andrew at openjdk.org Fri Jun 2 12:24:06 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 2 Jun 2023 12:24:06 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 02:01:00 GMT, Alexey Bakhtin wrote: >> Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties. >> >> There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required. >> >> This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`. >> >> As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK. >> >> The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true. >> >> A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream. > > src/java.base/share/classes/java/security/Security.java line 138: > >> 136: try { >> 137: extraPropDir = PropertyExpander.expand(extraPropDir); >> 138: stream = Files.find(Path.of(extraPropDir), Integer.MAX_VALUE, > > Hi @gnu-andrew , > The order of the files, returned by File::find is not defined. Different property files can change the same security properties, and only the latest changes will be applied. So the order of the property files is important but seems not controlled by the propertiesDir option. That's a good point. I do recall thinking about this in the early days of considering a solution, but clearly got a bit carried away in the implementation when I realised so much of the work could be done by `Files::find`. I'm thinking we should sort the returned list of Path objects lexicographically and those that occur later in sequence then override previous ones. Any file specified by `java.security.properties` is considered as if it was the final element, overriding all others. Thus, the following files: ~~~ 01-testFile1 02-testFile2 03-testDir/extra ~~~ would result in properties in `02-testFile2` taking precedence over `01-testFile1` and those in `extra` taking precedence over those in `02-testFile2`. I'll adapt the test to check for this as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14277#discussion_r1214303435 From andrew at openjdk.org Fri Jun 2 12:24:09 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 2 Jun 2023 12:24:09 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 11:54:00 GMT, Weijun Wang wrote: >> Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties. >> >> There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required. >> >> This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`. >> >> As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK. >> >> The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true. >> >> A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream. > > src/java.base/share/classes/java/security/Security.java line 139: > >> 137: extraPropDir = PropertyExpander.expand(extraPropDir); >> 138: stream = Files.find(Path.of(extraPropDir), Integer.MAX_VALUE, >> 139: ((path, attrs) -> attrs.isRegularFile())); > > You might want to exclude those files starting with `.` . Some OSes automatically generate them. Yes, a check on `Files.isHidden(path)` should cover that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14277#discussion_r1214304805 From andrew at openjdk.org Fri Jun 2 12:58:36 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Fri, 2 Jun 2023 12:58:36 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory [v2] In-Reply-To: References: Message-ID: > Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties. > > There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required. > > This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`. > > As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK. > > The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true. > > A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream. Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: Sort the returned list of property files and exclude hidden files. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14277/files - new: https://git.openjdk.org/jdk/pull/14277/files/f7529e43..85095b89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14277&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14277&range=00-01 Stats: 50 lines in 3 files changed: 40 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/14277.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14277/head:pull/14277 PR: https://git.openjdk.org/jdk/pull/14277 From aph at openjdk.org Fri Jun 2 14:32:18 2023 From: aph at openjdk.org (Andrew Haley) Date: Fri, 2 Jun 2023 14:32:18 GMT Subject: Integrated: 8296411: AArch64: Accelerated Poly1305 intrinsics In-Reply-To: References: Message-ID: On Mon, 22 May 2023 14:23:15 GMT, Andrew Haley wrote: > This provides a solid speedup of about 3-4x over the Java implementation. > > I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. > > Benchmarks: > > > ThunderX (2, I think): > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s > > Apple M1: > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s > Poly1305DigestBench.updateBytes 256 th... This pull request has now been integrated. Changeset: dc21e8aa Author: Andrew Haley URL: https://git.openjdk.org/jdk/commit/dc21e8aa8321abb161bbbc02ca379eda27a4984c Stats: 195 lines in 4 files changed: 194 ins; 0 del; 1 mod 8296411: AArch64: Accelerated Poly1305 intrinsics Reviewed-by: redestad, adinn ------------- PR: https://git.openjdk.org/jdk/pull/14085 From mullan at openjdk.org Fri Jun 2 14:53:07 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 Jun 2023 14:53:07 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v7] In-Reply-To: References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: On Thu, 1 Jun 2023 21:46:25 GMT, Rajan Halade wrote: >> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos and reformat code Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14252#pullrequestreview-1457698649 From abakhtin at openjdk.org Fri Jun 2 15:50:07 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Fri, 2 Jun 2023 15:50:07 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory [v2] In-Reply-To: References: Message-ID: <2MSLl5xsCpCMUvzNGv8I9vkh7b5jJfuuDcMJp2XN7Kc=.04ed4fa3-a341-4944-abb5-29010f874e7b@github.com> On Fri, 2 Jun 2023 12:58:36 GMT, Andrew John Hughes wrote: >> Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties. >> >> There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required. >> >> This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`. >> >> As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK. >> >> The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true. >> >> A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream. > > Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: > > Sort the returned list of property files and exclude hidden files. Thank you. Very useful enhancement. LGTM ------------- Marked as reviewed by abakhtin (Committer). PR Review: https://git.openjdk.org/jdk/pull/14277#pullrequestreview-1457862647 From rhalade at openjdk.org Fri Jun 2 18:28:44 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 2 Jun 2023 18:28:44 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v8] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: Enable OCSP logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14252/files - new: https://git.openjdk.org/jdk/pull/14252/files/e64e32fa..1ced572f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=06-07 Stats: 15 lines in 14 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From rhalade at openjdk.org Fri Jun 2 18:51:11 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 2 Jun 2023 18:51:11 GMT Subject: RFR: 8308592: Framework for CA interoperability testing [v9] In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com> Message-ID: > The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: fix typo in TeliaSoneraCA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14252/files - new: https://git.openjdk.org/jdk/pull/14252/files/1ced572f..58022a6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252 PR: https://git.openjdk.org/jdk/pull/14252 From valeriep at openjdk.org Fri Jun 2 23:58:21 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 2 Jun 2023 23:58:21 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 00:33:21 GMT, Francisco Ferrari Bihurriet wrote: >> As someone who is familiar with the Cipher convention, it's clearer to apply the Cipher convention across the board, i.e. for Mac and SecretKeyFactory too. >> For example: For SecretKeyFactory.PBEWithHmacSHA1AndAES_128, use >> `CKM_PKCS5_PBKD2 (required CKM_SHA_1_HMAC)` instead of `CKM_PKCS5_PBKD2 and CKM_SHA_1_HMAC`. >> >> The listed mechanism is the one the impl maps to or based on. The required mechanism is for auxiliary functionalities. Putting the auxiliary one inside the required brackets seems clearer than combining them with the "and" word. > > @valeriepeng: if the following format looks good to you, I'll pass the update to @martinuy: > > > > > > > > > >
Java Algorithm PKCS#11 Mechanisms
Cipher.PBEWithHmacSHA1AndAES_128 CKM_AES_CBC_PAD, CKM_AES_CBC (requires CKM_PKCS5_PBKD2 and CKM_SHA_1_HMAC)
[…] […]
Mac.HmacPBESHA1 CKM_SHA_1_HMAC (requires CKM_PBA_SHA1_WITH_SHA1_HMAC)
[…] […]
SecretKeyFactory.HmacPBESHA1 CKM_PBA_SHA1_WITH_SHA1_HMAC
[…] […]
SecretKeyFactory.PBKDF2WithHmacSHA224 CKM_PKCS5_PBKD2 (requires CKM_SHA224_HMAC)
@franferrax Yes, it looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1574446390 From valeriep at openjdk.org Sat Jun 3 00:03:23 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Sat, 3 Jun 2023 00:03:23 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 22:06:47 GMT, Francisco Ferrari Bihurriet wrote: >> @valeriepeng: I agree, `DEFAULT_ITERATIONS` should be used here and only here, so we consistently initialize any defaults in a single place. We'll update that. > > There are cases in which _salt_ and _iteration count_ come from the _key_ (`javax.crypto.interfaces.PBEKey`), so `PBES2Params.initialize()` shouldn't try to extract them from `params` (when it is `PBEParameterSpec`). To solve the inconsistency, and in line with your other comment, let's allow `params` to only be `IvParameterSpec`. But let's still receive it as `AlgorithmParameterSpec`, so we can check its type here (and make it simpler for callers), where only `IvParameterSpec` is allowed (plus `null` when encrypting). Sure, sounds reasonable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1214982193 From clanger at openjdk.org Sun Jun 4 06:22:08 2023 From: clanger at openjdk.org (Christoph Langer) Date: Sun, 4 Jun 2023 06:22:08 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> Message-ID: On Sat, 27 May 2023 22:47:53 GMT, Weijun Wang wrote: >> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove another obsolete comment > > I think you can finalize the CSR now. @wangweij The CSR is approved. Would you like to review/approve the PR now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1575418611 From weijun at openjdk.org Sun Jun 4 13:26:06 2023 From: weijun at openjdk.org (Weijun Wang) Date: Sun, 4 Jun 2023 13:26:06 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> Message-ID: On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose. >> 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Remove another obsolete comment Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13945#pullrequestreview-1461187293 From clanger at openjdk.org Mon Jun 5 08:40:19 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 5 Jun 2023 08:40:19 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> Message-ID: On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose. >> 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Remove another obsolete comment Thx. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1576362426 From clanger at openjdk.org Mon Jun 5 08:40:21 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 5 Jun 2023 08:40:21 GMT Subject: Integrated: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates In-Reply-To: References: Message-ID: On Thu, 11 May 2023 21:38:35 GMT, Christoph Langer wrote: > With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. > > The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. > > This change does the following: > 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. > 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose. > 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. > > I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. This pull request has now been integrated. Changeset: ac41c030 Author: Christoph Langer URL: https://git.openjdk.org/jdk/commit/ac41c030030c3d31815474c793ac9c420c47e22c Stats: 241 lines in 3 files changed: 193 ins; 32 del; 16 mod 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates Reviewed-by: mbaesken, weijun ------------- PR: https://git.openjdk.org/jdk/pull/13945 From clanger at openjdk.org Mon Jun 5 11:51:05 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 5 Jun 2023 11:51:05 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). LGTM ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14280#pullrequestreview-1462355243 From vlivanov at openjdk.org Mon Jun 5 18:22:43 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 5 Jun 2023 18:22:43 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Thu, 25 May 2023 22:54:15 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Catching up with master branch. > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address PR review 6: refactoring around rematerialization & improve test cases. > - Address PR review 5: refactor on rematerialization & add tests. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address part of PR review 4 & fix a bug setting only_candidate > - Catching up with master > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Fix tests. Remember previous reducible Phis. > - Address PR review 3. Some comments and be able to abort compilation. > - Merge with Master > - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. > - ... and 5 more: https://git.openjdk.org/jdk/compare/46c4da7f...8f81a7c8 src/hotspot/share/code/debugInfo.cpp line 251: > 249: // Set it to true so that the object will get rematerialized > 250: if (!_selected->is_root()) { > 251: _selected->set_root(true); Why do you need `_selected` to be marked as root? src/hotspot/share/code/debugInfo.cpp line 301: > 299: void ObjectMergeValue::print_detailed(outputStream* st) const { > 300: st->print("merge: ID=%d", _id); > 301: #ifndef PRODUCT Can you post a sample of the output, please? Why is it limited to non-product builds? It's valuable irrespective of build flavor. As I see in `ObjectValue::print_on` and `ScopeDesc::print_on`, you mix `print_on` with `print_fields_on`. Any particular reason for that? You could add `is_object_merge` case in ObjectValue::print_on` instead and extend `ObjectValue::print_fields_on` to cover `ObjectMergeValue` case. I find it hard to reason about `ObjectValue::print_on` vs `ObjectMergeValue::print_on` since it's a non-virtual method. Also, formatting is broken. src/hotspot/share/opto/compile.cpp line 2332: > 2330: } > 2331: > 2332: NOT_PRODUCT(ConnectionGraph::verify_ram_nodes(this, root());) Why do you limit the check to non-product builds only? It won't fail the compilation with product builds. src/hotspot/share/opto/output.cpp line 1101: > 1099: > 1100: if (!is_root) { > 1101: for (int k = 0; k < monarray->length(); k++) { I suggest to turn the lookup over `monarray` into a helper method and call it along with `locarray` and `exparray` checks: bool is_root = locarray->contains(ov) || exparray->contains(ov) || contains_as_owner(monarray, ov); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1217488199 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218419279 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1217491794 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218431285 From mdonovan at openjdk.org Mon Jun 5 18:37:34 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 5 Jun 2023 18:37:34 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated Message-ID: This PR implements a test to verify that Java will not negotiate TLS connections when one side of the connection requests disabled cipher suites. ------------- Commit messages: - 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated Changes: https://git.openjdk.org/jdk/pull/14316/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301379 Stats: 166 lines in 1 file changed: 166 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14316/head:pull/14316 PR: https://git.openjdk.org/jdk/pull/14316 From cslucas at openjdk.org Mon Jun 5 19:30:07 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 5 Jun 2023 19:30:07 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 5 Jun 2023 18:05:47 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Catching up with master branch. >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address PR review 6: refactoring around rematerialization & improve test cases. >> - Address PR review 5: refactor on rematerialization & add tests. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Fix tests. Remember previous reducible Phis. >> - Address PR review 3. Some comments and be able to abort compilation. >> - Merge with Master >> - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. >> - ... and 5 more: https://git.openjdk.org/jdk/compare/46c4da7f...8f81a7c8 > > src/hotspot/share/code/debugInfo.cpp line 301: > >> 299: void ObjectMergeValue::print_detailed(outputStream* st) const { >> 300: st->print("merge: ID=%d", _id); >> 301: #ifndef PRODUCT > > Can you post a sample of the output, please? > > Why is it limited to non-product builds? It's valuable irrespective of build flavor. > > As I see in `ObjectValue::print_on` and `ScopeDesc::print_on`, you mix `print_on` with `print_fields_on`. Any particular reason for that? You could add `is_object_merge` case in ObjectValue::print_on` instead and extend `ObjectValue::print_fields_on` to cover `ObjectMergeValue` case. I find it hard to reason about `ObjectValue::print_on` vs `ObjectMergeValue::print_on` since it's a non-virtual method. > > > > Also, formatting is broken. I added a few samples below and there are a few more here: https://gist.github.com/JohnTortugo/913523947e08157def6cfebafa7d5daa Sample 1: Compiled method (c2) 415 24 TestTrapAfterMerge::test (57 bytes) total in heap [0x00007f7b4d03da90,0x00007f7b4d03de18] = 904 relocation [0x00007f7b4d03dc00,0x00007f7b4d03dc18] = 24 main code [0x00007f7b4d03dc20,0x00007f7b4d03dcb8] = 152 stub code [0x00007f7b4d03dcb8,0x00007f7b4d03dcd0] = 24 oops [0x00007f7b4d03dcd0,0x00007f7b4d03dce0] = 16 metadata [0x00007f7b4d03dce0,0x00007f7b4d03dce8] = 8 scopes data [0x00007f7b4d03dce8,0x00007f7b4d03dd50] = 104 scopes pcs [0x00007f7b4d03dd50,0x00007f7b4d03de10] = 192 dependencies [0x00007f7b4d03de10,0x00007f7b4d03de18] = 8 scopes: ScopeDesc(pc=0x00007f7b4d03dc3a offset=1a): TestTrapAfterMerge::test at -1 (line 3) ScopeDesc(pc=0x00007f7b4d03dc41 offset=21): TestTrapAfterMerge::test at 11 (line 5) ScopeDesc(pc=0x00007f7b4d03dc44 offset=24): TestTrapAfterMerge::test at 51 (line 12) ScopeDesc(pc=0x00007f7b4d03dc4a offset=2a): TestTrapAfterMerge::test at 46 (line 8) ScopeDesc(pc=0x00007f7b4d03dc52 offset=32): TestTrapAfterMerge::test at 37 (line 9) ScopeDesc(pc=0x00007f7b4d03dc57 offset=37): TestTrapAfterMerge::test at 43 (line 8) ScopeDesc(pc=0x00007f7b4d03dc61 offset=41): TestTrapAfterMerge::test at 46 (line 8) reexecute=true Locals - l0: empty - l1: empty - l2: reg rbx [6],int - l3: empty - l4: merge: ID=26 - l5: reg r11 [22],int Objects - 0: merge: ID=26, selector="reg r10 [20],int", merge_pointer="nullptr", candidate objs=[27, 28] - 1: obj: ID=27, is_root=0, N.Fields=1, klass: Point Fields: reg r8 [16],int - 2: obj: ID=28, is_root=0, N.Fields=1, klass: Point Fields: reg rcx [2],int ScopeDesc(pc=0x00007f7b4d03dc63 offset=43): TestTrapAfterMerge::test at 46 (line 8) ScopeDesc(pc=0x00007f7b4d03dc6c offset=4c): TestTrapAfterMerge::test at 34 (line 8) ScopeDesc(pc=0x00007f7b4d03dc71 offset=51): TestTrapAfterMerge::test at 55 (line 12) - Sample2: Compiled method (c2) 443 24 TestManys::test (41 bytes) total in heap [0x00007f35e9155b90,0x00007f35e9155e78] = 744 relocation [0x00007f35e9155d00,0x00007f35e9155d18] = 24 main code [0x00007f35e9155d20,0x00007f35e9155d88] = 104 stub code [0x00007f35e9155d88,0x00007f35e9155da0] = 24 oops [0x00007f35e9155da0,0x00007f35e9155db0] = 16 metadata [0x00007f35e9155db0,0x00007f35e9155db8] = 8 scopes data [0x00007f35e9155db8,0x00007f35e9155e10] = 88 scopes pcs [0x00007f35e9155e10,0x00007f35e9155e70] = 96 dependencies [0x00007f35e9155e70,0x00007f35e9155e78] = 8 scopes: ScopeDesc(pc=0x00007f35e9155d3a offset=1a): TestManys::test at -1 (line 57) ScopeDesc(pc=0x00007f35e9155d42 offset=22): TestManys::test at 11 (line 59) ScopeDesc(pc=0x00007f35e9155d58 offset=38): TestManys::test at 25 (line 63) Locals - l0: empty - l1: empty - l2: empty - l3: empty - l4: empty - l5: empty - l6: empty - l7: empty - l8: merge: ID=26 Objects - 0: merge: ID=26, selector="reg rbp [10],int", merge_pointer="nullptr", candidate objs=[27, 28] - 1: obj: ID=27, is_root=0, N.Fields=4, klass: Point Fields: stack[36], stack[36], 0, 0 - 2: obj: ID=28, is_root=0, N.Fields=4, klass: Point Fields: 2023, 0, 0, 0 ScopeDesc(pc=0x00007f35e9155d74 offset=54): TestManys::test at 25 (line 63) - Sample3: Compiled method (c2) 436 24 TestMultiSFO::test (48 bytes) total in heap [0x00007f1df5155590,0x00007f1df5155850] = 704 relocation [0x00007f1df5155700,0x00007f1df5155718] = 24 main code [0x00007f1df5155720,0x00007f1df5155788] = 104 stub code [0x00007f1df5155788,0x00007f1df51557a0] = 24 oops [0x00007f1df51557a0,0x00007f1df51557b0] = 16 metadata [0x00007f1df51557b0,0x00007f1df51557b8] = 8 scopes data [0x00007f1df51557b8,0x00007f1df51557f8] = 64 scopes pcs [0x00007f1df51557f8,0x00007f1df5155848] = 80 dependencies [0x00007f1df5155848,0x00007f1df5155850] = 8 scopes: ScopeDesc(pc=0x00007f1df515573a offset=1a): TestMultiSFO::test at -1 (line 12) ScopeDesc(pc=0x00007f1df515575c offset=3c): TestMultiSFO::test at 28 (line 19) Locals - l0: empty - l1: empty - l2: empty - l3: merge: ID=14 - l4: obj: ID=15, is_root=1, N.Fields=2, klass: TestMultiSFO$Point Fields: stack[12], stack[8] Objects - 0: merge: ID=14, selector="reg rbp [10],int", merge_pointer="nullptr", candidate objs=[15, 16] - 1: obj: ID=15, is_root=1, N.Fields=2, klass: TestMultiSFO$Point Fields: stack[12], stack[8] - 2: obj: ID=16, is_root=0, N.Fields=2, klass: TestMultiSFO$Point Fields: stack[8], stack[12] ScopeDesc(pc=0x00007f1df5155778 offset=58): TestMultiSFO::test at 28 (line 19) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218500009 From cslucas at openjdk.org Mon Jun 5 19:55:09 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 5 Jun 2023 19:55:09 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 5 Jun 2023 19:26:59 GMT, Cesar Soares Lucas wrote: >> src/hotspot/share/code/debugInfo.cpp line 301: >> >>> 299: void ObjectMergeValue::print_detailed(outputStream* st) const { >>> 300: st->print("merge: ID=%d", _id); >>> 301: #ifndef PRODUCT >> >> Can you post a sample of the output, please? >> >> Why is it limited to non-product builds? It's valuable irrespective of build flavor. >> >> As I see in `ObjectValue::print_on` and `ScopeDesc::print_on`, you mix `print_on` with `print_fields_on`. Any particular reason for that? You could add `is_object_merge` case in ObjectValue::print_on` instead and extend `ObjectValue::print_fields_on` to cover `ObjectMergeValue` case. I find it hard to reason about `ObjectValue::print_on` vs `ObjectMergeValue::print_on` since it's a non-virtual method. >> >> >> >> Also, formatting is broken. > > I added a few samples below and there are a few more here: https://gist.github.com/JohnTortugo/913523947e08157def6cfebafa7d5daa > > Sample 1: > > > Compiled method (c2) 415 24 TestTrapAfterMerge::test (57 bytes) > total in heap [0x00007f7b4d03da90,0x00007f7b4d03de18] = 904 > relocation [0x00007f7b4d03dc00,0x00007f7b4d03dc18] = 24 > main code [0x00007f7b4d03dc20,0x00007f7b4d03dcb8] = 152 > stub code [0x00007f7b4d03dcb8,0x00007f7b4d03dcd0] = 24 > oops [0x00007f7b4d03dcd0,0x00007f7b4d03dce0] = 16 > metadata [0x00007f7b4d03dce0,0x00007f7b4d03dce8] = 8 > scopes data [0x00007f7b4d03dce8,0x00007f7b4d03dd50] = 104 > scopes pcs [0x00007f7b4d03dd50,0x00007f7b4d03de10] = 192 > dependencies [0x00007f7b4d03de10,0x00007f7b4d03de18] = 8 > scopes: > ScopeDesc(pc=0x00007f7b4d03dc3a offset=1a): > TestTrapAfterMerge::test at -1 (line 3) > ScopeDesc(pc=0x00007f7b4d03dc41 offset=21): > TestTrapAfterMerge::test at 11 (line 5) > ScopeDesc(pc=0x00007f7b4d03dc44 offset=24): > TestTrapAfterMerge::test at 51 (line 12) > ScopeDesc(pc=0x00007f7b4d03dc4a offset=2a): > TestTrapAfterMerge::test at 46 (line 8) > ScopeDesc(pc=0x00007f7b4d03dc52 offset=32): > TestTrapAfterMerge::test at 37 (line 9) > ScopeDesc(pc=0x00007f7b4d03dc57 offset=37): > TestTrapAfterMerge::test at 43 (line 8) > ScopeDesc(pc=0x00007f7b4d03dc61 offset=41): > TestTrapAfterMerge::test at 46 (line 8) reexecute=true > Locals > - l0: empty > - l1: empty > - l2: reg rbx [6],int > - l3: empty > - l4: merge: ID=26 > - l5: reg r11 [22],int > Objects > - 0: merge: ID=26, selector="reg r10 [20],int", merge_pointer="nullptr", candidate objs=[27, 28] > - 1: obj: ID=27, is_root=0, N.Fields=1, klass: Point > Fields: reg r8 [16],int > - 2: obj: ID=28, is_root=0, N.Fields=1, klass: Point > Fields: reg rcx [2],int > ScopeDesc(pc=0x00007f7b4d03dc63 offset=43): > TestTrapAfterMerge::test at 46 (line 8) > ScopeDesc(pc=0x00007f7b4d03dc6c offset=4c): > TestTrapAfterMerge::test at 34 (line 8) > ScopeDesc(pc=0x00007f7b4d03dc71 offset=51): > TestTrapAfterMerge::test at 55 (line 12) > > > - Sample2: > > > Compiled method (c2) 443 24 TestManys::test (41 bytes) > total in heap [0x00007f35e9155b90,0x00007f35e9155e78] = 744 > relocation [0x00007f35e9155d00,0x00007f35e9155d18] = 24 > main code [0x00007f35e9155d20,0x00007f35e9155d88] = 104 > stub code [0x00007f35e9155d88,0x00007f35e9155da0] = 24 > oops [0x00007f35e9155da0,0x00007f35e9155db0] =... > Why is it limited to non-product builds? It's valuable irrespective of build flavor. This is because `print_on` in `AnyObj` is only defined in non-product builds. I based implementation of `ObjectMergeValue::print_on` on `ObjectValue::print_on`. In `ObjectValue::print_on` fields aren't printed in product builds. > Any particular reason for that? You could add is_object_merge case in ObjectValue::print_oninstead and extendObjectValue::print_fields_onto coverObjectMergeValue case. I'll do that then. > Also, formatting is broken. Can you please share an example? If you mean the tabs on lines 303/304/306/307 I added those because I thought would make the code easier to read, but if you want I can definitely remove that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218523643 From cslucas at openjdk.org Mon Jun 5 19:55:14 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 5 Jun 2023 19:55:14 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 5 Jun 2023 05:10:13 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Catching up with master branch. >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address PR review 6: refactoring around rematerialization & improve test cases. >> - Address PR review 5: refactor on rematerialization & add tests. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Fix tests. Remember previous reducible Phis. >> - Address PR review 3. Some comments and be able to abort compilation. >> - Merge with Master >> - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. >> - ... and 5 more: https://git.openjdk.org/jdk/compare/46c4da7f...8f81a7c8 > > src/hotspot/share/opto/compile.cpp line 2332: > >> 2330: } >> 2331: >> 2332: NOT_PRODUCT(ConnectionGraph::verify_ram_nodes(this, root());) > > Why do you limit the check to non-product builds only? It won't fail the compilation with product builds. Duh. I'll fix that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218525026 From vlivanov at openjdk.org Mon Jun 5 20:31:02 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 5 Jun 2023 20:31:02 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 5 Jun 2023 19:50:25 GMT, Cesar Soares Lucas wrote: > If you mean the tabs on lines 303/304/306/307 Yes, it confused me. As an alternative, you could put selector and merge_pointer-related statements on the same line, but I'm not sure how much it improves readability: st->print(", selector=""); _selector->print_on(st); st->print("""); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218558213 From vlivanov at openjdk.org Mon Jun 5 20:31:03 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 5 Jun 2023 20:31:03 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <4gr0ARilcuMl1Zfht5_7qYOd-OouT_2rIa8SgQuQWDw=.b55a2bc3-def0-4e29-bfb2-cc940d3493fb@github.com> On Mon, 5 Jun 2023 20:27:42 GMT, Vladimir Ivanov wrote: >>> Why is it limited to non-product builds? It's valuable irrespective of build flavor. >> >> This is because `print_on` in `AnyObj` is only defined in non-product builds. I based implementation of `ObjectMergeValue::print_on` on `ObjectValue::print_on`. In `ObjectValue::print_on` fields aren't printed in product builds. >> >>> Any particular reason for that? You could add is_object_merge case in ObjectValue::print_oninstead and extendObjectValue::print_fields_onto coverObjectMergeValue case. >> >> I'll do that then. >> >>> Also, formatting is broken. >> >> Can you please share an example? If you mean the tabs on lines 303/304/306/307 I added those because I thought would make the code easier to read, but if you want I can definitely remove that. > >> If you mean the tabs on lines 303/304/306/307 > > Yes, it confused me. As an alternative, you could put selector and merge_pointer-related statements on the same line, but I'm not sure how much it improves readability: > > st->print(", selector=""); _selector->print_on(st); st->print("""); A couple of suggestions about the output: * `merge`: it's clearer to call it `merge_obj` * `obj` vs `merge` output: obj output is duplicated in ScopeDesc entries and Objects sections; before it was a short version printed in Locals/Expressions and all the details were included in Objects; I like to see field locations in the short version, but including everything looks way too much IMO; * it makes sense to include selector and merge_pointer info in short version, but `is_root` can be omitted ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218558295 From cslucas at openjdk.org Mon Jun 5 21:13:06 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 5 Jun 2023 21:13:06 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: <4gr0ARilcuMl1Zfht5_7qYOd-OouT_2rIa8SgQuQWDw=.b55a2bc3-def0-4e29-bfb2-cc940d3493fb@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <4gr0ARilcuMl1Zfht5_7qYOd-OouT_2rIa8SgQuQWDw=.b55a2bc3-def0-4e29-bfb2-cc940d3493fb@github.com> Message-ID: <3bgmER7fyi8uvkp58Fwr5s4XHT0BWOoED49EVDTRSDI=.a5839cc3-c2b2-4a94-a097-f748a3cf0a29@github.com> On Mon, 5 Jun 2023 20:27:48 GMT, Vladimir Ivanov wrote: >>> If you mean the tabs on lines 303/304/306/307 >> >> Yes, it confused me. As an alternative, you could put selector and merge_pointer-related statements on the same line, but I'm not sure how much it improves readability: >> >> st->print(", selector=""); _selector->print_on(st); st->print("""); > > A couple of suggestions about the output: > * `merge`: it's clearer to call it `merge_obj` > * `obj` vs `merge` output: obj output is duplicated in ScopeDesc entries and Objects sections; before it was a short version printed in Locals/Expressions and all the details were included in Objects; I like to see field locations in the short version, but including everything looks way too much IMO; > * it makes sense to include selector and merge_pointer info in short version, but `is_root` can be omitted Thanks @iwanowww . Does the output below look good to you? It prints ObjectValue in the same format as it was before this PR and only print details of the merge in the "Objects" section. Is there other output section that you think needs to be adjusted? Compiled method (c2) 436 24 TestMultiSFO::test (48 bytes) total in heap [0x00007f1df5155590,0x00007f1df5155850] = 704 relocation [0x00007f1df5155700,0x00007f1df5155718] = 24 main code [0x00007f1df5155720,0x00007f1df5155788] = 104 stub code [0x00007f1df5155788,0x00007f1df51557a0] = 24 oops [0x00007f1df51557a0,0x00007f1df51557b0] = 16 metadata [0x00007f1df51557b0,0x00007f1df51557b8] = 8 scopes data [0x00007f1df51557b8,0x00007f1df51557f8] = 64 scopes pcs [0x00007f1df51557f8,0x00007f1df5155848] = 80 dependencies [0x00007f1df5155848,0x00007f1df5155850] = 8 scopes: ScopeDesc(pc=0x00007f1df515573a offset=1a): TestMultiSFO::test at -1 (line 12) ScopeDesc(pc=0x00007f1df515575c offset=3c): TestMultiSFO::test at 28 (line 19) Locals - l0: empty - l1: empty - l2: empty - l3: merge_obj[14] - l4: obj[15] Objects - merge_obj[14], selector="reg rbp [10],int", merge_pointer="nullptr", candidate_objs=[15, 16] - obj[15], is_root=1, klass: TestMultiSFO$Point Fields: stack[12], stack[8] - obj[16], is_root=0, klass: TestMultiSFO$Point Fields: stack[8], stack[12] ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218596666 From vlivanov at openjdk.org Mon Jun 5 22:08:02 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 5 Jun 2023 22:08:02 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: <3bgmER7fyi8uvkp58Fwr5s4XHT0BWOoED49EVDTRSDI=.a5839cc3-c2b2-4a94-a097-f748a3cf0a29@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <4gr0ARilcuMl1Zfht5_7qYOd-OouT_2rIa8SgQuQWDw=.b55a2bc3-def0-4e29-bfb2-cc940d3493fb@github.com> <3bgmER7fyi8uvkp58Fwr5s4XHT0BWOoED49EVDTRSDI=.a5839cc3-c2b2-4a94-a097-f748a3cf0a29@github.com> Message-ID: <4CuSp8KR3SDGjc88Pd57VcwsBdjG5_FUT94U8XkoM0s=.e61ce2a5-b9b4-40aa-9399-62b3ac275634@github.com> On Mon, 5 Jun 2023 21:10:22 GMT, Cesar Soares Lucas wrote: >> A couple of suggestions about the output: >> * `merge`: it's clearer to call it `merge_obj` >> * `obj` vs `merge` output: obj output is duplicated in ScopeDesc entries and Objects sections; before it was a short version printed in Locals/Expressions and all the details were included in Objects; I like to see field locations in the short version, but including everything looks way too much IMO; >> * it makes sense to include selector and merge_pointer info in short version, but `is_root` can be omitted > > Thanks @iwanowww . Does the output below look good to you? It prints ObjectValue in the same format as it was before this PR and only print details of the merge in the "Objects" section. Is there other output section that you think needs to be adjusted? > > > Compiled method (c2) 436 24 TestMultiSFO::test (48 bytes) > total in heap [0x00007f1df5155590,0x00007f1df5155850] = 704 > relocation [0x00007f1df5155700,0x00007f1df5155718] = 24 > main code [0x00007f1df5155720,0x00007f1df5155788] = 104 > stub code [0x00007f1df5155788,0x00007f1df51557a0] = 24 > oops [0x00007f1df51557a0,0x00007f1df51557b0] = 16 > metadata [0x00007f1df51557b0,0x00007f1df51557b8] = 8 > scopes data [0x00007f1df51557b8,0x00007f1df51557f8] = 64 > scopes pcs [0x00007f1df51557f8,0x00007f1df5155848] = 80 > dependencies [0x00007f1df5155848,0x00007f1df5155850] = 8 > scopes: > ScopeDesc(pc=0x00007f1df515573a offset=1a): > TestMultiSFO::test at -1 (line 12) > ScopeDesc(pc=0x00007f1df515575c offset=3c): > TestMultiSFO::test at 28 (line 19) > Locals > - l0: empty > - l1: empty > - l2: empty > - l3: merge_obj[14] > - l4: obj[15] > > Objects > - merge_obj[14], selector="reg rbp [10],int", merge_pointer="nullptr", candidate_objs=[15, 16] > - obj[15], is_root=1, klass: TestMultiSFO$Point > Fields: stack[12], stack[8] > - obj[16], is_root=0, klass: TestMultiSFO$Point > Fields: stack[8], stack[12] Thanks, it looks much better now (except the position in Objects array is missing). It makes sense to mention `is_root` for merge_obj case even though it's always equals to '1`. Also, make merge_pointer optional and omit it when its value is null. BTW instead of printing `is_root=0/1`, you can introduce a more compact notation for and mark relevant lines with a single symbol: - 0: R merge_obj[14], selector="reg rbp [10],int" candidates=[15, 16] - 1: R obj[15], klass: TestMultiSFO$Point Fields: stack[12], stack[8] - 2: obj[16], klass: TestMultiSFO$Point Fields: stack[8], stack[12] ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218642386 From valeriep at openjdk.org Mon Jun 5 22:41:08 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 5 Jun 2023 22:41:08 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Sat, 27 May 2023 06:24:36 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao test/jdk/sun/security/pkcs11/Mac/PBAMac.java line 47: > 45: public final class PBAMac extends PKCS11Test { > 46: private static final char[] password = "123456".toCharArray(); > 47: private static final byte[] salt = "abcdefgh".getBytes(); This converts the string into bytes using "default" charset which means this test will likely fail if the default charset changed unexpectedly? Same goes for other data such as 'plainText'. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218667194 From valeriep at openjdk.org Mon Jun 5 22:46:10 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 5 Jun 2023 22:46:10 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Sat, 27 May 2023 06:24:36 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java line 143: > 141: private static final char[] pwd = "123456\uA4F7".toCharArray(); > 142: private static final char[] emptyPwd = new char[0]; > 143: private static final byte[] salt = "abcdefgh".getBytes(); My other comment of charset encoding applies here as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218670896 From cslucas at openjdk.org Mon Jun 5 22:49:04 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 5 Jun 2023 22:49:04 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 5 Jun 2023 05:05:26 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Catching up with master branch. >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address PR review 6: refactoring around rematerialization & improve test cases. >> - Address PR review 5: refactor on rematerialization & add tests. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Fix tests. Remember previous reducible Phis. >> - Address PR review 3. Some comments and be able to abort compilation. >> - Merge with Master >> - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. >> - ... and 5 more: https://git.openjdk.org/jdk/compare/46c4da7f...8f81a7c8 > > src/hotspot/share/code/debugInfo.cpp line 251: > >> 249: // Set it to true so that the object will get rematerialized >> 250: if (!_selected->is_root()) { >> 251: _selected->set_root(true); > > Why do you need `_selected` to be marked as root? I think you're right, there is no need for that. I'll remove/refactor that and run tests again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218672363 From cslucas at openjdk.org Mon Jun 5 22:49:05 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 5 Jun 2023 22:49:05 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: <4CuSp8KR3SDGjc88Pd57VcwsBdjG5_FUT94U8XkoM0s=.e61ce2a5-b9b4-40aa-9399-62b3ac275634@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <4gr0ARilcuMl1Zfht5_7qYOd-OouT_2rIa8SgQuQWDw=.b55a2bc3-def0-4e29-bfb2-cc940d3493fb@github.com> <3bgmER7fyi8uvkp58Fwr5s4XHT0BWOoED49EVDTRSDI=.a5839cc3-c2b2-4a94-a097-f748a3cf0a29@github.com> <4CuSp8KR3SDGjc88Pd57VcwsBdjG5_FUT94U8XkoM0s=.e61ce2a5-b9b4-40aa-9399-62b3ac275634@github.com> Message-ID: On Mon, 5 Jun 2023 22:03:59 GMT, Vladimir Ivanov wrote: >> Thanks @iwanowww . Does the output below look good to you? It prints ObjectValue in the same format as it was before this PR and only print details of the merge in the "Objects" section. Is there other output section that you think needs to be adjusted? >> >> >> Compiled method (c2) 436 24 TestMultiSFO::test (48 bytes) >> total in heap [0x00007f1df5155590,0x00007f1df5155850] = 704 >> relocation [0x00007f1df5155700,0x00007f1df5155718] = 24 >> main code [0x00007f1df5155720,0x00007f1df5155788] = 104 >> stub code [0x00007f1df5155788,0x00007f1df51557a0] = 24 >> oops [0x00007f1df51557a0,0x00007f1df51557b0] = 16 >> metadata [0x00007f1df51557b0,0x00007f1df51557b8] = 8 >> scopes data [0x00007f1df51557b8,0x00007f1df51557f8] = 64 >> scopes pcs [0x00007f1df51557f8,0x00007f1df5155848] = 80 >> dependencies [0x00007f1df5155848,0x00007f1df5155850] = 8 >> scopes: >> ScopeDesc(pc=0x00007f1df515573a offset=1a): >> TestMultiSFO::test at -1 (line 12) >> ScopeDesc(pc=0x00007f1df515575c offset=3c): >> TestMultiSFO::test at 28 (line 19) >> Locals >> - l0: empty >> - l1: empty >> - l2: empty >> - l3: merge_obj[14] >> - l4: obj[15] >> >> Objects >> - merge_obj[14], selector="reg rbp [10],int", merge_pointer="nullptr", candidate_objs=[15, 16] >> - obj[15], is_root=1, klass: TestMultiSFO$Point >> Fields: stack[12], stack[8] >> - obj[16], is_root=0, klass: TestMultiSFO$Point >> Fields: stack[8], stack[12] > > Thanks, it looks much better now (except the position in Objects array is missing). > > It makes sense to mention `is_root` for merge_obj case even though it's always equals to '1`. Also, make merge_pointer optional and omit it when its value is null. > > BTW instead of printing `is_root=0/1`, you can introduce a more compact notation and mark relevant lines with a single symbol: > > - 0: R merge_obj[14], selector="reg rbp [10],int" candidates=[15, 16] > - 1: R obj[15], klass: TestMultiSFO$Point > Fields: stack[12], stack[8] > - 2: obj[16], klass: TestMultiSFO$Point > Fields: stack[8], stack[12] Sounds good. I'll make the changes and push them asap. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1218671994 From valeriep at openjdk.org Mon Jun 5 23:22:12 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 5 Jun 2023 23:22:12 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Sat, 27 May 2023 06:24:36 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao test/jdk/sun/security/pkcs11/Cipher/PBECipher.java line 50: > 48: public final class PBECipher extends PKCS11Test { > 49: private static final char[] password = "123456".toCharArray(); > 50: private static final byte[] salt = "abcdefgh".getBytes(); Same comment for the charset encoding... test/jdk/sun/security/pkcs11/PKCS11Test.java line 870: > 868: @Override > 869: public byte[] getEncoded() { > 870: return new byte[0]; Well, instead of returning a 0-length byte array, how about throwing a RuntimeException indicating this method is not meant to be called? This would help troubleshooting if needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218696421 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218694581 From valeriep at openjdk.org Tue Jun 6 00:27:11 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 6 Jun 2023 00:27:11 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Sat, 27 May 2023 06:24:36 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java line 83: > 81: // Make sure that SunPKCS11 implements the Cipher algorithm > 82: Cipher.getInstance(pbeCipherAlg, sunPKCS11); > 83: testWith(sunPKCS11, pbeCipherAlg, pbeMacAlgs[0]); Looks like an error handling is missing, i.e. catch and ignore/skip the corresponding testing if the algorithm is not supported by the sunPKCS11 provider under test. Same goes for the Mac loop below also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218737578 From mbalao at openjdk.org Tue Jun 6 03:07:07 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 03:07:07 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Sat, 3 Jun 2023 00:00:04 GMT, Valerie Peng wrote: >> There are cases in which _salt_ and _iteration count_ come from the _key_ (`javax.crypto.interfaces.PBEKey`), so `PBES2Params.initialize()` shouldn't try to extract them from `params` (when it is `PBEParameterSpec`). To solve the inconsistency, and in line with your other comment, let's allow `params` to only be `IvParameterSpec`. But let's still receive it as `AlgorithmParameterSpec`, so we can check its type here (and make it simpler for callers), where only `IvParameterSpec` is allowed (plus `null` when encrypting). > > Sure, sounds reasonable. Both changes (passing a IvParameterSpec instance and consolidating defaults for iteration count in a single place) look good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218807629 From mbalao at openjdk.org Tue Jun 6 03:10:09 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 03:10:09 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 22:07:07 GMT, Francisco Ferrari Bihurriet wrote: >> src/java.base/share/classes/sun/security/util/PBEUtil.java line 182: >> >>> 180: // salt should be non-null per PBEParameterSpec >>> 181: iCountInit = check(pbeParams.getIterationCount()); >>> 182: saltInit = check(pbeParams.getSalt()); >> >> Why not override params with the IvParameterSpec inside the PBEParameterSpec here? Then the PBES2Params.initialize(...) method does not need to handle PBEParameterSpec type? Seems more consistent this way. > > @valeriepeng: I agree, the only downside I see is that we'll need to do the same `pbeParams.getParameterSpec()` extraction before [this `PBES2Params.initialize()` call](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java#L144-L146). But for this case, it's clearly more consistent to have the extraction here. We'll address this in the next iteration. I'm okay with this change. While I don't like extracting in two places (on the caller side) as @franferrax said, perhaps it makes easier to understand why the iteration count and salt are not obtained from params in PBES2Params::initialize. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218808892 From mbalao at openjdk.org Tue Jun 6 03:24:06 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 03:24:06 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 01:14:15 GMT, Francisco Ferrari Bihurriet wrote: >> @valeriepeng: the rationale behind this decision is based on the only usage of `engineGetKeySize()`, which corresponds to a [`crypto.policy=limited` _Cryptographic Jurisdiction Policy_](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/conf/security/java.security#L906-L942). Here, `engineGetKeySize()` is employed to check the key during the _Cipher_ initialization (see [`Cipher.java:1463`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1463), [`Cipher.java:1110`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1110), [`Cipher.java:1139`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/javax/crypto/Cipher.java#L1139)). So, what we can assert is that if the key size isn't going to be `svcPbeKi.keyLen`, then that very same _Cipher_ initialization will later fail anyway. >> >> There also is a previous precedent set by _SunJCE_: >> https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java#L214-L216 >> https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java#L377-L379 >> https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e//src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java#L355-L358 >> https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e//src/java.base/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java#L367-L371 >> >> NOTE: by passing `-Djava.security.properties=<(echo crypto.policy=limited)` as a JVM argument to [`test/jdk/sun/security/pkcs11/Cipher/PBECipher.java`](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java#L191), I could reproduce a failure of the [older implementation using the underlying cipher](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java#L210-L215): if we pass a `com.sun.crypto.provider.PBEKey` of the [`PBE` → `PBEWithMD5AndDES`](https://github.com/openjdk/jdk/blob/80575ccb06f8f1aee26f9cd18b8504211d2f62c7/src/java.base/sha... > > I can confirm that the failures I was seeing were caused by the `128` bits key size limit here: > https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/java.base/share/conf/security/policy/limited/default_local.policy#L13 > > If I set that to `512`, [`test/jdk/sun/security/pkcs11/Cipher/PBECipher.java`](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java) passes with `crypto.policy=limited`. I agree with @franferrax. This internal API was a bit confusing to me because a key is passed to obtain a key size but the key itself can be converted/derived right before use in the service, so the service can affect the real key size. This goes beyond the SunPKCS11 implementation. The rationale that we applied was to return the key size that a successful initialization of the service would have in all cases. There is only one caller, which will pass the same key to engineGetKeySize and to the service initialization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218818144 From mbalao at openjdk.org Tue Jun 6 03:35:11 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 03:35:11 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 23:18:49 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > test/jdk/sun/security/pkcs11/Cipher/PBECipher.java line 50: > >> 48: public final class PBECipher extends PKCS11Test { >> 49: private static final char[] password = "123456".toCharArray(); >> 50: private static final byte[] salt = "abcdefgh".getBytes(); > > Same comment for the charset encoding... Good. Fixed for salt and plainText here. > test/jdk/sun/security/pkcs11/Mac/PBAMac.java line 47: > >> 45: public final class PBAMac extends PKCS11Test { >> 46: private static final char[] password = "123456".toCharArray(); >> 47: private static final byte[] salt = "abcdefgh".getBytes(); > > This converts the string into bytes using "default" charset which means this test will likely fail if the default charset changed unexpectedly? Same goes for other data such as 'plainText'. That's right. Fixed for salt and plainText. > test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java line 143: > >> 141: private static final char[] pwd = "123456\uA4F7".toCharArray(); >> 142: private static final char[] emptyPwd = new char[0]; >> 143: private static final byte[] salt = "abcdefgh".getBytes(); > > My other comment of charset encoding applies here as well? Good. Fixed for salt here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218827193 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218824432 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218825066 From mbalao at openjdk.org Tue Jun 6 03:49:10 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 03:49:10 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 00:24:21 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java line 83: > >> 81: // Make sure that SunPKCS11 implements the Cipher algorithm >> 82: Cipher.getInstance(pbeCipherAlg, sunPKCS11); >> 83: testWith(sunPKCS11, pbeCipherAlg, pbeMacAlgs[0]); > > Looks like an error handling is missing, i.e. catch and ignore/skip the corresponding testing if the algorithm is not supported by the sunPKCS11 provider under test. Same goes for the Mac loop below also. I'm not sure of this change because the test is NSS-based ?in fact, we initialize the NSS software token with a specific configuration? and the PBE algorithms used in the test should be available. Have you found a platform/NSS version in which this is not true? I'm concerned about making the test (silently) pass when there is something that we should notice, such as the removal of something in a newer version that would affect our testing coverage or the change in one of the native mechanisms for a given algorithm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218841067 From mbalao at openjdk.org Tue Jun 6 04:06:10 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 04:06:10 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Sat, 27 May 2023 06:24:36 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao The agreed changes to the CSR look good to me. Moved to Finalized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1577869264 From mbalao at openjdk.org Tue Jun 6 04:06:12 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 04:06:12 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v6] In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 23:17:02 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > test/jdk/sun/security/pkcs11/PKCS11Test.java line 870: > >> 868: @Override >> 869: public byte[] getEncoded() { >> 870: return new byte[0]; > > Well, instead of returning a 0-length byte array, how about throwing a RuntimeException indicating this method is not meant to be called? This would help troubleshooting if needed. Sounds good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1218853753 From mbalao at openjdk.org Tue Jun 6 04:15:21 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 04:15:21 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v7] In-Reply-To: References: Message-ID: > We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. > > In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): > > * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) ... Martin Balao has updated the pull request incrementally with one additional commit since the last revision: 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #5) Co-authored-by: Francisco Ferrari Co-authored-by: Martin Balao ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12396/files - new: https://git.openjdk.org/jdk/pull/12396/files/1c596e14..f4093887 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=05-06 Stats: 38 lines in 6 files changed: 15 ins; 5 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/12396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396 PR: https://git.openjdk.org/jdk/pull/12396 From mbaesken at openjdk.org Tue Jun 6 07:12:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 07:12:02 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). Hi Christoph, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578046570 From mbaesken at openjdk.org Tue Jun 6 07:12:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 07:12:02 GMT Subject: Integrated: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). This pull request has now been integrated. Changeset: 3b85f84f Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/3b85f84f026973a2abdbce8d9baf1329c8a4ebf8 Stats: 20 lines in 2 files changed: 11 ins; 2 del; 7 mod 8309340: Provide sctpHandleSocketErrorWithMessage Reviewed-by: clanger ------------- PR: https://git.openjdk.org/jdk/pull/14280 From alanb at openjdk.org Tue Jun 6 07:19:03 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jun 2023 07:19:03 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). I see this was integrated without a reviewer in the area but I think the changes are okay. src/jdk.sctp/unix/native/libsctp/SctpNet.c line 147: > 145: errno = errorValue; > 146: if (message == NULL) { > 147: JNU_ThrowByNameWithLastError(env, xn, "NioSocketError"); "NioSocketError" is confusing as the failing message, maybe we should change that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578057691 PR Review Comment: https://git.openjdk.org/jdk/pull/14280#discussion_r1219054386 From mbaesken at openjdk.org Tue Jun 6 07:24:01 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 07:24:01 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 07:16:13 GMT, Alan Bateman wrote: > I see this was integrated without a reviewer in the area but I think the changes are okay. Hi Alan, I think Christoph is very competent in the area. But should I look into the census next time for some special reviewer category (and which one would that be) ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578063861 From alanb at openjdk.org Tue Jun 6 07:35:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jun 2023 07:35:07 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). The SCTP API/implementation is the networking area, "net" group in the census. We usually try to get a Reviewer from that area for changes to the networking code. It's not an issue here, just mentioning it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578082485 From dfuchs at openjdk.org Tue Jun 6 08:54:01 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Jun 2023 08:54:01 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). FWIW the changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/14280#pullrequestreview-1464641236 From mbaesken at openjdk.org Tue Jun 6 10:41:01 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 10:41:01 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 08:51:33 GMT, Daniel Fuchs wrote: > FWIW the changes look good to me. Thanks for looking into it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578414732 From mbaesken at openjdk.org Tue Jun 6 10:41:04 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 10:41:04 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 07:15:08 GMT, Alan Bateman wrote: >> There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. >> >> Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). > > src/jdk.sctp/unix/native/libsctp/SctpNet.c line 147: > >> 145: errno = errorValue; >> 146: if (message == NULL) { >> 147: JNU_ThrowByNameWithLastError(env, xn, "NioSocketError"); > > "NioSocketError" is confusing as the failing message, maybe we should change that. Hi Alan, do you have a good suggestion what to use instead ? Maybe "SCTP socket error" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14280#discussion_r1219391449 From cslucas at openjdk.org Tue Jun 6 14:51:46 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 6 Jun 2023 14:51:46 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v15] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Address PR review 6: debug format output & some refactoring. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/8f81a7c8..3a5ed401 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=13-14 Stats: 112 lines in 6 files changed: 37 ins; 59 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From cslucas at openjdk.org Tue Jun 6 16:51:04 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 6 Jun 2023 16:51:04 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v16] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges Catching up with master. - Address PR review 6: debug format output & some refactoring. - Catching up with master branch. Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address PR review 6: refactoring around rematerialization & improve test cases. - Address PR review 5: refactor on rematerialization & add tests. - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address part of PR review 4 & fix a bug setting only_candidate - Catching up with master Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Fix tests. Remember previous reducible Phis. - Address PR review 3. Some comments and be able to abort compilation. - ... and 7 more: https://git.openjdk.org/jdk/compare/ca6f07f9...cb0b6702 ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=15 Stats: 2741 lines in 26 files changed: 2486 ins; 113 del; 142 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From asemenov at openjdk.org Tue Jun 6 17:35:34 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 6 Jun 2023 17:35:34 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v3] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:04:09 GMT, Weijun Wang wrote: >> done > > I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`. This is rarely used in the code and is not the essence of the current changes. If you introduce such changes, then throughout the code. Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1220056527 From weijun at openjdk.org Tue Jun 6 17:50:00 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 6 Jun 2023 17:50:00 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 17:32:35 GMT, Artem Semenov wrote: >> I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`. > > This is rarely used in the code and is not the essence of the current changes. > If you introduce such changes, then throughout the code. > Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225 I'm not a clang expect, I was just asking if modifying the current `#if TARGET_OS_MAC` check into `#if defined(__APPLE__)` is also a solution. The comment on lines 46-47 says the condition was copied from a macOS SDK file and that's what the file is using now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1220071779 From valeriep at openjdk.org Tue Jun 6 18:22:18 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 6 Jun 2023 18:22:18 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v7] In-Reply-To: References: Message-ID: <2PLnY7FEoIW4top-ZGF-2G6gsMBOBt01nG2bO67lwfg=.cd7fa109-d4ba-4bcf-8501-b0e6a184426c@github.com> On Tue, 6 Jun 2023 04:15:21 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #5) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao Rest looks good. src/java.base/share/classes/sun/security/util/PBEUtil.java line 347: > 345: "Salt or iteration count parameters are " + > 346: "not consistent with PBE key"); > 347: } Based on the javadoc of PBEKey, it's possible that salt and ic aren't specified, e.g. null and 0. In this case, this check will fail if the PBEParameterSpec contains salt and ic. IIRC, the java impl will use the values from PBEParameterSpec in this case. Perhaps we can consider same handling? This can be handled separately by tracking this under a separate bug as it's getting too close to RPD1 already. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12396#pullrequestreview-1465811677 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1220107040 From mbalao at openjdk.org Tue Jun 6 19:23:19 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 19:23:19 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v7] In-Reply-To: <2PLnY7FEoIW4top-ZGF-2G6gsMBOBt01nG2bO67lwfg=.cd7fa109-d4ba-4bcf-8501-b0e6a184426c@github.com> References: <2PLnY7FEoIW4top-ZGF-2G6gsMBOBt01nG2bO67lwfg=.cd7fa109-d4ba-4bcf-8501-b0e6a184426c@github.com> Message-ID: On Tue, 6 Jun 2023 18:18:43 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #5) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/java.base/share/classes/sun/security/util/PBEUtil.java line 347: > >> 345: "Salt or iteration count parameters are " + >> 346: "not consistent with PBE key"); >> 347: } > > Based on the javadoc of PBEKey, it's possible that salt and ic aren't specified, e.g. null and 0. In this case, this check will fail if the PBEParameterSpec contains salt and ic. IIRC, the java impl will use the values from PBEParameterSpec in this case. Perhaps we can consider same handling? This can be handled separately by tracking this under a separate bug as it's getting too close to RPD1 already. The PBEUtil::checkKeyAndParams function is used by SunPKCS11 only (see P11PBECipher::engineInit and P11Mac::engineInit), and the keys passed are always P11Key instances. Thus, a P11Key that is also a PBEKey is a P11PBEKey, and both the salt and iteration count for these keys are properly set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1220191902 From mbalao at openjdk.org Tue Jun 6 19:43:29 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 6 Jun 2023 19:43:29 GMT Subject: Integrated: 8301553: Support Password-Based Cryptography in SunPKCS11 In-Reply-To: References: Message-ID: <2nR3RJ5ug0K_s_xDifTrySDisn2IcS0PIuz5v-DhdCg=.cb46a147-540f-437f-a425-20207ebe618e@github.com> On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote: > We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. > > In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): > > * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PB... This pull request has now been integrated. Changeset: 4a75fd46 Author: Martin Balao URL: https://git.openjdk.org/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 Stats: 3273 lines in 30 files changed: 2826 ins; 265 del; 182 mod 8301553: Support Password-Based Cryptography in SunPKCS11 Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/12396 From jjg at openjdk.org Tue Jun 6 22:12:34 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 6 Jun 2023 22:12:34 GMT Subject: Integrated: 8309570: ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 22:01:10 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java on macosx-x64 and windows-x64. > > The test is already ProblemListed on linux-all. Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14343#pullrequestreview-1466192317 From dcubed at openjdk.org Tue Jun 6 22:12:34 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 6 Jun 2023 22:12:34 GMT Subject: Integrated: 8309570: ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java Message-ID: A trivial fix to ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java on macosx-x64 and windows-x64. The test is already ProblemListed on linux-all. ------------- Commit messages: - 8309570: ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java Changes: https://git.openjdk.org/jdk/pull/14343/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14343&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309570 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14343.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14343/head:pull/14343 PR: https://git.openjdk.org/jdk/pull/14343 From darcy at openjdk.org Tue Jun 6 22:12:34 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 6 Jun 2023 22:12:34 GMT Subject: Integrated: 8309570: ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 22:01:10 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java on macosx-x64 and windows-x64. > > The test is already ProblemListed on linux-all. Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14343#pullrequestreview-1466192457 From dcubed at openjdk.org Tue Jun 6 22:12:35 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 6 Jun 2023 22:12:35 GMT Subject: Integrated: 8309570: ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 22:05:22 GMT, Jonathan Gibbons wrote: >> A trivial fix to ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java on macosx-x64 and windows-x64. >> >> The test is already ProblemListed on linux-all. > > Marked as reviewed by jjg (Reviewer). @jonathan-gibbons and @jddarcy - Thanks for the lightning fast reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14343#issuecomment-1579514623 From dcubed at openjdk.org Tue Jun 6 22:12:35 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 6 Jun 2023 22:12:35 GMT Subject: Integrated: 8309570: ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 22:01:10 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java on macosx-x64 and windows-x64. > > The test is already ProblemListed on linux-all. This pull request has now been integrated. Changeset: 0ceb4322 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/0ceb43227d1bcc8e709d66071e6ae11fcf0090fc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8309570: ProblemList sun/security/pkcs11/Signature/TestRSAKeyLength.java Reviewed-by: jjg, darcy ------------- PR: https://git.openjdk.org/jdk/pull/14343 From duke at openjdk.org Tue Jun 6 22:27:05 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 6 Jun 2023 22:27:05 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again Message-ID: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to DSA tests ------------- Commit messages: - Updated copywrite - Removed redundant call to getSigningRandom, fixed test formatting - Added test for RNG rest - Removed misplaced call to getSigningRandom - Added RNG reset in initSign Changes: https://git.openjdk.org/jdk/pull/14273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308474 Stats: 71 lines in 2 files changed: 70 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14273/head:pull/14273 PR: https://git.openjdk.org/jdk/pull/14273 From weijun at openjdk.org Tue Jun 6 22:27:10 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 6 Jun 2023 22:27:10 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again In-Reply-To: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> Message-ID: On Thu, 1 Jun 2023 21:17:11 GMT, Ben Perez wrote: > Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to DSA tests src/java.base/share/classes/sun/security/provider/DSA.java line 1: > 1: /* Update the copyright year for this file. src/java.base/share/classes/sun/security/provider/DSA.java line 163: > 161: // reset signing random > 162: this.signingRandom = null; > 163: this.signingRandom = getSigningRandom(); First, no need to set twice. Second, if you assign `getSigningRandom()` here, all other lazy `getSigningRandom()` calls become useless. test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 28: > 26: * @bug 8308474 > 27: * @summary Test that calling initSign resets RNG > 28: * @run main SecureRandomReset Not necessary if this is the only action in the test. Some people think this is clearer, though. For me, I have copied an existing test to create a new one and forgot to modify this line before. test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 45: > 43: Signature s = Signature.getInstance("SHA256withDSA"); > 44: > 45: //Initialize deterministic RNG and sign We usually add a space after `//`. test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 53: > 51: String sig2 = HexFormat.of().formatHex(s.sign()); > 52: > 53: if (!sig1.equals(sig2)) { If you only want to compare, there is no need to covert the byte arrays to strings. Just call `Arrays.equals(l,r)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1219733876 PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1219725409 PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1219732401 PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1219727531 PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1219726822 From duke at openjdk.org Tue Jun 6 22:27:12 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 6 Jun 2023 22:27:12 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again In-Reply-To: References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> Message-ID: On Tue, 6 Jun 2023 14:12:22 GMT, Weijun Wang wrote: >> Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to DSA tests > > test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 28: > >> 26: * @bug 8308474 >> 27: * @summary Test that calling initSign resets RNG >> 28: * @run main SecureRandomReset > > Not necessary if this is the only action in the test. Some people think this is clearer, though. For me, I have copied an existing test to create a new one and forgot to modify this line before. Would you prefer I take this out? I see the concern about accidentally copy/pasting incorrect test information but having the bug number is kind of nice ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1220030524 From weijun at openjdk.org Tue Jun 6 22:27:12 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 6 Jun 2023 22:27:12 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again In-Reply-To: References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> Message-ID: On Tue, 6 Jun 2023 17:13:36 GMT, Ben Perez wrote: >> test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 28: >> >>> 26: * @bug 8308474 >>> 27: * @summary Test that calling initSign resets RNG >>> 28: * @run main SecureRandomReset >> >> Not necessary if this is the only action in the test. Some people think this is clearer, though. For me, I have copied an existing test to create a new one and forgot to modify this line before. > > Would you prefer I take this out? I see the concern about accidentally copy/pasting incorrect test information but having the bug number is kind of nice I would take it out. And, I was only talking about the `@run` line. All others are totally fine. The `@test` is necessary for a test, otherwise jtreg would not run it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1220036952 From duke at openjdk.org Tue Jun 6 22:29:25 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 6 Jun 2023 22:29:25 GMT Subject: RFR: 8307144: namedParams in XECParameters and EdDSAParameters can be private final Message-ID: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` ------------- Commit messages: - Formatted to adhere to the blessed modifier order - Fixed accidental newline - Formatting changes - Changed namedParams to be private final static - Revert "Changed namedParams to be private final" - Changed namedParams to be private final Changes: https://git.openjdk.org/jdk/pull/14162/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307144 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14162/head:pull/14162 PR: https://git.openjdk.org/jdk/pull/14162 From robilad at openjdk.org Tue Jun 6 22:29:25 2023 From: robilad at openjdk.org (Dalibor Topic) Date: Tue, 6 Jun 2023 22:29:25 GMT Subject: RFR: 8307144: namedParams in XECParameters and EdDSAParameters can be private final In-Reply-To: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> References: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Message-ID: On Thu, 25 May 2023 21:17:40 GMT, Ben Perez wrote: > Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` Hi Ben, Please send an e-mail to dalibor.topic at oracle.com so that I can mark your account as verified. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14162#issuecomment-1571013997 From cslucas at openjdk.org Tue Jun 6 23:14:14 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 6 Jun 2023 23:14:14 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v17] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Rome minor refactorings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/cb0b6702..14ddb63a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=15-16 Stats: 12 lines in 5 files changed: 6 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From jnimeh at openjdk.org Wed Jun 7 04:09:55 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 7 Jun 2023 04:09:55 GMT Subject: RFR: 8307144: namedParams in XECParameters and EdDSAParameters can be private final In-Reply-To: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> References: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Message-ID: On Thu, 25 May 2023 21:17:40 GMT, Ben Perez wrote: > Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` Looks good to me. Just a minor nit in each file: The copyrights on line 2 in each file could be updated to 2023. ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14162#pullrequestreview-1466560004 From xuelei at openjdk.org Wed Jun 7 06:25:56 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 7 Jun 2023 06:25:56 GMT Subject: RFR: 8307144: namedParams in XECParameters and EdDSAParameters can be private final In-Reply-To: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> References: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Message-ID: On Thu, 25 May 2023 21:17:40 GMT, Ben Perez wrote: > Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` Marked as reviewed by xuelei (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14162#pullrequestreview-1466696530 From avu at openjdk.org Wed Jun 7 07:00:59 2023 From: avu at openjdk.org (Alexey Ushakov) Date: Wed, 7 Jun 2023 07:00:59 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:01:37 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > update Marked as reviewed by avu (Committer). The latest changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1466776433 PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1580043192 From duke at openjdk.org Wed Jun 7 07:03:57 2023 From: duke at openjdk.org (Bernd) Date: Wed, 7 Jun 2023 07:03:57 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again In-Reply-To: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> Message-ID: <38mEKqMtG4kyJAoaYwNjZpxwTXHR9ISt0mGWm_IGZjA=.729b0ada-43f1-4a59-9cf7-2a2a15d9be75@github.com> On Thu, 1 Jun 2023 21:17:11 GMT, Ben Perez wrote: > Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to DSA tests test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 51: > 49: > 50: // Re-initialize deterministic RNG and sign > 51: s.initSign(sk, deterministic()); Does this test depend on the fact that if the reset was missing it would ask the first deterministic RNG for a second random number which (?by luck?) is different from the first number of a re-seeded second instance? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1220996922 From mullan at openjdk.org Wed Jun 7 19:41:49 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 7 Jun 2023 19:41:49 GMT Subject: RFR: 8307144: namedParams in XECParameters and EdDSAParameters can be private final In-Reply-To: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> References: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Message-ID: On Thu, 25 May 2023 21:17:40 GMT, Ben Perez wrote: > Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` src/jdk.crypto.ec/share/classes/sun/security/ec/XECParameters.java line 45: > 43: static final XECParameters X448; > 44: > 45: private static final ParametersMap namedParams = new ParametersMap<>(); Small code style comment - we try to keep our code lines to 80 characters or less as it avoids scrolling for things like split screen code reviews. Suggest putting a line break after `=` and indenting the next line four spaces, ex: private static final ParametersMap namedParams = new ParametersMap<>(); Same comment below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14162#discussion_r1222076066 From duke at openjdk.org Wed Jun 7 19:56:49 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 7 Jun 2023 19:56:49 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again In-Reply-To: <38mEKqMtG4kyJAoaYwNjZpxwTXHR9ISt0mGWm_IGZjA=.729b0ada-43f1-4a59-9cf7-2a2a15d9be75@github.com> References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> <38mEKqMtG4kyJAoaYwNjZpxwTXHR9ISt0mGWm_IGZjA=.729b0ada-43f1-4a59-9cf7-2a2a15d9be75@github.com> Message-ID: On Wed, 7 Jun 2023 07:00:45 GMT, Bernd wrote: >> Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to DSA tests > > test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 51: > >> 49: >> 50: // Re-initialize deterministic RNG and sign >> 51: s.initSign(sk, deterministic()); > > Does this test depend on the fact that if the reset was missing it would ask the first deterministic RNG for a second random number which (?by luck?) is different from the first number of a re-seeded second instance? It does - I'll change the test to not have this potential failure mode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1222088990 From cslucas at openjdk.org Wed Jun 7 20:22:01 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 7 Jun 2023 20:22:01 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v13] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Tue, 23 May 2023 17:19:23 GMT, Vladimir Ivanov wrote: >>> I verified that the new test cases do trigger SR+NSR scenario. >>> >>> How do you test that deoptimization works as expected? >>> >> >> I have a copy of the tests in AllocationMergesTests.java in a separate file (not included in this PR) and I run the tests with a tool that compares the output of the test with RAM enabled and disabled. So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled. >> >>> Diagnostic output is still hard to read. On one hand, it's too verbose when it comes to PcDesc/ScopeDesc sections ("pc-bytecode offsets" and "scopes") in nmethod output (enabled either w/ `-XX:+PrintAssembly` or `-XX:CompileCommand=print,...`). On the other hand, it lacks some important details, like `selector` and `merge_ptr` location information which is essential to make sense of debug information at a safepoint in the code. >>> >> >> I'll take care of that. I was testing only with PrintDebugInfo. >> >>> FTR `_skip_rematerialization` flag is unused now. >>> >> >> yeah, I forgot to remove that. Thanks. >> >>> Speaking of `_only_merge_candidate` flag, I find it easier about the code when the property being tracked is whether the `ObjectValue` is referenced from corresponding JVM state or not. (Maybe call it `is_root()`?) So, `ScopeDesc::objects_to_rematerialize()` would skip everything not referenced from JVM state, but then unconditionally accept anything returned by `ObjectMergeValue::select()` which doesn't need to adjust the flag before returning selected object. Also, it's safer to track the flag status for every `ObjectValues`, even for `ObjectMergeValue`. >>> >> >> Sounds like a good idea. I'll do that. Thanks. >> >>> Are you sure there's no way to end up with nested `ObjectMergeValue`s in presence of iterative EA? >> >> I don't think so. This current patch only handle Phis that don't have NULL as input. As part of the reduction process we set at least one of the reducible Phi inputs to NULL. Therefore, subsequent iterations of EA won't reduce the same Phi. > >> So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled. > > Please, enhance `AllocationMergesTests` to cover deoptimization (e.g., using WhiteBox API or additional run w/ -XX:+DeoptimizeALot) and ensure that tests are sensitive enough to fail when wrong state is rematerialized. @iwanowww - I pushed some changes to address your feedback. Please let me know if you have any more comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1581452155 From mbalao at openjdk.org Wed Jun 7 20:31:18 2023 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 7 Jun 2023 20:31:18 GMT Subject: RFR: 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 Message-ID: We would like to propose a fix for 8309569. In this bug, a Java signature buffer of length 0 is passed to sun.security.pkcs11.wrapper.PKCS11::C_VerifyFinal to finish an ongoing signature verification operation. Notice that finishing the operation by means of C_SessionCancel was either not tried ?as in software tokens implementing a standard of PKCS # 11 previous to 3? or failed, and finishing the operation with C_VerifyFinal is used as a last resort. Before calling the native C_VerifyFinal function, the signature buffer is converted from Java to native in jByteArrayToCKByteArray. Previous to 8301553, calloc was called with length 0 and, in most platforms, returns an address different from NULL. This non-NULL value was okay to the NSS Software Token [1], nothing was read because the length was 0 and the operation was finally cancelled. After 8301553, we made jByteArrayToCKByteArray to return NULL in cases of length 0 in the spirit of aligning different calloc implementations to a single path. The scope of the change is not limited to jByteArrayToCKByteArray but to other 4 analogous conversion functions in p11_util.c. We propose to revert the behavior to the state previous to 8301553 ?in other words, calling calloc in cases of length 0? but avoiding an OOM exception if calloc returns NULL because of a length 0. For implementations where calloc returns NULL upon a 0 length, an OOM exception does not reflect what really happened. In these cases, it's up to the native PKCS # 11 library to handle the case. -- [1] - https://github.com/nss-dev/nss/blob/NSS_3_67_RTM/lib/softoken/pkcs11c.c#L3823 ------------- Commit messages: - 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 (iteration #0) Changes: https://git.openjdk.org/jdk/pull/14369/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309569 Stats: 39 lines in 2 files changed: 10 ins; 5 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/14369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14369/head:pull/14369 PR: https://git.openjdk.org/jdk/pull/14369 From duke at openjdk.org Wed Jun 7 20:58:49 2023 From: duke at openjdk.org (Bernd) Date: Wed, 7 Jun 2023 20:58:49 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again In-Reply-To: References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> <38mEKqMtG4kyJAoaYwNjZpxwTXHR9ISt0mGWm_IGZjA=.729b0ada-43f1-4a59-9cf7-2a2a15d9be75@github.com> Message-ID: On Wed, 7 Jun 2023 19:53:26 GMT, Ben Perez wrote: >> test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 51: >> >>> 49: >>> 50: // Re-initialize deterministic RNG and sign >>> 51: s.initSign(sk, deterministic()); >> >> Does this test depend on the fact that if the reset was missing it would ask the first deterministic RNG for a second random number which (?by luck?) is different from the first number of a re-seeded second instance? > > It does - I'll change the test to not have this potential failure mode. I think it?s fine (just wanted to make sure i understood the problem correctly), especially with the fixed seed. You could just comment it with ?with this seed the first two invocations produce different material? or something like that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1222166568 From weijun at openjdk.org Wed Jun 7 21:17:50 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 7 Jun 2023 21:17:50 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again In-Reply-To: References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> <38mEKqMtG4kyJAoaYwNjZpxwTXHR9ISt0mGWm_IGZjA=.729b0ada-43f1-4a59-9cf7-2a2a15d9be75@github.com> Message-ID: <_qPa3K9S9afK9EiB7SpNE0G6Ow0R9UjOK4Sy4suXRlk=.f3e5c72d-e4ba-4174-a8ee-5a3f2fbe2da8@github.com> On Wed, 7 Jun 2023 20:55:55 GMT, Bernd wrote: >> It does - I'll change the test to not have this potential failure mode. > > I think it?s fine (just wanted to make sure i understood the problem correctly), especially with the fixed seed. You could just comment it with ?with this seed the first two invocations produce different material? or something like that? Any random source should return different bytes when its `nextBytes` is called again. The major point here is when we see the same signature is generated, we can be sure the 2nd call to `initSign` does reinitiate the state of the random source inside to be exactly the same when the 1st `initSign` was called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14273#discussion_r1222185021 From mchung at openjdk.org Wed Jun 7 21:37:04 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 7 Jun 2023 21:37:04 GMT Subject: RFR: 8305104: Remove old core reflection implementation Message-ID: JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported. Those issues were related with exception being thrown with invalid arguments. We propose to remove the old core reflection implementation in JDK 22. The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work. ------------- Commit messages: - clean up - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection - merge - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection - 8305104: Remove the old core reflection implementation Changes: https://git.openjdk.org/jdk/pull/14371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14371&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305104 Stats: 6319 lines in 78 files changed: 13 ins; 6238 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/14371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14371/head:pull/14371 PR: https://git.openjdk.org/jdk/pull/14371 From kdriver at openjdk.org Wed Jun 7 21:40:14 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 7 Jun 2023 21:40:14 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v26] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: latest version of TLS1.2 test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/af035c39..b90cee85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=24-25 Stats: 83 lines in 2 files changed: 37 ins; 36 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From valeriep at openjdk.org Wed Jun 7 22:25:50 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 7 Jun 2023 22:25:50 GMT Subject: RFR: 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 In-Reply-To: References: Message-ID: On Wed, 7 Jun 2023 20:24:12 GMT, Martin Balao wrote: > We would like to propose a fix for 8309569. In this bug, a Java signature buffer of length 0 is passed to sun.security.pkcs11.wrapper.PKCS11::C_VerifyFinal to finish an ongoing signature verification operation. Notice that finishing the operation by means of C_SessionCancel was either not tried ?as in software tokens implementing a standard of PKCS # 11 previous to 3? or failed, and finishing the operation with C_VerifyFinal is used as a last resort. Before calling the native C_VerifyFinal function, the signature buffer is converted from Java to native in jByteArrayToCKByteArray. Previous to 8301553, calloc was called with length 0 and, in most platforms, returns an address different from NULL. This non-NULL value was okay to the NSS Software Token [1], nothing was read because the length was 0 and the operation was finally cancelled. After 8301553, we made jByteArrayToCKByteArray to return NULL in cases of length 0 in the spirit of aligning different calloc implementations to a single path. The scope of the change is not limited to jByteArrayToCKByteArray but to other 4 analogous conversion functions in p11_util.c. > > We propose to revert the behavior to the state previous to 8301553 ?in other words, calling calloc in cases of length 0? but avoiding an OOM exception if calloc returns NULL because of a length 0. For implementations where calloc returns NULL upon a 0 length, an OOM exception does not reflect what really happened. In these cases, it's up to the native PKCS # 11 library to handle the case. > > -- > [1] - https://github.com/nss-dev/nss/blob/NSS_3_67_RTM/lib/softoken/pkcs11c.c#L3823 I will take a look and run the mach5 job also, just to be sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14369#issuecomment-1581591962 From kdriver at openjdk.org Wed Jun 7 23:05:24 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 7 Jun 2023 23:05:24 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v27] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver 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 31 additional commits since the last revision: - format server payload to 80 chars - Merge remote-tracking branch 'upstream/master' into JDK-8294985 - latest version of TLS1.2 test - undo import changes - undo import changes - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985 - wrapping - addressed remaining code review comments - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985 - run tests with othervm - ... and 21 more: https://git.openjdk.org/jdk/compare/815bad3d...78ad62aa ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/b90cee85..78ad62aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=25-26 Stats: 53610 lines in 743 files changed: 44001 ins; 7004 del; 2605 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From valeriep at openjdk.org Thu Jun 8 00:42:50 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 8 Jun 2023 00:42:50 GMT Subject: RFR: 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 In-Reply-To: References: Message-ID: <2UeoDbvLoPst4R1yg4wL1teXaHn7YEB7tAh2E2a7Mso=.05087343-f706-406c-823a-53040c71f0bf@github.com> On Wed, 7 Jun 2023 20:24:12 GMT, Martin Balao wrote: > We would like to propose a fix for 8309569. In this bug, a Java signature buffer of length 0 is passed to sun.security.pkcs11.wrapper.PKCS11::C_VerifyFinal to finish an ongoing signature verification operation. Notice that finishing the operation by means of C_SessionCancel was either not tried ?as in software tokens implementing a standard of PKCS # 11 previous to 3? or failed, and finishing the operation with C_VerifyFinal is used as a last resort. Before calling the native C_VerifyFinal function, the signature buffer is converted from Java to native in jByteArrayToCKByteArray. Previous to 8301553, calloc was called with length 0 and, in most platforms, returns an address different from NULL. This non-NULL value was okay to the NSS Software Token [1], nothing was read because the length was 0 and the operation was finally cancelled. After 8301553, we made jByteArrayToCKByteArray to return NULL in cases of length 0 in the spirit of aligning different calloc implementations to a single path. The scope of the change is not limited to jByteArrayToCKByteArray but to other 4 analogous conversion functions in p11_util.c. > > We propose to revert the behavior to the state previous to 8301553 ?in other words, calling calloc in cases of length 0? but avoiding an OOM exception if calloc returns NULL because of a length 0. For implementations where calloc returns NULL upon a 0 length, an OOM exception does not reflect what really happened. In these cases, it's up to the native PKCS # 11 library to handle the case. > > -- > [1] - https://github.com/nss-dev/nss/blob/NSS_3_67_RTM/lib/softoken/pkcs11c.c#L3823 Looks good. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14369#pullrequestreview-1468783187 From mbalao at openjdk.org Thu Jun 8 01:27:55 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 8 Jun 2023 01:27:55 GMT Subject: Integrated: 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 In-Reply-To: References: Message-ID: On Wed, 7 Jun 2023 20:24:12 GMT, Martin Balao wrote: > We would like to propose a fix for 8309569. In this bug, a Java signature buffer of length 0 is passed to sun.security.pkcs11.wrapper.PKCS11::C_VerifyFinal to finish an ongoing signature verification operation. Notice that finishing the operation by means of C_SessionCancel was either not tried ?as in software tokens implementing a standard of PKCS # 11 previous to 3? or failed, and finishing the operation with C_VerifyFinal is used as a last resort. Before calling the native C_VerifyFinal function, the signature buffer is converted from Java to native in jByteArrayToCKByteArray. Previous to 8301553, calloc was called with length 0 and, in most platforms, returns an address different from NULL. This non-NULL value was okay to the NSS Software Token [1], nothing was read because the length was 0 and the operation was finally cancelled. After 8301553, we made jByteArrayToCKByteArray to return NULL in cases of length 0 in the spirit of aligning different calloc implementations to a single path. The scope of the change is not limited to jByteArrayToCKByteArray but to other 4 analogous conversion functions in p11_util.c. > > We propose to revert the behavior to the state previous to 8301553 ?in other words, calling calloc in cases of length 0? but avoiding an OOM exception if calloc returns NULL because of a length 0. For implementations where calloc returns NULL upon a 0 length, an OOM exception does not reflect what really happened. In these cases, it's up to the native PKCS # 11 library to handle the case. > > -- > [1] - https://github.com/nss-dev/nss/blob/NSS_3_67_RTM/lib/softoken/pkcs11c.c#L3823 This pull request has now been integrated. Changeset: 760cb04a Author: Martin Balao URL: https://git.openjdk.org/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d Stats: 39 lines in 2 files changed: 10 ins; 5 del; 24 mod 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 Co-authored-by: Martin Balao Co-authored-by: Francisco Ferrari Bihurriet Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/14369 From mdonovan at openjdk.org Thu Jun 8 14:32:04 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 8 Jun 2023 14:32:04 GMT Subject: RFR: 8309305: sun/security/ssl/SSLSocketImpl/BlockedAsyncClose.java fails with jtreg test timeout Message-ID: This PR improves the reliability of the BlockedAsyncClose test by addressing an edge case/race condition between the two test threads. The purpose of the test is to verify that an SSLSocket can be closed if a thread is blocked in a write operation. The test starts a "write" thread that writes data to a socket until the output buffer was filled, causing the write operation to block. The main thread then calls `SSLSocket.close()`. The original code used `Thread.sleep(1000)` to wait for the write-thread to block. However, 1 second isn't always long enough and if the write-thread isn't blocked and the output buffer is full (or almost full), the `socket.close()` call may block when it tries to send the close_notify alert. This is the condition that caused this bug. My change uses a Lock to determine if the write thread is blocked. In the write thread, the lock creates a critical section around the `write()` call. The main thread uses `tryLock()` with a timeout to determine that the write() call is taking too long and thus likely blocked. While there, I also updated the test to use the SSLContextTemplate class. ------------- Commit messages: - 8309305: sun/security/ssl/SSLSocketImpl/BlockedAsyncClose.java fails with jtreg test timeout Changes: https://git.openjdk.org/jdk/pull/14378/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14378&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309305 Stats: 57 lines in 1 file changed: 20 ins; 24 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14378/head:pull/14378 PR: https://git.openjdk.org/jdk/pull/14378 From duke at openjdk.org Thu Jun 8 15:45:09 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 8 Jun 2023 15:45:09 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again [v2] In-Reply-To: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> Message-ID: > Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to DSA tests Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Formatting changes, updated copywrite ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14273/files - new: https://git.openjdk.org/jdk/pull/14273/files/1e5ea144..314c7f16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14273&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14273&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14273/head:pull/14273 PR: https://git.openjdk.org/jdk/pull/14273 From weijun at openjdk.org Thu Jun 8 16:31:53 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 8 Jun 2023 16:31:53 GMT Subject: RFR: 8308474: DSA does not reset SecureRandom when initSign is called again [v2] In-Reply-To: References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> Message-ID: <-B4zCfBtFh6D6QPdDBXmromxlQbmycDPreqpywEDvFk=.42e69714-2747-4899-9366-e72b9c6bc7d7@github.com> On Thu, 8 Jun 2023 15:45:09 GMT, Ben Perez wrote: >> Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to DSA tests > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes, updated copywrite Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14273#pullrequestreview-1470366022 From duke at openjdk.org Thu Jun 8 17:14:30 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 8 Jun 2023 17:14:30 GMT Subject: RFR: 8307144: namedParams in XECParameters and EdDSAParameters can be private final [v2] In-Reply-To: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> References: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Message-ID: > Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Updated copywrite, added line breaks for readability ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14162/files - new: https://git.openjdk.org/jdk/pull/14162/files/f870eec4..86932d58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14162&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14162&range=00-01 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14162/head:pull/14162 PR: https://git.openjdk.org/jdk/pull/14162 From jjg at openjdk.org Thu Jun 8 17:29:59 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Jun 2023 17:29:59 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> Message-ID: <4aXf_OR_EF_CqqIhswGgOr0dZeHEoJRPRIAIQHtTHD4=.3849ecb7-c0c1-41bf-b81e-b823eb882899@github.com> On Wed, 5 Apr 2023 16:45:06 GMT, Jonathan Gibbons wrote: >> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248) > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback keep-alive comment ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1583064392 From mullan at openjdk.org Thu Jun 8 17:38:25 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 8 Jun 2023 17:38:25 GMT Subject: RFR: 8307144: namedParams in XECParameters and EdDSAParameters can be private final [v2] In-Reply-To: References: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Message-ID: On Thu, 8 Jun 2023 17:14:30 GMT, Ben Perez wrote: >> Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Updated copywrite, added line breaks for readability Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14162#pullrequestreview-1470464496 From jjg at openjdk.org Thu Jun 8 20:18:46 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Jun 2023 20:18:46 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> Message-ID: On Wed, 5 Apr 2023 16:45:06 GMT, Jonathan Gibbons wrote: >> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248) > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback I checked out references to `nist.gov`. I found 7 references to 4 documents: $ grep -r '*.*href=[^ ]*nist.gov' open/src/java.base | grep -o 'nist.gov[^"]*' nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf nist.gov/publications/fips/fips186-3/fips_186-3.pdf nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> Of these 4, 1 shows a page that says the spec has been superseded, and one is effectively a 404 Oops, that's not standard?! Sorry, we cannot find that page. The page you requested cannot be found at this time. I would like to defer these issues to be handled separately, and add `@spec` tags for these pages later, once the appropriate specs have been identified. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1583280716 From jjg at openjdk.org Thu Jun 8 20:49:49 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Jun 2023 20:49:49 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> Message-ID: On Thu, 8 Jun 2023 20:16:21 GMT, Jonathan Gibbons wrote: > I checked out references to `nist.gov`. > > I found 7 references to 4 documents: > > ``` > $ grep -r '*.*href=[^ ]*nist.gov' open/src/java.base | grep -o 'nist.gov[^"]*' > nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf > nist.gov/publications/fips/fips186-3/fips_186-3.pdf > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > ``` > > Of these 4, 1 shows a page that says the spec has been superseded, and one is effectively a 404 > > ``` > Oops, that's not standard?! > Sorry, we cannot find that page. > > The page you requested cannot be found at this time. > ``` > > I would like to defer these issues to be handled separately, and add `@spec` tags for these pages later, once the appropriate specs have been identified. Update, the apparent 404 is explained by a scripting error, due to an unquoted attribute value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1583319302 From jjg at openjdk.org Thu Jun 8 21:20:07 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Jun 2023 21:20:07 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v4] In-Reply-To: References: Message-ID: > Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248) Jonathan Gibbons 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 five additional commits since the last revision: - Add @spec tags for nist.gov docs - Merge remote-tracking branch 'upstream/master' into 8305406.at-spec-java.base-java-2-javax - Address review feedback - Update src/java.base/share/classes/java/security/cert/X509Certificate.java Co-authored-by: Daniel Jelinski - JDK-8305406: Add @spec tags in java.base/java.* (part 2) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13336/files - new: https://git.openjdk.org/jdk/pull/13336/files/03a70694..1b997359 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13336&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13336&range=02-03 Stats: 554345 lines in 6384 files changed: 454872 ins; 53914 del; 45559 mod Patch: https://git.openjdk.org/jdk/pull/13336.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13336/head:pull/13336 PR: https://git.openjdk.org/jdk/pull/13336 From vladimir.petko at canonical.com Fri Jun 9 09:09:25 2023 From: vladimir.petko at canonical.com (Vladimir Petko) Date: Fri, 9 Jun 2023 21:09:25 +1200 Subject: test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java fails on Ubuntu 23.10 AMD64 Message-ID: Hi, test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java[1] fails on Ubuntu Lunar (amd64) with CKR_GENERAL_ERROR . Reordering certificate addition (0001-CertChainRemoval-reorder-certificates.patch) allows the test to pass, but it may indicate a more serious underlying problem with library compatibility. Best Regards, Vladimir. -------------- next part -------------- A non-text attachment was scrubbed... Name: CertChainRemoval.jtr.gz Type: application/gzip Size: 3530 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CertChainRemoval-reorder-certificates.patch Type: text/x-patch Size: 3325 bytes Desc: not available URL: From fferrari at redhat.com Fri Jun 9 10:08:49 2023 From: fferrari at redhat.com (Francisco Ferrari Bihurriet) Date: Fri, 9 Jun 2023 12:08:49 +0200 Subject: test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java fails on Ubuntu 23.10 AMD64 In-Reply-To: References: Message-ID: <9ab7e94d-053b-476d-2362-c96ea76f910f@redhat.com> Hi Vladimir, This seems to be the same that is reported in a JDK-8301154 comment [1], we incidentally hit this when fixing JDK-8309569 [2]. It was failing on Martin Balao's Fedora machine with an older NSS version and working on my newer Fedora with NSS 3.89. Copying Valerie for awareness just in case she missed the Jira comment. [1] https://bugs.openjdk.org/browse/JDK-8301154?focusedCommentId=14585577&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14585577 [2] https://bugs.openjdk.org/browse/JDK-8309569 On 6/9/23 11:09, Vladimir Petko wrote: > Hi, > > test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java[1] fails > on Ubuntu Lunar (amd64) with CKR_GENERAL_ERROR . > Reordering certificate addition > (0001-CertChainRemoval-reorder-certificates.patch) allows the test to > pass, but it may indicate a more serious underlying problem with > library compatibility. > > Best Regards, > Vladimir. Regards, -- Francisco From duke at openjdk.org Fri Jun 9 10:17:44 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 9 Jun 2023 10:17:44 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> Message-ID: On Thu, 8 Jun 2023 20:46:41 GMT, Jonathan Gibbons wrote: > > I checked out references to `nist.gov`. > > I found 7 references to 4 documents: > > ``` > > $ grep -r '*.*href=[^ ]*nist.gov' open/src/java.base | grep -o 'nist.gov[^"]*' > > nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf > > nist.gov/publications/fips/fips186-3/fips_186-3.pdf > > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf > > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > > ``` > > Of these 4, 1 shows a page that says the spec has been superseded, and one is effectively a 404 > > ``` > > Oops, that's not standard?! > > Sorry, we cannot find that page. > > > > The page you requested cannot be found at this time. > > ``` > > > > I would like to defer these issues to be handled separately, and add `@spec` tags for these pages later, once the appropriate specs have been identified. > > Update, the apparent 404 is explained by a scripting error, due to an unquoted attribute value. The site name in the urls has changed to nvlpubs.nist.gov . For the DSS, the latest version in which DSA is described is nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf . It will be with withdrawn on February 23, 2024, though, and the superseding FIPS 186-5 standard says that it can only be used for signature verification from then on, but for the algorithm description it points back to FIPS 186-4. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1584332934 From vladimir.petko at canonical.com Fri Jun 9 12:31:14 2023 From: vladimir.petko at canonical.com (Vladimir Petko) Date: Sat, 10 Jun 2023 00:31:14 +1200 Subject: test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java fails on Ubuntu 23.10 AMD64 In-Reply-To: <9ab7e94d-053b-476d-2362-c96ea76f910f@redhat.com> References: <9ab7e94d-053b-476d-2362-c96ea76f910f@redhat.com> Message-ID: Hi, I have run the test in Mantic, which has NSS 3.89[1], and got the same failure. Best Regards, Vladimir. [1] https://launchpad.net/ubuntu/+source/nss/2:3.89-2 On Fri, Jun 9, 2023 at 10:09?PM Francisco Ferrari Bihurriet wrote: > > Hi Vladimir, > > This seems to be the same that is reported in a JDK-8301154 comment [1], > we incidentally hit this when fixing JDK-8309569 [2]. > > It was failing on Martin Balao's Fedora machine with an older NSS > version and working on my newer Fedora with NSS 3.89. > > Copying Valerie for awareness just in case she missed the Jira comment. > > [1] > https://bugs.openjdk.org/browse/JDK-8301154?focusedCommentId=14585577&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14585577 > [2] https://bugs.openjdk.org/browse/JDK-8309569 > > On 6/9/23 11:09, Vladimir Petko wrote: > > Hi, > > > > test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java[1] fails > > on Ubuntu Lunar (amd64) with CKR_GENERAL_ERROR . > > Reordering certificate addition > > (0001-CertChainRemoval-reorder-certificates.patch) allows the test to > > pass, but it may indicate a more serious underlying problem with > > library compatibility. > > > > Best Regards, > > Vladimir. > > Regards, > -- > Francisco > -------------- next part -------------- A non-text attachment was scrubbed... Name: CertChainRemoval.jtr.gz Type: application/gzip Size: 3534 bytes Desc: not available URL: From coffeys at openjdk.org Fri Jun 9 14:03:50 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 9 Jun 2023 14:03:50 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option Message-ID: New functionality in the -XshowSettings menu to display relevant information about JDK security configuration ------------- Commit messages: - minor edits, copyright, descriptions etc - Merge branch 'master' into 8281658-showsettings-security - Merge branch 'master' into 8281658-showsettings-security - 8281658 Changes: https://git.openjdk.org/jdk/pull/14394/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8281658 Stats: 195 lines in 4 files changed: 177 ins; 10 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From rriggs at openjdk.org Fri Jun 9 15:43:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Jun 2023 15:43:46 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration src/java.base/share/classes/sun/launcher/LauncherHelper.java line 65: > 63: import java.text.MessageFormat; > 64: import java.text.Normalizer; > 65: import java.util.*; Wild card imports are discouraged. (Your IDE may have done this behind your back) src/java.base/share/classes/sun/launcher/LauncherHelper.java line 328: > 326: > 327: private static void printSecuritySettings(String arg) { > 328: if (arg.toLowerCase(Locale.ROOT).equals("properties")) { How about a string switch with "all" and default: being the catchall. It would be easier to add others and avoid multiple calls to `toLowerCase`. It might be a good idea for unrecognized settings to print a 1-liner reminder of the valid values, including `all` src/java.base/share/classes/sun/launcher/LauncherHelper.java line 354: > 352: } > 353: } > 354: ostream.print("\n"); or just `ostream.println();` src/java.base/share/classes/sun/launcher/LauncherHelper.java line 363: > 361: SSLContext.getDefault().getSocketFactory().createSocket(); > 362: } catch (IOException | NoSuchAlgorithmException e) { > 363: throw new RuntimeException(e); That's pretty rude of the runtime; perhaps `throw InternalError("Unable to create secure socket")`. It would give some clue that doesn't look like a coding bug. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 376: > 374: System.out.println(THREEINDENT + s); > 375: } > 376: ostream.print("\n"); `ostream.println();` src/java.base/share/classes/sun/launcher/LauncherHelper.java line 393: > 391: } > 392: > 393: // return a string split across multiple lines which aims to limit max width This utility method might be usable in more places if the indentation was an argument instead of hard coded. For example, in `printSecurityProperties`. It might need to be able to split in more places. src/java.base/share/classes/sun/launcher/resources/launcher.properties line 171: > 169: \ -XshowSettings:vm\n\ > 170: \ show all vm related settings and continue\n\ > 171: \ -XshowSettings:security\n\ `all` should probably be documented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224440655 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224444089 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224451282 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224456125 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224457654 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224460749 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224467126 From kdriver at openjdk.org Fri Jun 9 16:02:38 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 9 Jun 2023 16:02:38 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v28] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: test case now catching the proper variety of SSLException (the message is now correct) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/78ad62aa..6f8021f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=26-27 Stats: 40 lines in 1 file changed: 9 ins; 3 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From kdriver at openjdk.org Fri Jun 9 16:19:07 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 9 Jun 2023 16:19:07 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v29] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <0Jb7HmmGKRfaae8PzyhRkItUUSrynw_-YEqhvzFp-Gw=.1b5074be-ef65-49dc-99fe-a149adad22ad@github.com> > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: uniformity in keystore paths ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/6f8021f7..e69abb3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=27-28 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From cslucas at openjdk.org Fri Jun 9 17:19:52 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 9 Jun 2023 17:19:52 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v13] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Tue, 23 May 2023 17:19:23 GMT, Vladimir Ivanov wrote: >>> I verified that the new test cases do trigger SR+NSR scenario. >>> >>> How do you test that deoptimization works as expected? >>> >> >> I have a copy of the tests in AllocationMergesTests.java in a separate file (not included in this PR) and I run the tests with a tool that compares the output of the test with RAM enabled and disabled. So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled. >> >>> Diagnostic output is still hard to read. On one hand, it's too verbose when it comes to PcDesc/ScopeDesc sections ("pc-bytecode offsets" and "scopes") in nmethod output (enabled either w/ `-XX:+PrintAssembly` or `-XX:CompileCommand=print,...`). On the other hand, it lacks some important details, like `selector` and `merge_ptr` location information which is essential to make sense of debug information at a safepoint in the code. >>> >> >> I'll take care of that. I was testing only with PrintDebugInfo. >> >>> FTR `_skip_rematerialization` flag is unused now. >>> >> >> yeah, I forgot to remove that. Thanks. >> >>> Speaking of `_only_merge_candidate` flag, I find it easier about the code when the property being tracked is whether the `ObjectValue` is referenced from corresponding JVM state or not. (Maybe call it `is_root()`?) So, `ScopeDesc::objects_to_rematerialize()` would skip everything not referenced from JVM state, but then unconditionally accept anything returned by `ObjectMergeValue::select()` which doesn't need to adjust the flag before returning selected object. Also, it's safer to track the flag status for every `ObjectValues`, even for `ObjectMergeValue`. >>> >> >> Sounds like a good idea. I'll do that. Thanks. >> >>> Are you sure there's no way to end up with nested `ObjectMergeValue`s in presence of iterative EA? >> >> I don't think so. This current patch only handle Phis that don't have NULL as input. As part of the reduction process we set at least one of the reducible Phi inputs to NULL. Therefore, subsequent iterations of EA won't reduce the same Phi. > >> So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled. > > Please, enhance `AllocationMergesTests` to cover deoptimization (e.g., using WhiteBox API or additional run w/ -XX:+DeoptimizeALot) and ensure that tests are sensitive enough to fail when wrong state is rematerialized. @iwanowww - I want to clarify expectations with my colleagues so I have to ask you how much left are there for you to review and whether there is some part of this PR that you're worried about in terms of correctness/performance/etc? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1584907343 From vlivanov at openjdk.org Fri Jun 9 17:25:55 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 9 Jun 2023 17:25:55 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v17] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Tue, 6 Jun 2023 23:14:14 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Rome minor refactorings. Overall, I like how this patch shapes. I need to go through share/opto changes (so far, I did only a shallow review of that part), but the rest looks good. I plan to submit functional and performance testing over the weekend. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1584913223 From mullan at openjdk.org Fri Jun 9 17:29:49 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 9 Jun 2023 17:29:49 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 18:22:13 GMT, Matthew Donovan wrote: > This PR implements a test to verify that Java will not negotiate TLS connections when one side of the connection requests disabled cipher suites. test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 35: > 33: * @test id=Server > 34: * @bug 8301379 > 35: * @summary Verify that Java will not negotiate disabled cipher suites when the This test could be enhanced to test all of the other suites that are disabled. I think that might be a good idea, to centralize that. Although you could do it as a follow-on RFE. test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 39: > 37: * > 38: * @library /javax/net/ssl/templates > 39: * @run main/othervm TLSWontNegotiateDisabledCipherAlgos server true TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 Consider collapsing all of these run lines into one run line which sets all of the disabled cipher suites together in one handshake. I think you still are testing that none of the suites are negotiated. test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 83: > 81: > 82: if (args[0].equals("server")) { > 83: try(TLSServer server = new TLSServer(useDisabledAlgo, args[2])) { Nit, space after `try` (also on line 98 and 152). test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 119: > 117: public void run() throws IOException { > 118: try { > 119: socket.getOutputStream().write("SECRET MESSAGE".getBytes(StandardCharsets.UTF_8)); Should this fail if this handshake passes? test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 121: > 119: socket.getOutputStream().write("SECRET MESSAGE".getBytes(StandardCharsets.UTF_8)); > 120: } catch (SSLHandshakeException exc) { > 121: // handshake failures are expected Can you inspect the handshake failure message to make sure it is failing for the right reason as you do for the server case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1224569812 PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1224568398 PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1224563096 PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1224566883 PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1224564674 From cslucas at openjdk.org Fri Jun 9 17:35:55 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 9 Jun 2023 17:35:55 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v17] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Tue, 6 Jun 2023 23:14:14 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Rome minor refactorings. Thank you for letting me know! ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1584925728 From valerie.peng at oracle.com Fri Jun 9 18:03:33 2023 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 9 Jun 2023 18:03:33 +0000 Subject: [External] : Re: test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java fails on Ubuntu 23.10 AMD64 In-Reply-To: References: <9ab7e94d-053b-476d-2362-c96ea76f910f@redhat.com> Message-ID: Thanks for the notice. Matthias Baesken already filed a separate bug on this (https://bugs.openjdk.org/browse/JDK-8309214 : https://bugs.openjdk.org/browse/JDK-8309214) and we started exchange info as I can't reproduce the test failure. So you are observing this with NSS 3.89 but Francisco isn't? Hmm... Valerie -----Original Message----- From: Vladimir Petko Sent: Friday, June 9, 2023 5:31 AM To: Francisco Ferrari Bihurriet Cc: security-dev at openjdk.org; Valerie Peng Subject: [External] : Re: test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java fails on Ubuntu 23.10 AMD64 Hi, I have run the test in Mantic, which has NSS 3.89[1], and got the same failure. Best Regards, Vladimir. [1] https://urldefense.com/v3/__https://launchpad.net/ubuntu/*source/nss/2:3.89-2__;Kw!!ACWV5N9M2RV99hQ!PKfA6sQzU8HWMkUYTo49Jp2jma9JaGEg_74UdCHZFC2Va_DgCThkBd2IJk6D1JVbplZpSroctT5oRUzYvoiwJPmohjyfxg$ On Fri, Jun 9, 2023 at 10:09?PM Francisco Ferrari Bihurriet wrote: > > Hi Vladimir, > > This seems to be the same that is reported in a JDK-8301154 comment > [1], we incidentally hit this when fixing JDK-8309569 [2]. > > It was failing on Martin Balao's Fedora machine with an older NSS > version and working on my newer Fedora with NSS 3.89. > > Copying Valerie for awareness just in case she missed the Jira comment. > > [1] > https://bugs.openjdk.org/browse/JDK-8301154?focusedCommentId=14585577& > page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel# > comment-14585577 [2] https://bugs.openjdk.org/browse/JDK-8309569 > > On 6/9/23 11:09, Vladimir Petko wrote: > > Hi, > > > > test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java[1] fails > > on Ubuntu Lunar (amd64) with CKR_GENERAL_ERROR . > > Reordering certificate addition > > (0001-CertChainRemoval-reorder-certificates.patch) allows the test > > to pass, but it may indicate a more serious underlying problem with > > library compatibility. > > > > Best Regards, > > Vladimir. > > Regards, > -- > Francisco > From mullan at openjdk.org Fri Jun 9 18:32:08 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 9 Jun 2023 18:32:08 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Did you consider only showing the security settings if the "security" option is specified? Seems like a lot of data to show in the default case and may not be interesting to many users. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1584984068 From kdriver at openjdk.org Fri Jun 9 19:48:13 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 9 Jun 2023 19:48:13 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v30] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <1fA9ID2isoxs36otij5HANUR6s3WxK2N6SOpflsBQ7M=.ae69cd0e-d8d7-42dd-8275-d8a9b435b491@github.com> > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: fixed server payload once more ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/e69abb3f..50a45b5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=28-29 Stats: 9 lines in 1 file changed: 0 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From wetmore at openjdk.org Fri Jun 9 23:03:34 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 9 Jun 2023 23:03:34 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v30] In-Reply-To: <1fA9ID2isoxs36otij5HANUR6s3WxK2N6SOpflsBQ7M=.ae69cd0e-d8d7-42dd-8275-d8a9b435b491@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <1fA9ID2isoxs36otij5HANUR6s3WxK2N6SOpflsBQ7M=.ae69cd0e-d8d7-42dd-8275-d8a9b435b491@github.com> Message-ID: On Fri, 9 Jun 2023 19:48:13 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > fixed server payload once more Latest change looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1585183418 From kdriver at openjdk.org Fri Jun 9 23:35:07 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 9 Jun 2023 23:35:07 GMT Subject: Integrated: 8294985: SSLEngine throws IAE during parsing of X500Principal In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 13 Apr 2023 18:49:48 GMT, Kevin Driver wrote: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) This pull request has now been integrated. Changeset: 80edd5c2 Author: Kevin Driver Committer: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/80edd5c298f21c5e5be3a0c2bb63129e76e0334f Stats: 486 lines in 4 files changed: 468 ins; 0 del; 18 mod 8294985: SSLEngine throws IAE during parsing of X500Principal Reviewed-by: wetmore, xuelei, mullan ------------- PR: https://git.openjdk.org/jdk/pull/13466 From alanb at openjdk.org Sat Jun 10 07:18:39 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 10 Jun 2023 07:18:39 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option In-Reply-To: References: Message-ID: <8YVrR0xPCqo7X1OykjWSWKmNFTXtrd0kk42zjJvsRrM=.a33af31b-8543-4522-82a7-ddc44029f616@github.com> On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration There is a lot of output and does seem to overwhelm the java -XshowSettings output with detail that I wouldn't expect by default. It's effectively printing conf/java.security and enumerating all the capabilities of the providers and cipher suites. So I think I agree with Sean's suggestion to require the :security sub-option for the detail. We could potentially do this for the available locales too. The -XshowSettings output could include a message at the end about using -XshowSettings:detailed or some such sub-option for more detailed output. In passing, it looks like some of the output is going to stderr, some to stdout, so you might want to check that. Also StringTokenizer is legacy, I don't think we want that in the java launcher code, it looks like it just needs String.split. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1585530294 From weijun at openjdk.org Sat Jun 10 14:44:42 2023 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 10 Jun 2023 14:44:42 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration src/java.base/share/classes/sun/launcher/LauncherHelper.java line 349: > 347: // split lines longer than 60 chars which have multiple values > 348: ostream.println(TWOINDENT + key + "="); > 349: List.of(val.split(",")).forEach(s -> ostream.println(THREEINDENT + s.trim())); You should probably add back `,` when printing them out. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 381: > 379: private static void printSecurityProviderConfig() { > 380: ostream.println(INDENT + "Security provider static configuration:"); > 381: for (Provider p : Security.getProviders()) { Maybe add an empty line or something like `-----` between providers? src/java.base/share/classes/sun/launcher/LauncherHelper.java line 385: > 383: ostream.println(TWOINDENT + "Provider information: " + wrappedString(p.getInfo(), 80)); > 384: ostream.println(TWOINDENT + "Provider services: (type : algorithm)"); > 385: for (Provider.Service ps : p.getServices().stream() If this stream is empty, should you print out something like "none"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1225400656 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1225401386 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1225401803 From asemenov at openjdk.org Sun Jun 11 15:40:28 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Sun, 11 Jun 2023 15:40:28 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 17:47:02 GMT, Weijun Wang wrote: >> This is rarely used in the code and is not the essence of the current changes. >> If you introduce such changes, then throughout the code. >> Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225 > > I'm not a clang expect, I was just asking if modifying the current `#if TARGET_OS_MAC` check into `#if defined(__APPLE__)` is also a solution. The comment on lines 46-47 says the condition was copied from a macOS SDK file and that's what the file is using now. I think you can create a separate ticket and pull request to discuss this issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1225842637 From asemenov at openjdk.org Sun Jun 11 16:38:31 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Sun, 11 Jun 2023 16:38:31 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v5] In-Reply-To: References: Message-ID: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - update - update - update - update - 8308286 Fix clang warnings in linux code ------------- Changes: https://git.openjdk.org/jdk/pull/14033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=04 Stats: 16 lines in 6 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From coffeys at openjdk.org Mon Jun 12 08:55:41 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 12 Jun 2023 08:55:41 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Thanks for the reviews to date. All good comments, I'll implement. Yes, the output of `-XShowSettings` is more verbose. Let me try and re-implement with a new user option. Perhaps, we could have some of the key security settings show up with the `-XShowSettings` option (static provider names (I should list them in preference order actually) and enabled TLS protocols ?) and then have some help output hinting about how to get verbose output ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1586880695 From erikj at openjdk.org Mon Jun 12 12:30:55 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 Jun 2023 12:30:55 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v5] In-Reply-To: References: Message-ID: On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - update > - update > - update > - update > - 8308286 Fix clang warnings in linux code Build changes look ok. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1587242876 From mullan at openjdk.org Mon Jun 12 12:59:42 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 12 Jun 2023 12:59:42 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Another possibility is to put this under a new option, ex `-XshowSecuritySettings`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1587290923 From xuelei at openjdk.org Mon Jun 12 16:52:29 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 12 Jun 2023 16:52:29 GMT Subject: RFR: 8309867: redundant class field RSAPadding.md Message-ID: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> Hi, May I get this simple update reviewed? The class field RSAPadding.md can be converted to a local variable of the constructor, and save the class footprint. Thanks, Xuelei ------------- Commit messages: - 8309867: redundant class field RSAPadding.md Changes: https://git.openjdk.org/jdk/pull/14422/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14422&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309867 Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14422.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14422/head:pull/14422 PR: https://git.openjdk.org/jdk/pull/14422 From mdonovan at openjdk.org Mon Jun 12 17:31:26 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 12 Jun 2023 17:31:26 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v2] In-Reply-To: References: Message-ID: > This PR implements a test to verify that Java will not negotiate TLS connections when one side of the connection requests disabled cipher suites. Matthew Donovan 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: - cleaned up code, combined individual executions - Merge branch 'master' into JDK-8301379 - 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14316/files - new: https://git.openjdk.org/jdk/pull/14316/files/353be172..6c90e31c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=00-01 Stats: 48850 lines in 672 files changed: 40711 ins; 6052 del; 2087 mod Patch: https://git.openjdk.org/jdk/pull/14316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14316/head:pull/14316 PR: https://git.openjdk.org/jdk/pull/14316 From mdonovan at openjdk.org Mon Jun 12 17:33:55 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 12 Jun 2023 17:33:55 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 17:23:00 GMT, Sean Mullan wrote: >> Matthew Donovan 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: >> >> - cleaned up code, combined individual executions >> - Merge branch 'master' into JDK-8301379 >> - 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated > > test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 119: > >> 117: public void run() throws IOException { >> 118: try { >> 119: socket.getOutputStream().write("SECRET MESSAGE".getBytes(StandardCharsets.UTF_8)); > > Should this fail if this handshake passes? I updated the code to throw an exception here. It's useful for logging but if the handshake is successful and data is transferred the server will report the error. > test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 121: > >> 119: socket.getOutputStream().write("SECRET MESSAGE".getBytes(StandardCharsets.UTF_8)); >> 120: } catch (SSLHandshakeException exc) { >> 121: // handshake failures are expected > > Can you inspect the handshake failure message to make sure it is failing for the right reason as you do for the server case? I added a check for the failure message. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1227017797 PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1227018124 From hchao at openjdk.org Mon Jun 12 17:56:43 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Mon, 12 Jun 2023 17:56:43 GMT Subject: RFR: 8309867: redundant class field RSAPadding.md In-Reply-To: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> References: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> Message-ID: On Mon, 12 Jun 2023 16:39:33 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I get this simple update reviewed? > > The class field RSAPadding.md can be converted to a local variable of the constructor, and save the class footprint. > > Thanks, > Xuelei Marked as reviewed by hchao (Committer). LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/14422#pullrequestreview-1475499571 PR Comment: https://git.openjdk.org/jdk/pull/14422#issuecomment-1587805406 From duke at openjdk.org Mon Jun 12 17:59:12 2023 From: duke at openjdk.org (duke) Date: Mon, 12 Jun 2023 17:59:12 GMT Subject: Withdrawn: 8295146: Clean up native code with newer C/C++ language features In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 06:20:41 GMT, Julian Waters wrote: > After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 > > No changes to the behaviour of the JDK has resulted in any way from this commit This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From weijun at openjdk.org Mon Jun 12 18:14:52 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 12 Jun 2023 18:14:52 GMT Subject: RFR: 8309867: redundant class field RSAPadding.md In-Reply-To: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> References: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> Message-ID: On Mon, 12 Jun 2023 16:39:33 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I get this simple update reviewed? > > The class field RSAPadding.md can be converted to a local variable of the constructor, and save the class footprint. > > Thanks, > Xuelei Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14422#pullrequestreview-1475531192 From mullan at openjdk.org Mon Jun 12 18:21:47 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 12 Jun 2023 18:21:47 GMT Subject: RFR: 8309867: redundant class field RSAPadding.md In-Reply-To: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> References: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> Message-ID: On Mon, 12 Jun 2023 16:39:33 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I get this simple update reviewed? > > The class field RSAPadding.md can be converted to a local variable of the constructor, and save the class footprint. > > Thanks, > Xuelei Looks good. I'd be more inclined to call this a Bug than an Enhancement. ------------- PR Review: https://git.openjdk.org/jdk/pull/14422#pullrequestreview-1475542021 From xuelei at openjdk.org Mon Jun 12 18:21:49 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 12 Jun 2023 18:21:49 GMT Subject: RFR: 8309867: redundant class field RSAPadding.md In-Reply-To: References: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> Message-ID: On Mon, 12 Jun 2023 17:53:42 GMT, Hai-May Chao wrote: >> Hi, >> >> May I get this simple update reviewed? >> >> The class field RSAPadding.md can be converted to a local variable of the constructor, and save the class footprint. >> >> Thanks, >> Xuelei > > LGTM Thank you @haimaychao and @wangweij! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14422#issuecomment-1587844728 From rhalade at openjdk.org Mon Jun 12 18:23:41 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Mon, 12 Jun 2023 18:23:41 GMT Subject: RFR: 8156889: ListKeychainStore.sh fails in some virtualized environments Message-ID: This fix converted shell test to java code. Following are the updates done to the original shell test logic: - Test is updated to be a manual test as it is rather difficult/impossible to have it run in virtualized environment where we can't update the security keychain search list to include created keychain. - Test is updated to save earlier keychain search order and restore when test ends. - Test is now using legacy encryption and MAC algorithms, refer macOS open radar FB8988319, as macOS security framework doesn't work with the latest algorithms. Algorithms were updated with JDK-8153005. ------------- Commit messages: - 8156889: ListKeychainStore.sh fails in some virtualized environments Changes: https://git.openjdk.org/jdk/pull/14424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8156889 Stats: 449 lines in 4 files changed: 202 ins; 247 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14424/head:pull/14424 PR: https://git.openjdk.org/jdk/pull/14424 From duke at openjdk.org Mon Jun 12 18:58:58 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 12 Jun 2023 18:58:58 GMT Subject: Withdrawn: 8307144: namedParams in XECParameters and EdDSAParameters can be private final In-Reply-To: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> References: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Message-ID: On Thu, 25 May 2023 21:17:40 GMT, Ben Perez wrote: > Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14162 From duke at openjdk.org Mon Jun 12 19:03:21 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 12 Jun 2023 19:03:21 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array Message-ID: Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. ------------- Commit messages: - updated copywrite - Fixed getEncoded for CRSAPublicKey - Fixed imports and formatting - Modify getEncoded to return copy of encoding. Added test. Changes: https://git.openjdk.org/jdk/pull/14425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308808 Stats: 33 lines in 2 files changed: 30 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14425/head:pull/14425 PR: https://git.openjdk.org/jdk/pull/14425 From valeriep at openjdk.org Mon Jun 12 19:40:42 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 12 Jun 2023 19:40:42 GMT Subject: RFR: 8309867: redundant class field RSAPadding.md In-Reply-To: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> References: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> Message-ID: On Mon, 12 Jun 2023 16:39:33 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I get this simple update reviewed? > > The class field RSAPadding.md can be converted to a local variable of the constructor, and save the class footprint. > > Thanks, > Xuelei Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14422#pullrequestreview-1475679300 From duke at openjdk.org Mon Jun 12 19:48:01 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 12 Jun 2023 19:48:01 GMT Subject: Integrated: 8307144: namedParams in XECParameters and EdDSAParameters can be private final In-Reply-To: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> References: <0VdUbQFln4tZi8VHK3ZiO4P4n7CpJbqtwYe2ZCpUCJg=.4bfcfe92-f445-48ac-aece-f5cec3c2dac0@github.com> Message-ID: On Thu, 25 May 2023 21:17:40 GMT, Ben Perez wrote: > Changed `namedParams` in XECParameters and EdDSAParameters to be `private final` This pull request has now been integrated. Changeset: 3c15ad8d Author: Ben Perez Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/3c15ad8d47dad303192efba4ec524a7612377d51 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod 8307144: namedParams in XECParameters and EdDSAParameters can be private final Reviewed-by: jnimeh, xuelei, mullan ------------- PR: https://git.openjdk.org/jdk/pull/14162 From xuelei at openjdk.org Mon Jun 12 20:45:54 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 12 Jun 2023 20:45:54 GMT Subject: Integrated: 8309867: redundant class field RSAPadding.md In-Reply-To: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> References: <7mTeesy9N8-0CdKx6dSZffV1ymD4dhKboxJUjKlsUfc=.d3e8ff1f-8f5d-46c2-a044-7b10d4c05a86@github.com> Message-ID: On Mon, 12 Jun 2023 16:39:33 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I get this simple update reviewed? > > The class field RSAPadding.md can be converted to a local variable of the constructor, and save the class footprint. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: 80a8144a Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/80a8144af5aae104188de9cc182e6d59c1466732 Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod 8309867: redundant class field RSAPadding.md Reviewed-by: hchao, weijun, valeriep ------------- PR: https://git.openjdk.org/jdk/pull/14422 From jlu at openjdk.org Mon Jun 12 21:28:30 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jun 2023 21:28:30 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update Message-ID: Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) For example, image Please note that the HTML files only apply to .properties, and not .java resources. ------------- Commit messages: - Revert tool's un-translation of 'exception-type' for zh-CN - Move localized currencynames.properties to jdk.localedata - Apply trailing WS tool patch - Remove extra quotes in 'main.usage' values - Revert WinResources changing of 'resource.wxl-file-name' value - Revert MsiInstallerStrings culture value changes - Apply JDK21 Open translation patch Changes: https://git.openjdk.org/jdk21/pull/11/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309632 Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod Patch: https://git.openjdk.org/jdk21/pull/11.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11 PR: https://git.openjdk.org/jdk21/pull/11 From jlu at openjdk.org Mon Jun 12 21:28:30 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jun 2023 21:28:30 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <-g_p5DXIJa2iFx-wYX9Fl024cy_wOxNlIN3g8TB5V1E=.84d95609-9341-4a50-afa2-e9dcb462a0bb@github.com> On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. @naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences. ------------- PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588123540 From jlu at openjdk.org Mon Jun 12 21:29:54 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jun 2023 21:29:54 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you. ------------- PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588130775 From kcr at openjdk.org Mon Jun 12 21:45:55 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Jun 2023 21:45:55 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:27:05 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> image >> >> >> Please note that the HTML files only apply to .properties, and not .java resources. > > @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you. @justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21. See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html ------------- PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588146416 From jlu at openjdk.org Mon Jun 12 21:55:48 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jun 2023 21:55:48 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:42:24 GMT, Kevin Rushforth wrote: >> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you. > > @justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21. > > See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html @kevinrushforth Thanks for the reminder, will make the change in ML first. ------------- PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588156115 From jlu at openjdk.org Mon Jun 12 22:07:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jun 2023 22:07:11 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update Message-ID: Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) For example, image Please note that the HTML files only apply to .properties, and not .java resources. ------------- Commit messages: - Merge remote-tracking branch 'justinJDK21/JDK21-RDP1-L10nDrop' into JDK21-L10NDrop-RDP1 - Revert tool's un-translation of 'exception-type' for zh-CN - Move localized currencynames.properties to jdk.localedata - Apply trailing WS tool patch - Remove extra quotes in 'main.usage' values - Revert WinResources changing of 'resource.wxl-file-name' value - Revert MsiInstallerStrings culture value changes - Apply JDK21 Open translation patch Changes: https://git.openjdk.org/jdk/pull/14430/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309632 Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430 From jlu at openjdk.org Mon Jun 12 22:16:50 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jun 2023 22:16:50 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. @naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences. @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1588180092 From duke at openjdk.org Mon Jun 12 22:20:53 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 12 Jun 2023 22:20:53 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115: > 113: main.help.opt.main.validate=\ --validate Validiert den Inhalt des JAR-Archivs. Diese Option\n validiert, dass die von einem Multi-Release-JAR-Archiv\n exportierte API \u00FCber die verschiedenen Releaseversionen\n hinweg konsistent ist. > 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n -C DIR Zum angegebenen Verzeichnis wechseln und die folgende\n Datei aufnehmen > 115: main.help.opt.any.file=\ -f, --file=FILE Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n stdout verwendet, je nach Vorgang\n --release VERSION Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n der JAR-Datei (d.h. META-INF/versions/VERSION/) This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227296089 From jlu at openjdk.org Mon Jun 12 22:32:14 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jun 2023 22:32:14 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Revert 'main.help.opt.any.file' value for _de ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14430/files - new: https://git.openjdk.org/jdk/pull/14430/files/ee072231..8ee7bf88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430 From jlu at openjdk.org Mon Jun 12 22:32:34 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jun 2023 22:32:34 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 22:17:25 GMT, Eirik Bjorsnos wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115: > >> 113: main.help.opt.main.validate=\ --validate Validiert den Inhalt des JAR-Archivs. Diese Option\n validiert, dass die von einem Multi-Release-JAR-Archiv\n exportierte API \u00FCber die verschiedenen Releaseversionen\n hinweg konsistent ist. >> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n -C DIR Zum angegebenen Verzeichnis wechseln und die folgende\n Datei aufnehmen >> 115: main.help.opt.any.file=\ -f, --file=FILE Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n stdout verwendet, je nach Vorgang\n --release VERSION Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n der JAR-Datei (d.h. META-INF/versions/VERSION/) > > This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German.. Thanks for catching that. The translation tool incorrectly translated this, and we had manually fixed it with `Auslassen` in the last translation drop. This was an instance of the tool simply overwriting it this time. Will file a bug against the translation tool regarding this, to prevent it in future translation drops. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227305807 From mdonovan at openjdk.org Tue Jun 13 11:17:23 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 13 Jun 2023 11:17:23 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v3] In-Reply-To: References: Message-ID: > This PR implements a test to verify that Java will not negotiate TLS connections when one side of the connection requests disabled cipher suites. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: added all disabled ciphers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14316/files - new: https://git.openjdk.org/jdk/pull/14316/files/6c90e31c..64e32b89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=01-02 Stats: 58 lines in 1 file changed: 46 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/14316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14316/head:pull/14316 PR: https://git.openjdk.org/jdk/pull/14316 From mdonovan at openjdk.org Tue Jun 13 11:17:27 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 13 Jun 2023 11:17:27 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 17:25:52 GMT, Sean Mullan wrote: >> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: >> >> added all disabled ciphers > > test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 35: > >> 33: * @test id=Server >> 34: * @bug 8301379 >> 35: * @summary Verify that Java will not negotiate disabled cipher suites when the > > This test could be enhanced to test all of the other suites that are disabled. I think that might be a good idea, to centralize that. Although you could do it as a follow-on RFE. I added all of the disable ciphers that are listed in DisabledAlgorithms. Let me know if this isn't what you were thinking. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1227950487 From aturbanov at openjdk.org Tue Jun 13 13:24:50 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 13 Jun 2023 13:24:50 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration src/java.base/share/classes/sun/launcher/LauncherHelper.java line 330: > 328: if (arg.toLowerCase(Locale.ROOT).equals("properties")) { > 329: printSecurityProperties(); > 330: } else if(arg.toLowerCase(Locale.ROOT).equals("providers")) { Suggestion: } else if (arg.toLowerCase(Locale.ROOT).equals("providers")) { src/java.base/share/classes/sun/launcher/LauncherHelper.java line 332: > 330: } else if(arg.toLowerCase(Locale.ROOT).equals("providers")) { > 331: printSecurityProviderConfig(); > 332: } else if(arg.toLowerCase(Locale.ROOT).equals("tls")) { Suggestion: } else if (arg.toLowerCase(Locale.ROOT).equals("tls")) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228125148 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228125325 From coffeys at openjdk.org Tue Jun 13 13:57:13 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 13 Jun 2023 13:57:13 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v2] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey 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 six additional commits since the last revision: - Merge branch 'master' into 8281658-showsettings-security - Incorporate feedback to date - minor edits, copyright, descriptions etc - Merge branch 'master' into 8281658-showsettings-security - Merge branch 'master' into 8281658-showsettings-security - 8281658 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/a54a0921..c60a4ed4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=00-01 Stats: 51921 lines in 852 files changed: 41802 ins; 7035 del; 3084 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From coffeys at openjdk.org Tue Jun 13 13:57:59 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 13 Jun 2023 13:57:59 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Thanks for the feedback to date. I've pushed new changes to reflect requested changes. I've changed the default` -XshowSettings `behaviour to only print some highlights of security settings and to also hint at how verbose security settings are shown. I think that works. I looked at widening use of the `wrappedString `utility method Roger but there were subtle differences with how security properties arguments are wrapped. Not sure if it warrants the extra complexity. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1589369063 From aturbanov at openjdk.org Tue Jun 13 14:02:57 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 13 Jun 2023 14:02:57 GMT Subject: RFR: 8309305: sun/security/ssl/SSLSocketImpl/BlockedAsyncClose.java fails with jtreg test timeout In-Reply-To: References: Message-ID: <-_iOgUpQEXlV0-cqnXZzyANYigujR6P6acmvf6cTLVg=.5a406b3c-09f8-4180-9a81-10008fe16430@github.com> On Thu, 8 Jun 2023 14:25:26 GMT, Matthew Donovan wrote: > This PR improves the reliability of the BlockedAsyncClose test by addressing an edge case/race condition between the two test threads. The purpose of the test is to verify that an SSLSocket can be closed if a thread is blocked in a write operation. > > The test starts a "write" thread that writes data to a socket until the output buffer was filled, causing the write operation to block. The main thread then calls `SSLSocket.close()`. The original code used `Thread.sleep(1000)` to wait for the write-thread to block. However, 1 second isn't always long enough and if the write-thread isn't blocked and the output buffer is full (or almost full), the `socket.close()` call may block when it tries to send the close_notify alert. This is the condition that caused this bug. > > My change uses a Lock to determine if the write thread is blocked. In the write thread, the lock creates a critical section around the `write()` call. The main thread uses `tryLock()` with a timeout to determine that the write() call is taking too long and thus likely blocked. > > While there, I also updated the test to use the SSLContextTemplate class. test/jdk/sun/security/ssl/SSLSocketImpl/BlockedAsyncClose.java line 90: > 88: // if the writeLock is not released by the other thread within 10 > 89: // seconds it is probably blocked, and we can try to close the socket > 90: while(writeLock.tryLock(10, TimeUnit.SECONDS)) { Suggestion: while (writeLock.tryLock(10, TimeUnit.SECONDS)) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14378#discussion_r1228181139 From mdonovan at openjdk.org Tue Jun 13 14:24:20 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 13 Jun 2023 14:24:20 GMT Subject: RFR: 8309305: sun/security/ssl/SSLSocketImpl/BlockedAsyncClose.java fails with jtreg test timeout [v2] In-Reply-To: References: Message-ID: > This PR improves the reliability of the BlockedAsyncClose test by addressing an edge case/race condition between the two test threads. The purpose of the test is to verify that an SSLSocket can be closed if a thread is blocked in a write operation. > > The test starts a "write" thread that writes data to a socket until the output buffer was filled, causing the write operation to block. The main thread then calls `SSLSocket.close()`. The original code used `Thread.sleep(1000)` to wait for the write-thread to block. However, 1 second isn't always long enough and if the write-thread isn't blocked and the output buffer is full (or almost full), the `socket.close()` call may block when it tries to send the close_notify alert. This is the condition that caused this bug. > > My change uses a Lock to determine if the write thread is blocked. In the write thread, the lock creates a critical section around the `write()` call. The main thread uses `tryLock()` with a timeout to determine that the write() call is taking too long and thus likely blocked. > > While there, I also updated the test to use the SSLContextTemplate class. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: Fixed whitespace. Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14378/files - new: https://git.openjdk.org/jdk/pull/14378/files/b25620d4..3e3768d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14378&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14378&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14378/head:pull/14378 PR: https://git.openjdk.org/jdk/pull/14378 From rriggs at openjdk.org Tue Jun 13 14:57:57 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jun 2023 14:57:57 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v2] In-Reply-To: References: Message-ID: <-t0j8xoVmNzjqVi2SvBGoGUUl0cot5buTNMvDZO1zig=.2fbf648f-785a-4738-b5cb-d882f0eb2eaf@github.com> On Tue, 13 Jun 2023 13:57:13 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey 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 six additional commits since the last revision: > > - Merge branch 'master' into 8281658-showsettings-security > - Incorporate feedback to date > - minor edits, copyright, descriptions etc > - Merge branch 'master' into 8281658-showsettings-security > - Merge branch 'master' into 8281658-showsettings-security > - 8281658 src/java.base/share/classes/sun/launcher/LauncherHelper.java line 189: > 187: } else { > 188: printSecuritySettings("all"); > 189: } Perhaps a slight preference for: var opt = opts.length > 2 ? opts[2].trim() : "all"; printSecuritySettings(opt); src/java.base/share/classes/sun/launcher/LauncherHelper.java line 342: > 340: > 341: private static void printSecuritySettings(String arg) { > 342: switch (arg.toLowerCase(Locale.ROOT)) { Drop the conversion to lower case: none of the other categories allow "sloppy-case" inputs. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 422: > 420: ostream.println(TWOINDENT + "Provider name: " + p.getName()); > 421: if (verbose) { > 422: ostream.println(TWOINDENT + PROV_INFO_STRING + wrappedString(p.getInfo(), 80)); Wrapping the args at 80 might still produce line that is quite long. Perhaps wrap the string after it was concatenated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228227964 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228187867 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228270167 From duke at openjdk.org Tue Jun 13 16:38:03 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 13 Jun 2023 16:38:03 GMT Subject: Integrated: 8308474: DSA does not reset SecureRandom when initSign is called again In-Reply-To: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> References: <1xObwcOlJDRei8orzwK4XDAGFXSx1fA7TRanSpfay_M=.8b68416f-3e48-444c-b277-0483703cb514@github.com> Message-ID: On Thu, 1 Jun 2023 21:17:11 GMT, Ben Perez wrote: > Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to DSA tests This pull request has now been integrated. Changeset: bed9161c Author: Ben Perez Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/bed9161c815b5b4773f36eac7e8dadc1384c7fd1 Stats: 70 lines in 2 files changed: 69 ins; 0 del; 1 mod 8308474: DSA does not reset SecureRandom when initSign is called again Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/14273 From cslucas at openjdk.org Tue Jun 13 17:56:00 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 13 Jun 2023 17:56:00 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v17] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Fri, 9 Jun 2023 17:23:22 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: >> >> Rome minor refactorings. > > Overall, I like how this patch shapes. > > I need to go through share/opto changes (so far, I did only a shallow review of that part), but the rest looks good. I plan to submit functional and performance testing over the weekend. @iwanowww - May I ask how did the tests go? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1589775478 From naoto at openjdk.org Tue Jun 13 18:41:52 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 13 Jun 2023 18:41:52 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> image >> >> >> Please note that the HTML files only apply to .properties, and not .java resources. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Revert 'main.help.opt.any.file' value for _de Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways. src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63: > 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059 > 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E > 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059 The translation seems wrong. It means to *add* the selected file, which is not the same meaning as in English file src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140: > 138: > 139: # 0: type, 1: name > 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 505: > 503: > 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059 > 505: These translations are very cryptic. Cannot understand it at first hand. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959: > 957: > 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093 > 959: The translation of "well-formed" is incorrect. It is not ??? ------------- PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477795175 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228530280 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228521409 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228538758 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228529769 From jlu at openjdk.org Tue Jun 13 18:56:44 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 Jun 2023 18:56:44 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com> On Tue, 13 Jun 2023 18:13:12 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140: > >> 138: >> 139: # 0: type, 1: name >> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf > > Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file. I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let ask about this specific instance. > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959: > >> 957: >> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093 >> 959: > > The translation of "well-formed" is incorrect. It is not ??? For translations that are incorrect, I can file a bug against the tool. Such a fix would probably not happen soon, can you suggest an alternative for now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228567669 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228570665 From naoto at openjdk.org Tue Jun 13 20:24:46 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 13 Jun 2023 20:24:46 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> image >> >> >> Please note that the HTML files only apply to .properties, and not .java resources. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Revert 'main.help.opt.any.file' value for _de Left some suggestions. Should be looked at by translators later. src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63: > 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059 > 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E > 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059 Suggestion: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 502: > 500: compiler.warn.forward.ref=\u521D\u671F\u5316\u3055\u308C\u308B\u524D\u306E\u5909\u6570''{0}''\u3092\u53C2\u7167\u3057\u3088\u3046\u3068\u3057\u307E\u3057\u305F > 501: > 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059 Suggestion: compiler.warn.possible.this.escape=\u30b5\u30d6\u30af\u30e9\u30b9\u304c\u521d\u671f\u5316\u3055\u308c\u308b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306e\u53ef\u80fd\u6027\u304c\u3042\u308a\u307e\u3059 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 504: > 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059 > 503: > 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059 Suggestion: compiler.warn.possible.this.escape.location=\u4e8b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306f\u3053\u306e\u547c\u3073\u51fa\u3057\u3067\u51fa\u73fe\u3057\u307e\u3059 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 956: > 954: compiler.err.unclosed.text.block=\u9589\u3058\u3089\u308C\u3066\u3044\u306A\u3044\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF > 955: > 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093 Suggestion: compiler.err.string.template.is.not.well.formed=\u6587\u5b57\u5217\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 958: > 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093 > 957: > 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093 Suggestion: compiler.err.text.block.template.is.not.well.formed=\u30c6\u30ad\u30b9\u30c8\u30fb\u30d6\u30ed\u30c3\u30af\u30fb\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093 ------------- Changes requested by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477963618 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228635514 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228648714 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228651272 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228653057 PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228654384 From weijun at openjdk.org Tue Jun 13 20:58:51 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 13 Jun 2023 20:58:51 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> image >> >> >> Please note that the HTML files only apply to .properties, and not .java resources. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Revert 'main.help.opt.any.file' value for _de Some comments: - `src/java.base/share/classes/sun/launcher/resources/launcher` `? private`. "private" should be translated, just like the "static" in the 2nd box. - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler` `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"? `compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated. `compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced". - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`: `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file. - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap` I don't think the new translation is better than the old one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590013825 From jlu at openjdk.org Tue Jun 13 21:06:25 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 Jun 2023 21:06:25 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v3] In-Reply-To: References: Message-ID: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Review: use Naoto's recommended ja values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14430/files - new: https://git.openjdk.org/jdk/pull/14430/files/8ee7bf88..7801eefb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430 From jlu at openjdk.org Tue Jun 13 21:06:28 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 Jun 2023 21:06:28 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 19:59:28 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63: > >> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059 >> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E >> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059 > > Suggestion: > > FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059 Thank you Naoto, all your recommended translations have been updated. The HTML diffs have also been updated as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228692234 From jlu at openjdk.org Tue Jun 13 22:09:40 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 Jun 2023 22:09:40 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4] In-Reply-To: References: Message-ID: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. Justin Lu has updated the pull request incrementally with three additional commits since the last revision: - Review: correct previous commit, remove ? as well - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN - Review: Use old 'err.crash' zh_CN value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14430/files - new: https://git.openjdk.org/jdk/pull/14430/files/7801eefb..f7c06512 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430 PR: https://git.openjdk.org/jdk/pull/14430 From jlu at openjdk.org Tue Jun 13 22:09:43 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 Jun 2023 22:09:43 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 20:56:31 GMT, Weijun Wang wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert 'main.help.opt.any.file' value for _de > > Some comments: > > - `src/java.base/share/classes/sun/launcher/resources/launcher` > > `? private`. "private" should be translated, just like the "static" in the 2nd box. > > - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler` > > `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"? > > `compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated. > > `compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced". > > > - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`: > > `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file. > > - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap` > > I don't think the new translation is better than the old one. Thank you for the review @wangweij, I have addressed these recommendations > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`: > > > `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file. > > * `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap` > > > I don't think the new translation is better than the old one. For the other comments, I will bring them to the language specialist for updated translations. Ideally we can get those in for this translation drop, but if not, they can go in during the second translation drop during RDP2. I am also hesitant to make too many manual changes, as they will just get overwritten by the tool in the future, so it's best to get it fixed in the tool first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590087839 From naoto at openjdk.org Wed Jun 14 00:09:03 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 Jun 2023 00:09:03 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4] In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 22:09:40 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> image >> >> >> Please note that the HTML files only apply to .properties, and not .java resources. > > Justin Lu has updated the pull request incrementally with three additional commits since the last revision: > > - Review: correct previous commit, remove ? as well > - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN > - Review: Use old 'err.crash' zh_CN value Looks good, Justin ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1478236336 From dholmes at openjdk.org Wed Jun 14 05:22:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jun 2023 05:22:19 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 Message-ID: Updated the version to 22-ea and year to 2024. The following unpublished changes will also be included in this update: - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option The following changes were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor Thanks. ------------- Commit messages: - 8304478: Initial nroff manpage generation for JDK 22 Changes: https://git.openjdk.org/jdk/pull/14462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304478 Stats: 140 lines in 28 files changed: 1 ins; 105 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/14462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462 PR: https://git.openjdk.org/jdk/pull/14462 From alanb at openjdk.org Wed Jun 14 06:11:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jun 2023 06:11:55 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. Looks fine. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478549017 From dholmes at openjdk.org Wed Jun 14 06:11:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jun 2023 06:11:55 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 06:08:59 GMT, Alan Bateman wrote: >> Updated the version to 22-ea and year to 2024. >> >> The following unpublished changes will also be included in this update: >> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character >> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) >> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option >> >> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: >> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code >> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor >> >> Thanks. > > Looks fine. Thanks @AlanBateman ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1590531861 From sspitsyn at openjdk.org Wed Jun 14 09:28:11 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jun 2023 09:28:11 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. The Serviceability changes look good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478940868 From coffeys at openjdk.org Wed Jun 14 11:39:14 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 14 Jun 2023 11:39:14 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Incorporate review comments from Roger and tweak some code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/c60a4ed4..55a85e38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=01-02 Stats: 14 lines in 1 file changed: 0 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From coffeys at openjdk.org Wed Jun 14 11:39:17 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 14 Jun 2023 11:39:17 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v2] In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 13:57:13 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey 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 six additional commits since the last revision: > > - Merge branch 'master' into 8281658-showsettings-security > - Incorporate feedback to date > - minor edits, copyright, descriptions etc > - Merge branch 'master' into 8281658-showsettings-security > - Merge branch 'master' into 8281658-showsettings-security > - 8281658 Thanks for the comments Roger. Changes pushed. Some other minor issues corrected also while passing through code. ------------- PR Review: https://git.openjdk.org/jdk/pull/14394#pullrequestreview-1479167051 From coffeys at openjdk.org Wed Jun 14 11:39:23 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 14 Jun 2023 11:39:23 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v2] In-Reply-To: <-t0j8xoVmNzjqVi2SvBGoGUUl0cot5buTNMvDZO1zig=.2fbf648f-785a-4738-b5cb-d882f0eb2eaf@github.com> References: <-t0j8xoVmNzjqVi2SvBGoGUUl0cot5buTNMvDZO1zig=.2fbf648f-785a-4738-b5cb-d882f0eb2eaf@github.com> Message-ID: On Tue, 13 Jun 2023 14:30:57 GMT, Roger Riggs wrote: >> Sean Coffey 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 six additional commits since the last revision: >> >> - Merge branch 'master' into 8281658-showsettings-security >> - Incorporate feedback to date >> - minor edits, copyright, descriptions etc >> - Merge branch 'master' into 8281658-showsettings-security >> - Merge branch 'master' into 8281658-showsettings-security >> - 8281658 > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 189: > >> 187: } else { >> 188: printSecuritySettings("all"); >> 189: } > > Perhaps a slight preference for: > > var opt = opts.length > 2 ? opts[2].trim() : "all"; > printSecuritySettings(opt); fair point. done > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 422: > >> 420: ostream.println(TWOINDENT + "Provider name: " + p.getName()); >> 421: if (verbose) { >> 422: ostream.println(TWOINDENT + PROV_INFO_STRING + wrappedString(p.getInfo(), 80)); > > Wrapping the args at 80 might still produce line that is quite long. > Perhaps wrap the string after it was concatenated. logic updated. I think that's what you were hinting at Roger. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229446518 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229447236 From weijun at openjdk.org Wed Jun 14 11:51:00 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 Jun 2023 11:51:00 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Roger and tweak some code src/java.base/share/classes/sun/launcher/LauncherHelper.java line 378: > 376: ostream.println(TWOINDENT + key + "="); > 377: List.of(val.split(",")).forEach( > 378: s -> ostream.println(THREEINDENT + s.trim() + ",")); Will this print a comma for the last line? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229466419 From weijun at openjdk.org Wed Jun 14 11:54:59 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 Jun 2023 11:54:59 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Roger and tweak some code src/java.base/share/classes/sun/launcher/LauncherHelper.java line 424: > 422: if (!services.isEmpty()) { > 423: services.stream() > 424: .sorted(Comparator.comparing(Provider.Service::getType)) How about sorting by algorithm within the same type? Another suggestion: adding aliases to output, for example: `Signature: Ed25519 (1.3.101.112, OID.1.3.101.112)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229473561 From weijun at openjdk.org Wed Jun 14 12:49:09 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 Jun 2023 12:49:09 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Roger and tweak some code src/java.base/share/classes/sun/launcher/LauncherHelper.java line 357: > 355: private static void printSecuritySummarySettings() { > 356: ostream.println("Security settings summary: " + "\n" + > 357: INDENT + "Use \"-XshowSettings:security\" for verbose details\n"); Is it helpful to list sub-options here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229560168 From mullan at openjdk.org Wed Jun 14 13:45:59 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 14 Jun 2023 13:45:59 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v3] In-Reply-To: References: Message-ID: <8gn13OHKYr7lLycHTTjR71BiZdMMdP1ansKW63LdmR4=.9a9cb302-04de-4257-99df-46f9f7e09eac@github.com> On Tue, 13 Jun 2023 11:11:32 GMT, Matthew Donovan wrote: >> test/jdk/javax/net/ssl/TLS/TLSWontNegotiateDisabledCipherAlgos.java line 35: >> >>> 33: * @test id=Server >>> 34: * @bug 8301379 >>> 35: * @summary Verify that Java will not negotiate disabled cipher suites when the >> >> This test could be enhanced to test all of the other suites that are disabled. I think that might be a good idea, to centralize that. Although you could do it as a follow-on RFE. > > I added all of the disable ciphers that are listed in DisabledAlgorithms. Let me know if this isn't what you were thinking. Thanks! Yes, this is what I was thinking. There is another test `test/jdk/javax/net/ssl/ciphersuites/DisabledAlgorithms.java` that is very similar to this test. Can you compare these two tests and consider removing that test, or combining them if there are other things that test is testing that this one isn't? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1229645413 From mullan at openjdk.org Wed Jun 14 14:10:05 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 14 Jun 2023 14:10:05 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 11:52:35 GMT, Weijun Wang wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporate review comments from Roger and tweak some code > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 424: > >> 422: if (!services.isEmpty()) { >> 423: services.stream() >> 424: .sorted(Comparator.comparing(Provider.Service::getType)) > > How about sorting by algorithm within the same type? > > Another suggestion: adding aliases to output, for example: `Signature: Ed25519 (1.3.101.112, OID.1.3.101.112)`. +1 to sorting by algorithm name within same type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229680104 From jlu at openjdk.org Wed Jun 14 16:25:00 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 14 Jun 2023 16:25:00 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com> References: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com> Message-ID: On Tue, 13 Jun 2023 18:50:42 GMT, Justin Lu wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140: >> >>> 138: >>> 139: # 0: type, 1: name >>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf >> >> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file. > > I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let me ask about this specific instance. The language specialist confirmed the double quotes are locale specific for de. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1229881212 From sean.mullan at oracle.com Wed Jun 14 16:40:20 2023 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 14 Jun 2023 12:40:20 -0400 Subject: RFD: Services lockdown for security providers In-Reply-To: References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com> Message-ID: <4b159d35-ee2e-952d-8e22-c035e5ed17ea@oracle.com> This proposal looks pretty good, although I think I would like to see more examples and a prototype if you have it. I think this would work well in conjunction with Sean Coffey's enhancement to add a security category to the java -XshowSettings option [1]. This would help debug issues with the syntax. The provider suboption could be enhanced (perhaps by default, perhaps with an additional suboption) to show the services that are disabled, ex, with the property set to jdk.security.providers.filter=!*.MessageDigest.MD5; !*.MessageDigest.MD2; *: it would show something like: Provider name: SUN Provider information: ... Provider services: (type : algorithm) ... MessageDigest : MD2 (disabled) MessageDigest : MD5 (disabled) ... I would even add that as a debugging tip in the documenting of the syntax. --Sean [1] https://github.com/openjdk/jdk/pull/14394 On 5/24/23 5:03 PM, Martin Balao wrote: > Hi, > > Thanks Anthony for your feedback. > > We've been exploring the syntax and semantics for this new property > further, with the goal of making it more consistent and simple while > retaining expressiveness power. We understand the importance of clarity > to minimize the risk of security providers, service types or algorithms > being unexpectedly enabled. > > In this new iteration of the proposal, we explore a filter that has > similarities to the serialization filter (jdk.serialFilter). We think > that it could be beneficial to leverage on a specification to which the > user is familiar already. > > > General structure > ==================== > > jdk.security.providers.filter=pattern-1; pattern-2; ...; pattern-n > > The property jdk.security.providers.filter is an overrideable Security > property. Thus, a System property with the same name exists and, when > specified, overrides any value in its Security counterpart. When not > specified (value is null), filtering capabilities are completely > disabled: all installed security providers, service types and algorithms > are allowed. If any of these properties are set during run time, the > filter could be initialized already and the new value may not take effect. > > When filtering capabilities are enabled, each service is checked against > the filter before registration. Notice that this affects both the > initial list of security providers as well as those dynamically > installed during run time. Once a service is registered, instances of it > can be obtained and used without any other checks that could affect > performance. > > The registration of a service involves a combination of a security > provider, service type and algorithm. Each combination is evaluated > against the filter patterns, from left to right. When a pattern matches > ?or, in other words, the rule concerns the service to be registered?, a > decision is made: the service will be allowed or denied. When a decision > is made, remaining patterns are not checked for the service under > consideration. When all patterns are checked and a decision is not made, > the default behavior is to deny the service registration. > > Contrary to the serialization filter, white spaces between patterns do > not have any significance. > > > Pattern matching > ===================================================== > > pattern := ! security-provider.service-type.algorithm > > pattern := security-provider.service-type.algorithm > > A canonical pattern consists of 3 hierarchical levels separated by ".". > From left to right in lexicographic order, these levels denote a > security provider, a service type and an algorithm. If a pattern starts > with "!", the decision made upon matching is to deny the service > registration. Otherwise, the service registration is allowed. White > spaces between "!" and the rest of the pattern do not have any significance. > > For a match to be successful, the security provider name, the service > type and the algorithm have to match the pattern exactly (case > insensitive). If the service type of a security provider interprets the > algorithm as a transformation composed of different parts, the full > transformation has to be specified in the pattern: the filter takes a > conservative approach and does not make any assumptions of what an > algorithm name means. For example, "AES" as the algorithm of a canonical > filter pattern will not match an "AES/ECB/PKCS5Padding" transformation. > > If an algorithm alias is specified in the filter pattern, a service > registering the alias will be matched. > > For convenience, it's possible to specify patterns in non-canonical forms: > > 1) At any level, the security provider, the service type or the > algorithm name can contain wildcards ("*") to represent zero or more > repetitions of any character; > > 2) The .algorithm part can be omitted to imply all algorithms under the > security provider and service type; > > 3) The .service-type.algorithm part can be omitted to imply all service > types and algorithms under the security provider; and, > > 4) The non-canonical form #1 can be combined with either #2 or #3. > > > Security provider, service type and algorithm names escaping > ================================================================= > > If the security provider, service type or algorithm name contains any of > the characters "\", ".", ";" or "*", they have to be escaped by > prepending the character "\". If the character "\" is found not escaping > a character, it's silently discarded. > > White spaces are discarded at the beginning and end of names. > > It's worth mentioning that the described escaping rules apply to the > jdk.security.providers.filter property value as read in > java.lang.System::getProperty or java.security.Security::getProperty. > Additional escaping might be needed depending on how the property is > passed. For example, Security properties require "\" characters to be > escaped. Thus, to match a provider name whose name is "\.", a filter > would require the "jdk.security.providers.filter=\\\\\\." entry in the > java.security file. See more about this in java.util.Properties::load [1]. > > > Examples (correct) > ==================== > > -- > > Enable all security providers, service types and algorithms: > > jdk.security.providers.filter= > > or > > jdk.security.providers.filter=* > > or > > jdk.security.providers.filter=*.* > > or > > jdk.security.providers.filter=*.*.* > > -- > > Enable everything except for the MD5 algorithm in MessageDigest services > when implemented by the SUN security provider: > > jdk.security.providers.filter=!SUN.MessageDigest.MD5; * > > -- > > Enable everything except for the MD5 algorithm in MessageDigest > services, irrespective of the security provider: > > jdk.security.providers.filter=!*.MessageDigest.MD5; * > > -- > > Enable everything except for algorithms using MD5, irrespective of the > security provider and the service type: > > jdk.security.providers.filter=!*.*.*MD5*; * > > Notice that in this case there are wildcards at the beginning and end of > the algorithm name. The reason is to match MD5 uses in algorithms such > as HmacMD5, MD5withRSA, PBEWithMD5AndDES, etc. > > -- > > Enable everything except for the RC4 algorithm in Cipher services when > implemented by the SunJCE security provider: > > jdk.security.providers.filter=!SunJCE.Cipher.ARCFOUR; * > > or > > jdk.security.providers.filter=!SunJCE.Cipher.RC4; * > > or > > jdk.security.providers.filter=!SunJCE.Cipher.1\.2\.840\.113549\.3\.4; * > > -- > > Enable the SUN security provider only, with all its service types and > algorithms. Other security providers must be disabled. > > jdk.security.providers.filter=SUN > > -- > > Enable the SUN security provider only, with all its service types and > algorithms except for MessageDigest. Other security providers must be > disabled. > > jdk.security.providers.filter=!SUN.MessageDigest; SUN > > -- > > > Examples (mistakes) > ==================== > > -- > > Enable everything except for the MD5 algorithm, irrespective of the > security provider and the service type: > > jdk.security.providers.filter=*; !*.*.MD5 > > This is wrong because the pattern "*" is matched first and a decision > allowing MD5 will be made immediately after. The pattern "!*.*.MD5" will > never be checked. > > -- > > Enable all SUN service types except for MessageDigest. Disable other > security providers. > > jdk.security.providers.filter=!SUN.MessageDigest > > While non-SUN security providers are effectively disabled, this is wrong > because SUN services other than MessageDigest will not match any pattern > and, by default, the decision is to deny registration. > > -- > > Enable the SunPKCS11 security provider only. > > jdk.security.providers.filter=SunPKCS11 > > This is wrong because the SunPKCS11 provider has to be identified by its > name instead of its class. A possible name would have the form of > SunPKCS11-NAME. In a filter, this can be matched either by > "SunPKCS11-NAME" or "SunPKCS11-*". > > -- > > > Look forward to your thoughts. > > Thanks.- > > > -- > [1] - > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Properties.html#load%28java.io.Reader%29 > > (?) - Thanks to Francisco Ferrari (@fferrari) for his contributions to > this proposal. > > > > > On 2/24/23 14:49, Anthony Scarpino wrote: >> Hi Martin, >> >> Interesting proposal.? I think Alternative 1 is a better direction to >> explore from a code structure standpoint.? If I remember correctly, >> Preferred Provider is accessed when getting a service or instance of the >> algorithm.? That happens on a per-operation basis.? What you describe is >> something that would reshape contents of the ProviderList where >> algorithms or services would not be in the list at all.? That is were I >> think #2 gets too complex in trying to handle both in the same property. >> ?#2 may end up putting all checks in a per-operation check, hindering >> performance every time as the list grows. >> >> I agree this is mostly used in the FIPS situation or where someone wants >> to disable an algorithm completely, say MD5.? In those cases it's best >> to just prevent the algorithm from ever being available. >> >> On the smaller details side that you list.? I think the name ".enabled" >> doesn't fit, particularly as the first thing in the example disables all >> Ciphers :).? I don't have any suggestions at this time. >> >> As far as the syntax.? I think it maybe a bit difficult to parse in code >> and mental to disable all Ciphers, then enable just for SunJCE and SUN. >> The SUN '*" confused me until I realized you were enabling Ciphers. >> Seems too easy to get wrong.? I know you weren't making a formal spec, >> but we have to start somewhere. >> >> thanks >> >> Tony >> >> >> On 2/17/23 10:52 AM, Martin Balao wrote: >>> Hi, >>> >>> We would like to discuss a limitation in the current configuration >>> capabilities for security providers and possible solutions that we are >>> exploring (?). >>> >>> As you know, current configuration capabilities in java.security allow >>> users to install security providers, decide their priority in a list >>> (security.provider. properties) and even circumvent this priority >>> for specific algorithms (jdk.security.provider.preferred property). >>> However, there is no granularity in terms of what service types and >>> algorithms are enabled once a security provider is installed: it's an >>> all or nothing scheme. It is worth noting that security providers can >>> bring with them a diverse range of service types. As an example, the >>> SUN security provider comes with the following service types: >>> SecureRandom, Signature, KeyPairGenerator, >>> AlgorithmParameterGenerator, AlgorithmParameters, KeyFactory, >>> MessageDigest, CertificateFactory, KeyStore, CertStore, Policy, >>> Configuration, CertPathBuilder and CertPathValidator [1]. >>> >>> In some cases, the user may need to enforce that all cryptographic >>> primitives come from a specific security provider. This could happen, >>> for example, when operating in a FIPS-compliant environment or under >>> strict security policies. To better illustrate, let's say that the >>> user requires that all cryptographic operations are performed in a >>> Hardware Security Module (HSM). On the OpenJDK side, this means that >>> the implementation for Cipher, Signature, Mac and other cryptographic >>> services must be the one in the SunPKCS11 security provider. Let's >>> also suppose that other non-cryptographic services such as those for >>> certificates validation and TLS are required, and their implementation >>> is in the SUN and SunJSSE security providers respectively. Setting >>> SunPKCS11 at the highest priority of the list is not a strong >>> guarantee to ensure that all cryptographic operations come from it: >>> it's possible that an algorithm for Signature is not implemented in >>> SunPKCS11 or in its underlying token but in the SUN security provider. >>> Disabling the SUN security provider wouldn't be an option in this case >>> because we need its certificates validation service. >>> >>> This problem goes beyond OpenJDK default security providers. Even if >>> we come up with a new layout for service types, algorithms and >>> providers ?putting backward compatibility issues aside?, there is >>> always the possibility that a 3rd party security provider does not >>> follow any services grouping convention. It might also be the case >>> that we need to disable a specific algorithm only ?i.e. for >>> cryptographic policy reasons? and TLS or JAR signing properties fall >>> short. >>> >>> In our view, it would be beneficial to add more configuration >>> flexibility and control to the existing API in which any security >>> provider can be plugged in, in the form of deciding which service >>> types and algorithms are enabled for each installed provider. >>> >>> There are 2 alternatives that we are exploring to tackle this problem. >>> >>> Alternative #1 >>> =========================== >>> >>> Introduce a new security property to decide which service types and >>> algorithms are enabled for each security provider. The default value >>> for this property would be empty, which keeps this feature disabled >>> and all services from installed security providers available. >>> >>> As for the new property's syntax and semantics, we've been considering >>> an allow-list along the lines of: >>> >>> jdk.security.provider.enabled = security-provider-1 { service-type-1 : >>> alg-1, ... ; ... } , ... >>> >>> Note: we need a formal syntax specification, this is for illustration >>> only. >>> >>> As part of the syntax we are considering the use of wildcards (*) to >>> match multiple security providers, service types and algorithms, and >>> minus signs (-) to remove service types. When a service type is >>> removed, the action applies to all algorithms and any attempt to >>> specify them explicitly would be an error. The minus sign cannot be >>> used at the algorithm level. We are also thinking that in case of a >>> partial or total contradiction between conditions, the right-most >>> value applies on top of the others. If a security provider, service >>> type or algorithm does not exist, we can simply write a debug warning >>> and ignore it. As for the name of the algorithms, we can also include >>> Ciphers transformations. >>> >>> Example: >>> >>> jdk.security.provider.enabled = * { -Cipher }, SunJCE { Cipher : >>> AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature } >>> >>> This would be interpreted as: >>> >>> ??* Irrespective of the provider (*), Cipher services should be >>> removed (-). This rule would be superfluous in this case because the >>> property itself is an allow-list and there is nothing to the left that >>> enables Cipher service types for any provider. >>> ??* From the SunJCE security provider, Cipher services with >>> AES/GCM/NoPadding and DES transformations are allowed, and Signature >>> services with any algorithm are allowed. Notice that there is a >>> shortcut here: the algorithm list that follows the service name, "': >>> alg-1, ..." is optional. When omitted all the service's algorithms are >>> enabled. >>> ??* From the SUN security provider, every service type is allowed >>> except Signature (recall that a minus sign can only apply to a >>> service, removing all associated algorithms). >>> >>> It's not the goal of this proposal to invalidate property values that >>> lead to inconsistent internal states, such as "the Cipher service of >>> SunJCE depends on AlgorithmParameters from SUN". This is because the >>> combinations for a check are virtually infinite: there can be 3rd >>> party security providers with their own semantics and dependencies. In >>> the same way, we cannot determine at start time any application >>> dependencies. It's up to the user to analyze all types of dependencies >>> before setting a value. >>> >>> >>> Alternative #2 >>> =========================== >>> >>> Introduce a boolean security property to turn the value of the >>> existing jdk.security.provider.preferred property into the only >>> combinations of algorithm, service and provider that are allowed: >>> >>> jdk.security.provider.preferredOnly = true >>> >>> The default value for the new property would be "false", keeping the >>> current "preferred" behavior in which all algorithms and services from >>> installed security providers are available. >>> >>> Contrary to Alternative #1, the user has to explicitly list the >>> algorithms and cannot rely on wildcards to express wide categories >>> such as "all Cipher algorithms from SunJCE" or "all algorithms from >>> SunJCE". The use of minus signs to remove service types or algorithms >>> wouldn't be available either. >>> >>> In order to mitigate the burden on users we can consider extending >>> jdk.security.provider.preferred syntax as long as we keep >>> backward-compatibility and stay within the boundaries of a "preferred" >>> semantics. For example, we can accept a value of >>> "jdk.security.provider.preferred=SunJCE" to mean that any service and >>> any algorithm from SunJCE is either preferred or allowed, depending on >>> the value of jdk.security.provider.preferredOnly. This case would be a >>> service type and algorithm wildcard. We can also define an >>> algorithms-only wildcard, such as Cipher.*:SunJCE. >>> >>> Alternative #2 has the advantage of reusing most or all of the >>> existing syntax. However, it's worth noticing that it implies an >>> overloaded semantic that can turn confusing or inconvenient in some >>> cases. As an example, a user that relies on the prioritized security >>> providers list for most of the algorithms and has only a few preferred >>> exceptions, would need to express preferences by extension upon >>> turning on this feature. Alternative #1 keeps preferences and >>> availability as two separate concepts, in a more clear way. >>> >>> >>> Thanks, >>> Martin.- >>> >>> -- >>> [1] - >>> https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D >>> (?) - Thanks to @fferrari for his contributions to this proposal. >>> >> > From mchung at openjdk.org Wed Jun 14 18:43:57 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 14 Jun 2023 18:43:57 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. Marked as reviewed by mchung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1480088199 From lancea at openjdk.org Wed Jun 14 18:51:10 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 14 Jun 2023 18:51:10 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1480097706 From acobbs at openjdk.org Wed Jun 14 19:23:59 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 14 Jun 2023 19:23:59 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > The following changes, to javac.1, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22 Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion? To be clear, I'm not blaming you for this situation - the problem is that there exist "closed sources" at all (why??) - but that doesn't seem like a good excuse for deleting work without a clear path to ensuring it is preserved (and the simplest way to do that is to do it yourself). Obviously I'd do it myself if I could. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1591849483 From cslucas at openjdk.org Wed Jun 14 19:29:45 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 14 Jun 2023 19:29:45 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'openjdk:master' into rematerialization-of-merges - Rome minor refactorings. - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges Catching up with master. - Address PR review 6: debug format output & some refactoring. - Catching up with master branch. Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address PR review 6: refactoring around rematerialization & improve test cases. - Address PR review 5: refactor on rematerialization & add tests. - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address part of PR review 4 & fix a bug setting only_candidate - Catching up with master Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - ... and 9 more: https://git.openjdk.org/jdk/compare/57b82512...939dcffe ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=17 Stats: 2732 lines in 26 files changed: 2484 ins; 108 del; 140 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From mullan at openjdk.org Wed Jun 14 20:30:59 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 14 Jun 2023 20:30:59 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array In-Reply-To: References: Message-ID: <1oZpv6oPQAqfSN85Y50hJedi5_slv2TZ3XFmPaUEh2c=.7f60249c-d1ff-4dbe-832b-35c1306d9aa1@github.com> On Mon, 12 Jun 2023 18:49:59 GMT, Ben Perez wrote: > Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java line 99: > 97: byte[] safeEncoding = new byte[encoding.length]; > 98: System.arraycopy(encoding, 0, safeEncoding, 0, encoding.length); > 99: return safeEncoding; You can replace these lines (and below) with `return encoding.clone();` which is more compact and the same AFAICT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14425#discussion_r1230130701 From duke at openjdk.org Wed Jun 14 20:38:18 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 14 Jun 2023 20:38:18 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v2] In-Reply-To: References: Message-ID: > Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Changed array copy to be more compact ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14425/files - new: https://git.openjdk.org/jdk/pull/14425/files/e7d4dd73..04b2a9d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14425/head:pull/14425 PR: https://git.openjdk.org/jdk/pull/14425 From duke at openjdk.org Wed Jun 14 20:52:57 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 14 Jun 2023 20:52:57 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v2] In-Reply-To: <1oZpv6oPQAqfSN85Y50hJedi5_slv2TZ3XFmPaUEh2c=.7f60249c-d1ff-4dbe-832b-35c1306d9aa1@github.com> References: <1oZpv6oPQAqfSN85Y50hJedi5_slv2TZ3XFmPaUEh2c=.7f60249c-d1ff-4dbe-832b-35c1306d9aa1@github.com> Message-ID: On Wed, 14 Jun 2023 20:28:15 GMT, Sean Mullan wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed array copy to be more compact > > src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java line 99: > >> 97: byte[] safeEncoding = new byte[encoding.length]; >> 98: System.arraycopy(encoding, 0, safeEncoding, 0, encoding.length); >> 99: return safeEncoding; > > You can replace these lines (and below) with `return encoding.clone();` which is more compact and the same AFAICT. Good call, just pushed those changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14425#discussion_r1230155017 From vlivanov at openjdk.org Wed Jun 14 20:54:16 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 14 Jun 2023 20:54:16 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Wed, 14 Jun 2023 19:29:45 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'openjdk:master' into rematerialization-of-merges > - Rome minor refactorings. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > Catching up with master. > - Address PR review 6: debug format output & some refactoring. > - Catching up with master branch. > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address PR review 6: refactoring around rematerialization & improve test cases. > - Address PR review 5: refactor on rematerialization & add tests. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address part of PR review 4 & fix a bug setting only_candidate > - Catching up with master > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - ... and 9 more: https://git.openjdk.org/jdk/compare/57b82512...939dcffe Overall, the testing went well. (It discovered some minor issues I commented about.) I'm rerunning some benchmarks which reported suspicious results. Will keep you posted. src/hotspot/share/opto/c2_globals.hpp line 473: > 471: " register allocation.") \ > 472: \ > 473: product(bool, ReduceAllocationMerges, true, \ I suggest to turn the flag into diagnostic one. There are much stricter requirements for product flags, so better to avoid introducing new ones. src/hotspot/share/opto/c2_globals.hpp line 476: > 474: "Try to simplify allocation merges before Scalar Replacement") \ > 475: \ > 476: develop(bool, TraceReduceAllocationMerges, false, \ The flag is debug-only while you use it in non-product code (`NOT_PRODUCT` macro). It doesn't break the build, but make the code under `NOT_PRODUCT` macro useless in optimized builds. You could either get rid of `NOT_PRODUCT` usages or turn the flag into `notproduct` one. src/hotspot/share/opto/c2compiler.cpp line 150: > 148: if (C.failure_reason_is(retry_no_reduce_allocation_merges())) { > 149: assert(do_reduce_allocation_merges, "must make progress"); > 150: do_reduce_allocation_merges = false; I consider the check here as a safety net which is intended to provide graceful degradation in performance if RAM optimization misbehaves for some reason. But bailing out an optimization is better than bailing out the whole compilation. I suggest to introduce new diagnostic flag (e.g., `VerifyReduceAllocationMerges`) and add a guarantee call here which signals whenever we encounter a problematic case. I'm fine with handling that as a separate enhancement (it makes sense to dump additional diagnostic info at the place where such bail outs are triggered ). test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/AllocationMergesTests.java line 43: > 41: public static void main(String[] args) { > 42: TestFramework.runWithFlags("-XX:+ReduceAllocationMerges", > 43: "-XX:+TraceReduceAllocationMerges", `TraceReduceAllocationMerges` and `DeoptimizeALot` are not available in product binaries, so the test fails there. You need to either limit the test to debug builds only or add `-XX:+IgnoreUnrecognizedVMOptions`. If `ReduceAllocationMerges` is turned into diagnostic flag, you need to specify `-XX:+UnlockDiagnosticVMOptions`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1591966055 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1230121828 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1230145481 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1230152798 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1230119032 From ascarpino at openjdk.org Wed Jun 14 21:27:00 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 Jun 2023 21:27:00 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Roger and tweak some code I would recommend using the service syntax that is similar to Preferred Provider and is also similar to a [services control](https://mail.openjdk.org/pipermail/security-dev/2023-May/035819.html) on the security mailing list that is not yet approved. `Signature.SHA1withRSA` instead of `Signature : SHA1withRSA` ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1592008732 From dholmes at openjdk.org Wed Jun 14 21:31:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jun 2023 21:31:00 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 19:21:01 GMT, Archie Cobbs wrote: > Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion? @archiecobbs we (Oracle) will take care of restoring this text so please don't be concerned about that. It will just be a temporary glitch. It should have been handled when the original PRs were done. It needs to be handled as a separate issue and PR though - whether that were to happen before or after this PR is somewhat immaterial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592014026 From dholmes at openjdk.org Wed Jun 14 21:31:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jun 2023 21:31:03 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 09:25:14 GMT, Serguei Spitsyn wrote: >> Updated the version to 22-ea and year to 2024. >> >> The following unpublished changes will also be included in this update: >> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character >> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) >> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option >> >> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: >> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code >> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor >> >> Thanks. > > The Serviceability changes look good. > Thanks, > Serguei Thanks for the additional reviews @sspitsyn , @LanceAndersen and @mlchung ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592014943 From acobbs at openjdk.org Wed Jun 14 21:40:57 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 14 Jun 2023 21:40:57 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 21:28:01 GMT, David Holmes wrote: > > Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion? > > @archiecobbs we (Oracle) will take care of restoring this text so please don't be concerned about that. It will just be a temporary glitch. OK thanks. Putting my trust in you :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592023452 From dholmes at openjdk.org Wed Jun 14 22:11:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Jun 2023 22:11:57 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. I've filed https://bugs.openjdk.org/browse/JDK-8310067 for the javac manpage fixup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592056009 From alanb at openjdk.org Thu Jun 15 06:31:59 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jun 2023 06:31:59 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Roger and tweak some code src/java.base/share/classes/sun/launcher/LauncherHelper.java line 183: > 181: case "locale": > 182: printLocale(); > 183: break; printLocale might need the same treatment to avoid printing the list of all locales by default. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1230497367 From alanb at openjdk.org Thu Jun 15 06:35:01 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jun 2023 06:35:01 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 06:29:09 GMT, Alan Bateman wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporate review comments from Roger and tweak some code > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 183: > >> 181: case "locale": >> 182: printLocale(); >> 183: break; > > printLocale might need the same treatment to avoid printing the list of all locales by default. Have you tried putting the new code into say sun.launcher.SecuritySettings to avoid adding so much security conf code into LauncherHelper? Maybe eventually this will need to a more pluggable as -XshowSettings has grown a bit beyond what it was originally for. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1230499915 From alanb at openjdk.org Thu Jun 15 07:30:59 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jun 2023 07:30:59 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Roger and tweak some code The output from -XshowSettings vs. the large dump from -XshowSettings:security look good, I think the default vs. all split is quite good. The format/style of the output is a bit different to the other sections in the -XshowSettings output. The other sections are more like name = value. What you have is okay, it just looks a bit different. There are a few blank lines in the the "Security settings summary" output that you might want to cull. Also "Use -XshowSettings:security for verbose details" might be better as "... for security details". Also what would you think about the earlier suggesting to do the same for the locale output? The dump of all available locales seems excessive to print out by default. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1592507948 From jpai at openjdk.org Thu Jun 15 08:42:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 15 Jun 2023 08:42:05 GMT Subject: RFR: 8310106: sun.security.ssl.SSLHandshake.getHandshakeProducer() incorrectly checks handshakeConsumers Message-ID: Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/JDK-8310106? The commit here fixes the typo in `sun.security.ssl.SSLHandshake.getHandshakeProducer()` method to correctly use `handshakeProducers`. I checked if a new jtreg test could be added for this, but given where this change resides and the nature of this change, I don't see a way to add one. Existing tests in `tier1`, `tier2` and `tier3` continue to pass with this change. ------------- Commit messages: - 8310106: sun.security.ssl.SSLHandshake.getHandshakeProducer() incorrectly checks handshakeConsumers Changes: https://git.openjdk.org/jdk/pull/14483/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14483&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310106 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14483/head:pull/14483 PR: https://git.openjdk.org/jdk/pull/14483 From mdonovan at openjdk.org Thu Jun 15 12:35:38 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 15 Jun 2023 12:35:38 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v4] In-Reply-To: References: Message-ID: > This PR implements a test to verify that Java will not negotiate TLS connections when one side of the connection requests disabled cipher suites. Matthew Donovan 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 six additional commits since the last revision: - Merge branch 'master' into JDK-8301379 - refactored to combine common code, use ssl test template class - added all disabled ciphers - cleaned up code, combined individual executions - Merge branch 'master' into JDK-8301379 - 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14316/files - new: https://git.openjdk.org/jdk/pull/14316/files/64e32b89..d66a7c2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=02-03 Stats: 15001 lines in 472 files changed: 4573 ins; 8815 del; 1613 mod Patch: https://git.openjdk.org/jdk/pull/14316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14316/head:pull/14316 PR: https://git.openjdk.org/jdk/pull/14316 From mdonovan at openjdk.org Thu Jun 15 12:36:00 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 15 Jun 2023 12:36:00 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v4] In-Reply-To: <8gn13OHKYr7lLycHTTjR71BiZdMMdP1ansKW63LdmR4=.9a9cb302-04de-4257-99df-46f9f7e09eac@github.com> References: <8gn13OHKYr7lLycHTTjR71BiZdMMdP1ansKW63LdmR4=.9a9cb302-04de-4257-99df-46f9f7e09eac@github.com> Message-ID: On Wed, 14 Jun 2023 13:43:37 GMT, Sean Mullan wrote: >> I added all of the disable ciphers that are listed in DisabledAlgorithms. Let me know if this isn't what you were thinking. Thanks! > > Yes, this is what I was thinking. There is another test `test/jdk/javax/net/ssl/ciphersuites/DisabledAlgorithms.java` that is very similar to this test. Can you compare these two tests and consider removing that test, or combining them if there are other things that test is testing that this one isn't? The tests look similar but are definitely testing different code paths. I didn't combine the tests because they're different enough in how they work that making them one test would be messier than having two tests. I did, however, relocate my new test to the same directory as `DisabledAlgorithms` and changed it to use the same list of disabled ciphers so when we need to add to the list, it's covered by both tests. Also, while there, I updated DisabledAlgorithms to use the SSL test template classes instead of the binary {key,trust}store files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1230941148 From mullan at openjdk.org Thu Jun 15 15:10:03 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jun 2023 15:10:03 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 20:38:18 GMT, Ben Perez wrote: >> Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed array copy to be more compact src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java line 96: > 94: } > 95: } > 96: return encoding.clone(); Missed this before, but if the code on line 89 throws an Exception, then encoding will be null, so you also want to check for null on line 96 to avoid an NPE, i.e. `return (encoding == null) ? null : encoding.clone();` Same comment on line 182. test/jdk/sun/security/mscapi/EncodingMutability.java line 5: > 3: * @bug 8308808 > 4: * @requires os.family == "windows" > 5: * @modules jdk.crypto.mscapi/sun.security.mscapi I think you just need `jdk.crypto.mscapi` on this line as you are not accessing the internal `sun.security.mscapi` classes. test/jdk/sun/security/mscapi/EncodingMutability.java line 9: > 7: */ > 8: > 9: import java.security.*; Suggest including each import instead of wildcarding as there are not that many. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14425#discussion_r1231145007 PR Review Comment: https://git.openjdk.org/jdk/pull/14425#discussion_r1231159008 PR Review Comment: https://git.openjdk.org/jdk/pull/14425#discussion_r1231154401 From mullan at openjdk.org Thu Jun 15 16:12:13 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jun 2023 16:12:13 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v4] In-Reply-To: References: <8gn13OHKYr7lLycHTTjR71BiZdMMdP1ansKW63LdmR4=.9a9cb302-04de-4257-99df-46f9f7e09eac@github.com> Message-ID: On Thu, 15 Jun 2023 12:33:45 GMT, Matthew Donovan wrote: >> Yes, this is what I was thinking. There is another test `test/jdk/javax/net/ssl/ciphersuites/DisabledAlgorithms.java` that is very similar to this test. Can you compare these two tests and consider removing that test, or combining them if there are other things that test is testing that this one isn't? > > The tests look similar but are definitely testing different code paths. I didn't combine the tests because they're different enough in how they work that making them one test would be messier than having two tests. I did, however, relocate my new test to the same directory as `DisabledAlgorithms` and changed it to use the same list of disabled ciphers so when we need to add to the list, it's covered by both tests. Also, while there, I updated DisabledAlgorithms to use the SSL test template classes instead of the binary {key,trust}store files. Ok, I suggest adding a comment to the `DisabledAlgorithms` test to note that they are different. The one difference I see is that `DisabledAlgorithms` is also testing that the disabled suites can still be used if the security properties are empty. Other than that, they look somewhat similar but using different templates for setting things up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14316#discussion_r1231245021 From duke at openjdk.org Thu Jun 15 17:22:53 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 15 Jun 2023 17:22:53 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v3] In-Reply-To: References: Message-ID: > Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. Ben Perez has updated the pull request incrementally with two additional commits since the last revision: - Removed unnecessary imports - Removed unnecessary module in test. Catch null in getEncoded ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14425/files - new: https://git.openjdk.org/jdk/pull/14425/files/04b2a9d1..eb5b5948 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=01-02 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14425/head:pull/14425 PR: https://git.openjdk.org/jdk/pull/14425 From mdonovan at openjdk.org Thu Jun 15 17:26:10 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 15 Jun 2023 17:26:10 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v5] In-Reply-To: References: Message-ID: > This PR implements a test to verify that Java will not negotiate TLS connections when one side of the connection requests disabled cipher suites. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: added clarifying comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14316/files - new: https://git.openjdk.org/jdk/pull/14316/files/d66a7c2f..948d2d61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14316&range=03-04 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14316/head:pull/14316 PR: https://git.openjdk.org/jdk/pull/14316 From mullan at openjdk.org Thu Jun 15 18:12:05 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jun 2023 18:12:05 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 17:22:53 GMT, Ben Perez wrote: >> Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. > > Ben Perez has updated the pull request incrementally with two additional commits since the last revision: > > - Removed unnecessary imports > - Removed unnecessary module in test. Catch null in getEncoded test/jdk/sun/security/mscapi/EncodingMutability.java line 1: > 1: /* Missing Oracle/OpenJDK copyright. Just copy from another test and change date to 2023. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14425#discussion_r1231378389 From mullan at openjdk.org Thu Jun 15 18:12:16 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jun 2023 18:12:16 GMT Subject: RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated [v5] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 17:26:10 GMT, Matthew Donovan wrote: >> This PR implements a test to verify that Java will not negotiate TLS connections when one side of the connection requests disabled cipher suites. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > added clarifying comment Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14316#pullrequestreview-1482147274 From duke at openjdk.org Thu Jun 15 19:13:37 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 15 Jun 2023 19:13:37 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v4] In-Reply-To: References: Message-ID: > Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: added copyrite to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14425/files - new: https://git.openjdk.org/jdk/pull/14425/files/eb5b5948..112a70db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=02-03 Stats: 30 lines in 1 file changed: 26 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14425/head:pull/14425 PR: https://git.openjdk.org/jdk/pull/14425 From mdonovan at openjdk.org Thu Jun 15 19:20:20 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 15 Jun 2023 19:20:20 GMT Subject: Integrated: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated In-Reply-To: References: Message-ID: <93NNVbYx-g78bDplle0-5GCnZUwkaydTNSaYgY6CPcw=.33a6209d-026e-44e2-9043-da59324d65fb@github.com> On Mon, 5 Jun 2023 18:22:13 GMT, Matthew Donovan wrote: > This PR implements a test to verify that Java will not negotiate TLS connections when one side of the connection requests disabled cipher suites. This pull request has now been integrated. Changeset: 9f64a643 Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/9f64a64376c677dbe1358807329b42737ac78ad9 Stats: 311 lines in 2 files changed: 179 ins; 51 del; 81 mod 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/14316 From jlu at openjdk.org Thu Jun 15 19:45:52 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 19:45:52 GMT Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. This pull request has now been integrated. Changeset: 81bfd789 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/81bfd78901ff540ad0355a466cfad097e701028a Stats: 460 lines in 50 files changed: 279 ins; 48 del; 133 mod 8309632: JDK 21 RDP1 L10n resource files update Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/14430 From mullan at openjdk.org Thu Jun 15 19:55:51 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jun 2023 19:55:51 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v4] In-Reply-To: References: Message-ID: <0lGDcTeTMkNLq-d5zpuqDSV-MAO_0upEdbwA9cPzVhM=.da55898c-b213-4d29-8a64-0328edc06854@github.com> On Thu, 15 Jun 2023 19:13:37 GMT, Ben Perez wrote: >> Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > added copyrite to test test/jdk/sun/security/mscapi/EncodingMutability.java line 2: > 1: /* > 2: * Copyright (c) 2005, 2023, Oracle and/or its affiliates. All rights reserved. Should only have the initial year the code was created and the last year that the code is updated, so in this case it should just have 2023. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14425#discussion_r1231472155 From kcr at openjdk.org Thu Jun 15 20:05:30 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jun 2023 20:05:30 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. I was > @kevinrushforth Thanks for the reminder, will make the change in ML first. Thanks. And I see you made this PR Draft, which is a good idea. Once the mainline PR is integrated, you can change the title of this PR to `Backport NNNNNNNNNNN`, where `NNNNNNNNNNN` is the 40 character commit hash of the jdk master commit. Then Skara will note this as a Backport, and also note whether it is a clean backport. ------------- PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588176435 From duke at openjdk.org Thu Jun 15 20:05:31 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Thu, 15 Jun 2023 20:05:31 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115: > 113: main.help.opt.main.validate=\ --validate Validiert den Inhalt des JAR-Archivs. Diese Option\n validiert, dass die von einem Multi-Release-JAR-Archiv\n exportierte API \u00FCber die verschiedenen Releaseversionen\n hinweg konsistent ist. > 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n -C DIR Zum angegebenen Verzeichnis wechseln und die folgende\n Datei aufnehmen > 115: main.help.opt.any.file=\ -f, --file=FILE Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n stdout verwendet, je nach Vorgang\n --release VERSION Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n der JAR-Datei (d.h. META-INF/versions/VERSION/) (Review comment moved to mainline PR) ------------- PR Review Comment: https://git.openjdk.org/jdk21/pull/11#discussion_r1227287139 From duke at openjdk.org Thu Jun 15 20:57:44 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 15 Jun 2023 20:57:44 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v5] In-Reply-To: References: Message-ID: > Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: fixed copyrite date ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14425/files - new: https://git.openjdk.org/jdk/pull/14425/files/112a70db..3e6485cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14425&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14425/head:pull/14425 PR: https://git.openjdk.org/jdk/pull/14425 From kcr at openjdk.org Thu Jun 15 21:09:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jun 2023 21:09:09 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean") ------------- PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593724465 From jlu at openjdk.org Thu Jun 15 21:13:00 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 21:13:00 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <8055MPxK8nGDItLuewscD0HhRwu4yJHWRoWg1H_SEu4=.7a2b5b3b-422c-4d32-8b68-d856a6ac8c05@github.com> On Thu, 15 Jun 2023 21:06:32 GMT, Kevin Rushforth wrote: > Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean") Hi Kevin, yes it is. I still need to grab the changes from mainline and include them in this PR. ------------- PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593728784 From mullan at openjdk.org Thu Jun 15 22:05:01 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jun 2023 22:05:01 GMT Subject: RFR: 8308808: SunMSCAPI public keys returns internal key array [v5] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 20:57:44 GMT, Ben Perez wrote: >> Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyrite date Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14425#pullrequestreview-1482448970 From weijun at openjdk.org Fri Jun 16 02:00:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Jun 2023 02:00:40 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry Message-ID: The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. The test uses some reflection to get this field and try updating it in multiple threads. ------------- Commit messages: - chmod a-x - the fix Changes: https://git.openjdk.org/jdk/pull/14506/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14506&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309667 Stats: 109 lines in 2 files changed: 106 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14506.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14506/head:pull/14506 PR: https://git.openjdk.org/jdk/pull/14506 From xuelei at openjdk.org Fri Jun 16 02:45:00 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 16 Jun 2023 02:45:00 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 01:21:57 GMT, Weijun Wang wrote: > The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. > > The test uses some reflection to get this field and try updating it in multiple threads. Nice catch! ------------- Marked as reviewed by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14506#pullrequestreview-1482638205 From peter.firmstone at zeus.net.au Fri Jun 16 02:48:17 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 16 Jun 2023 12:48:17 +1000 Subject: JDK-8280491 and JEP411 Message-ID: <97a17898-59d8-731d-6fe5-0096a0661c03@zeus.net.au> Release Note: Alternate Subject.getSubject and doAs APIs Created That Do Not Depend on Security Manager APIs https://bugs.openjdk.org/browse/JDK-8280491 Just wondering about the future implementation plans for these new API's? The implementation depends on deprecated for removal API's in JEP411, so this creates a level of indirection. My understanding is developers are supposed to migrate to the new API, so as not to depend on deprecated API, eg for establishing TLS connections using Subject credentials. As it isn't yet clear how a Subject context will be preserved across threads in future version of OpenJDK, (currently we use the AccessControlContext for that), for example we capture the existing context, to establish TLS connections in call back communications for network event listeners. So it appears we can change to these methods now, and it will work using the same methods as we use now, but it isn't clear whether it will still behave in a compatible way in future.? Will our TLS connections still be able to obtain the authenticated subject??? Will it still work if there are multiple authenticated Subject threads, from remotely authenticated connections, after the removal of deprecated API, will there be new API to preserve an Authenticated subject across threads? Thanks in adv. -- Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From wetmore at openjdk.org Fri Jun 16 02:56:14 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 Jun 2023 02:56:14 GMT Subject: RFR: 8310106: sun.security.ssl.SSLHandshake.getHandshakeProducer() incorrectly checks handshakeConsumers In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 06:02:13 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/JDK-8310106? > > The commit here fixes the typo in `sun.security.ssl.SSLHandshake.getHandshakeProducer()` method to correctly use `handshakeProducers`. > > I checked if a new jtreg test could be added for this, but given where this change resides and the nature of this change, I don't see a way to add one. Existing tests in `tier1`, `tier2` and `tier3` continue to pass with this change. LGTM. I think I understand why we never saw any impact. Tagging @XueleiFan in case he wants to also review it, but this looks pretty straightforward. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14483#pullrequestreview-1482643233 From xuelei at openjdk.org Fri Jun 16 02:56:15 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 16 Jun 2023 02:56:15 GMT Subject: RFR: 8310106: sun.security.ssl.SSLHandshake.getHandshakeProducer() incorrectly checks handshakeConsumers In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 06:02:13 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/JDK-8310106? > > The commit here fixes the typo in `sun.security.ssl.SSLHandshake.getHandshakeProducer()` method to correctly use `handshakeProducers`. > > I checked if a new jtreg test could be added for this, but given where this change resides and the nature of this change, I don't see a way to add one. Existing tests in `tier1`, `tier2` and `tier3` continue to pass with this change. Nice catch. Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14483#pullrequestreview-1482644422 From jlu at openjdk.org Fri Jun 16 04:39:42 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 16 Jun 2023 04:39:42 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. Justin Lu has updated the pull request incrementally with five additional commits since the last revision: - Review: correct previous commit, remove ? as well - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN - Review: Use old 'err.crash' zh_CN value - Review: use Naoto's recommended ja values - Revert 'main.help.opt.any.file' value for _de ------------- Changes: - all: https://git.openjdk.org/jdk21/pull/11/files - new: https://git.openjdk.org/jdk21/pull/11/files/13b8b309..a2e52373 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00-01 Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk21/pull/11.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11 PR: https://git.openjdk.org/jdk21/pull/11 From jpai at openjdk.org Fri Jun 16 05:41:20 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 Jun 2023 05:41:20 GMT Subject: RFR: 8310106: sun.security.ssl.SSLHandshake.getHandshakeProducer() incorrectly checks handshakeConsumers In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 06:02:13 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/JDK-8310106? > > The commit here fixes the typo in `sun.security.ssl.SSLHandshake.getHandshakeProducer()` method to correctly use `handshakeProducers`. > > I checked if a new jtreg test could be added for this, but given where this change resides and the nature of this change, I don't see a way to add one. Existing tests in `tier1`, `tier2` and `tier3` continue to pass with this change. Thank you Brad and Xuelei for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14483#issuecomment-1594132694 From jpai at openjdk.org Fri Jun 16 05:41:21 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 Jun 2023 05:41:21 GMT Subject: Integrated: 8310106: sun.security.ssl.SSLHandshake.getHandshakeProducer() incorrectly checks handshakeConsumers In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 06:02:13 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/JDK-8310106? > > The commit here fixes the typo in `sun.security.ssl.SSLHandshake.getHandshakeProducer()` method to correctly use `handshakeProducers`. > > I checked if a new jtreg test could be added for this, but given where this change resides and the nature of this change, I don't see a way to add one. Existing tests in `tier1`, `tier2` and `tier3` continue to pass with this change. This pull request has now been integrated. Changeset: db133dbc Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/db133dbc02a7f38104fdbca967c59f758c6f4336 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8310106: sun.security.ssl.SSLHandshake.getHandshakeProducer() incorrectly checks handshakeConsumers Reviewed-by: wetmore, xuelei ------------- PR: https://git.openjdk.org/jdk/pull/14483 From Alan.Bateman at oracle.com Fri Jun 16 05:48:29 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2023 06:48:29 +0100 Subject: JDK-8280491 and JEP411 In-Reply-To: <97a17898-59d8-731d-6fe5-0096a0661c03@zeus.net.au> References: <97a17898-59d8-731d-6fe5-0096a0661c03@zeus.net.au> Message-ID: <60f4faba-21a9-07d8-a1bb-36e7605dd40d@oracle.com> On 16/06/2023 03:48, Peter Firmstone wrote: > : > > As it isn't yet clear how a Subject context will be preserved across > threads in future version of OpenJDK, (currently we use the > AccessControlContext for that), for example we capture the existing > context, to establish TLS connections in call back communications for > network event listeners. > It's good to think about a Subject.current/callAs re-implemented to use ScopedValue [1], currently in preview with JEP 446 in Java 21. ScopedValue allows for sharing in structured concurrency contexts. -Alan [1] https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/ScopedValue.html [2] https://openjdk.org/jeps/446 From jnimeh at openjdk.org Fri Jun 16 05:51:59 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 16 Jun 2023 05:51:59 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v3] In-Reply-To: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> Message-ID: On Wed, 3 May 2023 11:26:32 GMT, Matthew Donovan wrote: >> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. >> >> Thanks > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > made handshake context lock final This looks good to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13742#pullrequestreview-1482759220 From xuelei at openjdk.org Fri Jun 16 06:27:02 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 16 Jun 2023 06:27:02 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v3] In-Reply-To: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> Message-ID: On Wed, 3 May 2023 11:26:32 GMT, Matthew Donovan wrote: >> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. >> >> Thanks > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > made handshake context lock final src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 914: > 912: @Override > 913: public SSLSession getHandshakeSession() { > 914: engineLock.lock(); I'm not very sure of this update. By removing the enginLock on socket/engine level here, is it possible there are two threads that one read the handshake session and another on write? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1231827430 From peter.firmstone at zeus.net.au Fri Jun 16 07:32:19 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 16 Jun 2023 17:32:19 +1000 Subject: JDK-8280491 and JEP411 In-Reply-To: <60f4faba-21a9-07d8-a1bb-36e7605dd40d@oracle.com> References: <97a17898-59d8-731d-6fe5-0096a0661c03@zeus.net.au> <60f4faba-21a9-07d8-a1bb-36e7605dd40d@oracle.com> Message-ID: Thanks Alan, That's quite interesting.?? Often we use Executor tasks to perform event notifications to listeners, context is the same across many, in fact we do this for distributed garbage collection over TLS connections too. -- Regards, Peter On 16/06/2023 3:48 pm, Alan Bateman wrote: > On 16/06/2023 03:48, Peter Firmstone wrote: >> : >> >> As it isn't yet clear how a Subject context will be preserved across >> threads in future version of OpenJDK, (currently we use the >> AccessControlContext for that), for example we capture the existing >> context, to establish TLS connections in call back communications for >> network event listeners. >> > > It's good to think about a Subject.current/callAs re-implemented to > use ScopedValue [1], currently in preview with JEP 446 in Java 21. > ScopedValue allows for sharing in structured concurrency contexts. > > -Alan > > [1] > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/ScopedValue.html > [2] https://openjdk.org/jeps/446 From dfuchs at openjdk.org Fri Jun 16 09:31:01 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 16 Jun 2023 09:31:01 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 01:21:57 GMT, Weijun Wang wrote: > The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. > > The test uses some reflection to get this field and try updating it in multiple threads. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1438: > 1436: > 1437: if (entry.attributes == null) { > 1438: entry.attributes = ConcurrentHashMap.newKeySet(); It seems that there is still a risk that two threads may compete here, then you may end up with one thread working with a different copy of the attributes, no longer tied to the entry. E.g: Thread#1 sees attributes is null, Thread#2 sees attributes is null, both set attributes and only one of them win. The caller in the second thread (that lost) is given the "dangling" map that has not been set, and if it modifies it then modifications will be lost. I don't know if this scenario can actually happen - but the possibility is there. Unless there's always some locking further up the stack that would prevent this? Also I see in total four places that do: [entry|this].attributes = new HashSet<>(); wouldn't you need to modify all four places in the same manner? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14506#discussion_r1232011194 From djelinski at openjdk.org Fri Jun 16 10:06:02 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 16 Jun 2023 10:06:02 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 01:21:57 GMT, Weijun Wang wrote: > The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. > > The test uses some reflection to get this field and try updating it in multiple threads. Would it be possible to only catch checked exceptions in `X509KeyManagerImpl.getEntry`? Currently the exception is discarded without a trace, which made debugging this a bit of a challenge. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1: > 1: /* Please modify the `entry.attributes` initializers in lines 240, 700 and 2519 as well. I suppose you could also make the `attributes` final and initialize in line. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2434: > 2432: byte[] keyId = null; > 2433: ObjectIdentifier[] trustedKeyUsage = null; > 2434: Set attributes = new HashSet<>(); This change is not necessary; this set is never used by other threads. ------------- Changes requested by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14506#pullrequestreview-1483127112 PR Review Comment: https://git.openjdk.org/jdk/pull/14506#discussion_r1232039978 PR Review Comment: https://git.openjdk.org/jdk/pull/14506#discussion_r1232039628 From coffeys at openjdk.org Fri Jun 16 11:14:38 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 16 Jun 2023 11:14:38 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v4] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey has updated the pull request incrementally with two additional commits since the last revision: - Refactor out security code to helper class - Print aliases. Order Provider type/service output. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/55a85e38..020a1863 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=02-03 Stats: 350 lines in 3 files changed: 211 ins; 133 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From coffeys at openjdk.org Fri Jun 16 11:14:39 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 16 Jun 2023 11:14:39 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: <1K5PfrEc4i0qS14H3IVOBHlVLrZSzcSbMnDkbKbmbo0=.a5a99be5-cedf-427e-a334-17205534243c@github.com> On Thu, 15 Jun 2023 06:32:06 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 183: >> >>> 181: case "locale": >>> 182: printLocale(); >>> 183: break; >> >> printLocale might need the same treatment to avoid printing the list of all locales by default. > > Have you tried putting the new code into say sun.launcher.SecuritySettings to avoid adding so much security conf code into LauncherHelper? Maybe eventually this will need to a more pluggable as -XshowSettings has grown a bit beyond what it was originally for. Logged https://bugs.openjdk.org/browse/JDK-8310201 to track the Locale changes Alan. Good suggestion on factoring out the security code to a helper class. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232109645 From coffeys at openjdk.org Fri Jun 16 11:14:39 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 16 Jun 2023 11:14:39 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: <1_nHxqnq9Jx8_a_WHvoxRVlO1DnnTdjGSVeyOyD7d6U=.c8e1489f-eff9-4f96-b548-d7ebd3bc83be@github.com> On Wed, 14 Jun 2023 14:06:33 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 424: >> >>> 422: if (!services.isEmpty()) { >>> 423: services.stream() >>> 424: .sorted(Comparator.comparing(Provider.Service::getType)) >> >> How about sorting by algorithm within the same type? >> >> Another suggestion: adding aliases to output, for example: `Signature: Ed25519 (1.3.101.112, OID.1.3.101.112)`. > > +1 to sorting by algorithm name within same type. good point. done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232107493 From coffeys at openjdk.org Fri Jun 16 11:14:39 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 16 Jun 2023 11:14:39 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 12:46:36 GMT, Weijun Wang wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporate review comments from Roger and tweak some code > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 357: > >> 355: private static void printSecuritySummarySettings() { >> 356: ostream.println("Security settings summary: " + "\n" + >> 357: INDENT + "Use \"-XshowSettings:security\" for verbose details\n"); > > Is it helpful to list sub-options here? I think it might be better to delegate to `java -X` help output actually. tweaked code in this area. (I could see the subcommand options becoming inaccurate if we add more such subcommands in the future). -X help output should be our reference > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 378: > >> 376: ostream.println(TWOINDENT + key + "="); >> 377: List.of(val.split(",")).forEach( >> 378: s -> ostream.println(THREEINDENT + s.trim() + ",")); > > Will this print a comma for the last line? yes, I was hoping it wouldn't be an issue! modified code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232108994 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232107328 From coffeys at openjdk.org Fri Jun 16 11:17:01 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 16 Jun 2023 11:17:01 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: References: Message-ID: <6d5iDkOICVDpQQX8w35_tRV0JoNyvIoMwVand9UD2fw=.227423ad-484d-43d0-946b-6fd84938d14b@github.com> On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Roger and tweak some code Incorporated all comments to date. Took Tony's point on board. The provider output format is now `type.service` the refactoring of code into new security helper class might make it harder to determine recent changes. I committed the main changes before the refactor operation. Might make review easier : https://github.com/openjdk/jdk/pull/14394/commits/1af66eb6362c15a92ce03b0ab8667d6d3a0cb673 Need to update details in CSR also. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1594515340 From alanb at openjdk.org Fri Jun 16 11:27:17 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jun 2023 11:27:17 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v4] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 11:14:38 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor out security code to helper class > - Print aliases. Order Provider type/service output. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 132: > 130: ResourceBundle.getBundle(defaultBundleName); > 131: } > 132: static PrintStream ostream; I don't think we want SecuritySettings accessing LauncherHelper's field like this. I assume printSecuritySetting is just missing a PrintStream parameter so that it can be called to print the security settings to a given stream. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 276: > 274: first = false; > 275: } else { // following lines prefix with indents > 276: ostream.println(TWOINDENT + s); I assume these changes are per reverted now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232121754 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232121990 From alanb at openjdk.org Fri Jun 16 11:27:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jun 2023 11:27:18 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v3] In-Reply-To: <1K5PfrEc4i0qS14H3IVOBHlVLrZSzcSbMnDkbKbmbo0=.a5a99be5-cedf-427e-a334-17205534243c@github.com> References: <1K5PfrEc4i0qS14H3IVOBHlVLrZSzcSbMnDkbKbmbo0=.a5a99be5-cedf-427e-a334-17205534243c@github.com> Message-ID: On Fri, 16 Jun 2023 11:09:23 GMT, Sean Coffey wrote: > Logged https://bugs.openjdk.org/browse/JDK-8310201 to track the Locale changes Alan. Thanks, probably should treat this as a bug for JDK 21 so that a new addition doesn't change behavior between 21 and 22. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232123081 From mdonovan at openjdk.org Fri Jun 16 12:00:59 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 16 Jun 2023 12:00:59 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v4] In-Reply-To: References: Message-ID: > In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. > > Thanks Matthew Donovan 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 five additional commits since the last revision: - I missed a method that needed updating - Merge branch 'master' into socket-close-null - made handshake context lock final - using try/finally in terminateHandshakeContext and using local context variable in all places it should be - 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13742/files - new: https://git.openjdk.org/jdk/pull/13742/files/92a48a70..e95cef8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=02-03 Stats: 263186 lines in 4286 files changed: 195335 ins; 39118 del; 28733 mod Patch: https://git.openjdk.org/jdk/pull/13742.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13742/head:pull/13742 PR: https://git.openjdk.org/jdk/pull/13742 From mdonovan at openjdk.org Fri Jun 16 12:01:39 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 16 Jun 2023 12:01:39 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v4] In-Reply-To: References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> Message-ID: On Fri, 16 Jun 2023 06:24:36 GMT, Xue-Lei Andrew Fan wrote: >> Matthew Donovan 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 five additional commits since the last revision: >> >> - I missed a method that needed updating >> - Merge branch 'master' into socket-close-null >> - made handshake context lock final >> - using try/finally in terminateHandshakeContext and using local context variable in all places it should be >> - 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException > > src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 914: > >> 912: @Override >> 913: public SSLSession getHandshakeSession() { >> 914: engineLock.lock(); > > I'm not very sure of this update. By removing the enginLock on socket/engine level here, is it possible there are two threads that one read the handshake session and another on write? `engineLock` was used to here to make sure that `conContext.handshakeContext` is not null before accessing it. The problem is that the `handshakeContext` is modified (set to null) by the `TransportContext` class. So using a lock in SSLEngineImpl or SSLSocketImpl doesn't protect `handshakeContext` from becoming null between the check and use. The actual SSLSession object was never protected from concurrent modification (unless it has its own lock.) When reviewing the code to answer this, I noticed that I needed to update `SSLEngineImpl.getHandshakeApplicationProtocol()` so there is a new commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1232155247 From coffeys at openjdk.org Fri Jun 16 12:14:49 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 16 Jun 2023 12:14:49 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v5] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Pass PrintStream to security helper ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/020a1863..91dc41f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=03-04 Stats: 14 lines in 2 files changed: 5 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From weijun at openjdk.org Fri Jun 16 12:30:17 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Jun 2023 12:30:17 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v2] In-Reply-To: References: Message-ID: > The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. > > The test uses some reflection to get this field and try updating it in multiple threads. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: add a log message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14506/files - new: https://git.openjdk.org/jdk/pull/14506/files/1d817b6f..62b57ba5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14506&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14506&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14506.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14506/head:pull/14506 PR: https://git.openjdk.org/jdk/pull/14506 From weijun at openjdk.org Fri Jun 16 12:52:00 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Jun 2023 12:52:00 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v3] In-Reply-To: References: Message-ID: > The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. > > The test uses some reflection to get this field and try updating it in multiple threads. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more cases to cover ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14506/files - new: https://git.openjdk.org/jdk/pull/14506/files/62b57ba5..dca45ad0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14506&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14506&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14506.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14506/head:pull/14506 PR: https://git.openjdk.org/jdk/pull/14506 From weijun at openjdk.org Fri Jun 16 12:52:02 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Jun 2023 12:52:02 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 09:53:10 GMT, Daniel Jeli?ski wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> more cases to cover > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1: > >> 1: /* > > Please modify the `entry.attributes` initializers in lines 240, 700 and 2519 as well. I suppose you could also make the `attributes` final and initialize in line. Thanks. I'll keep the structure as it is now. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2434: > >> 2432: String alias = null; >> 2433: byte[] keyId = null; >> 2434: ObjectIdentifier[] trustedKeyUsage = null; > > This change is not necessary; this set is never used by other threads. Correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14506#discussion_r1232203289 PR Review Comment: https://git.openjdk.org/jdk/pull/14506#discussion_r1232203002 From weijun at openjdk.org Fri Jun 16 12:52:06 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Jun 2023 12:52:06 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 09:25:30 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> more cases to cover > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1438: > >> 1436: >> 1437: if (entry.attributes == null) { >> 1438: entry.attributes = ConcurrentHashMap.newKeySet(); > > It seems that there is still a risk that two threads may compete here, then you may end up with one thread working with a different copy of the attributes, no longer tied to the entry. E.g: > > Thread#1 sees attributes is null, Thread#2 sees attributes is null, both set attributes and only one of them win. The caller in the second thread (that lost) is given the "dangling" map that has not been set, and if it modifies it then modifications will be lost. > I don't know if this scenario can actually happen - but the possibility is there. Unless there's always some locking further up the stack that would prevent this? > > Also I see in total four places that do: > > [entry|this].attributes = new HashSet<>(); > > > wouldn't you need to modify all four places in the same manner? Correct. Done. I'll look into making the classes immutable in the next release. I hesitate to make such a big change in RDP. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14506#discussion_r1232205474 From xuelei at openjdk.org Fri Jun 16 13:57:02 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 16 Jun 2023 13:57:02 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v4] In-Reply-To: References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> Message-ID: <0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com> On Fri, 16 Jun 2023 11:59:01 GMT, Matthew Donovan wrote: >> src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 914: >> >>> 912: @Override >>> 913: public SSLSession getHandshakeSession() { >>> 914: engineLock.lock(); >> >> I'm not very sure of this update. By removing the enginLock on socket/engine level here, is it possible there are two threads that one read the handshake session and another on write? > > `engineLock` was used to here to make sure that `conContext.handshakeContext` is not null before accessing it. The problem is that the `handshakeContext` is modified (set to null) by the `TransportContext` class. So using a lock in SSLEngineImpl or SSLSocketImpl doesn't protect `handshakeContext` from becoming null between the check and use. > > The actual SSLSession object was never protected from concurrent modification (unless it has its own lock.) > > When reviewing the code to answer this, I noticed that I needed to update `SSLEngineImpl.getHandshakeApplicationProtocol()` so there is a new commit. I had a search of the value assignment of handshakeSession. Here is one example of the calling stack: SSLEngineImpl.DelegatedTask.run()->TransportContext.dispatch()->SSLHandshake().consume()->HandshakeConsumer.consume()->SSLExtensions.product()->ServerHello.produce()->shc.handshakeSession = session The engineLock was placed on SSLEngineImpl.DelegatedTask.run() and released after complete the job, which means the value assignment of handshakeSession is synchronized. The locks in SSLEngineImpl and SSLSocketImpl are used for operations synchronization so that other classes may not need additional locks in most cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1232286405 From dfuchs at openjdk.org Fri Jun 16 14:20:02 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 16 Jun 2023 14:20:02 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v3] In-Reply-To: References: Message-ID: <9htKSZ-h1ndBb2b2Mu8lObyDuQd6v4xQmWvXs_fszpY=.3a0a4834-ab6b-45b8-b0fc-b8656c3aa5ac@github.com> On Fri, 16 Jun 2023 12:45:58 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1438: >> >>> 1436: >>> 1437: if (entry.attributes == null) { >>> 1438: entry.attributes = ConcurrentHashMap.newKeySet(); >> >> It seems that there is still a risk that two threads may compete here, then you may end up with one thread working with a different copy of the attributes, no longer tied to the entry. E.g: >> >> Thread#1 sees attributes is null, Thread#2 sees attributes is null, both set attributes and only one of them win. The caller in the second thread (that lost) is given the "dangling" map that has not been set, and if it modifies it then modifications will be lost. >> I don't know if this scenario can actually happen - but the possibility is there. Unless there's always some locking further up the stack that would prevent this? >> >> Also I see in total four places that do: >> >> [entry|this].attributes = new HashSet<>(); >> >> >> wouldn't you need to modify all four places in the same manner? > > Correct. Done. > > I'll look into making the classes immutable in the next release. I hesitate to make such a big change in RDP. I wonder if this would work, if you don't want to use final or volatile + CAS: class Entry { ... private Set createAttributesMap() { synchronized (this) { var attributes = this.attributes; if (attributes == null) { return attributes = this.attributes = ConcurrentHashMap.newKeySet(); } else return attributes; } } } ... if (entry.attributes == null) { entry.attributes = entry.createAttributesMap(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14506#discussion_r1232315157 From mdonovan at openjdk.org Fri Jun 16 14:27:06 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 16 Jun 2023 14:27:06 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v4] In-Reply-To: <0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com> References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> <0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com> Message-ID: On Fri, 16 Jun 2023 13:54:37 GMT, Xue-Lei Andrew Fan wrote: >> `engineLock` was used to here to make sure that `conContext.handshakeContext` is not null before accessing it. The problem is that the `handshakeContext` is modified (set to null) by the `TransportContext` class. So using a lock in SSLEngineImpl or SSLSocketImpl doesn't protect `handshakeContext` from becoming null between the check and use. >> >> The actual SSLSession object was never protected from concurrent modification (unless it has its own lock.) >> >> When reviewing the code to answer this, I noticed that I needed to update `SSLEngineImpl.getHandshakeApplicationProtocol()` so there is a new commit. > > I had a search of the value assignment of handshakeSession. Here is one example of the calling stack: > SSLEngineImpl.DelegatedTask.run()->TransportContext.dispatch()->SSLHandshake().consume()->HandshakeConsumer.consume()->SSLExtensions.product()->ServerHello.produce()->shc.handshakeSession = session > > The engineLock was placed on SSLEngineImpl.DelegatedTask.run() and released after complete the job, which means the value assignment of handshakeSession is synchronized. > > The locks in SSLEngineImpl and SSLSocketImpl are used for operations synchronization so that other classes may not need additional locks in most cases. I see what you're saying with respect to SSLEngineImpl. It looks like all of the public methods are synchronized with `engineLock` so I shouldn't have made any changes there. I will revert them. Are you ok with the changes in SSLSocketImpl? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1232323601 From xuelei at openjdk.org Fri Jun 16 14:33:08 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 16 Jun 2023 14:33:08 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v4] In-Reply-To: References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> <0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com> Message-ID: On Fri, 16 Jun 2023 14:24:17 GMT, Matthew Donovan wrote: >> I had a search of the value assignment of handshakeSession. Here is one example of the calling stack: >> SSLEngineImpl.DelegatedTask.run()->TransportContext.dispatch()->SSLHandshake().consume()->HandshakeConsumer.consume()->SSLExtensions.product()->ServerHello.produce()->shc.handshakeSession = session >> >> The engineLock was placed on SSLEngineImpl.DelegatedTask.run() and released after complete the job, which means the value assignment of handshakeSession is synchronized. >> >> The locks in SSLEngineImpl and SSLSocketImpl are used for operations synchronization so that other classes may not need additional locks in most cases. > > I see what you're saying with respect to SSLEngineImpl. It looks like all of the public methods are synchronized with `engineLock` so I shouldn't have made any changes there. I will revert them. > > Are you ok with the changes in SSLSocketImpl? I may update both SSLSocketImpl and SSLEngineImpl, as SSLSocketImpl uses the locks similar to SSLEngineImpl. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1232331470 From mdonovan at openjdk.org Fri Jun 16 14:49:10 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 16 Jun 2023 14:49:10 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v4] In-Reply-To: References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> <0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com> Message-ID: On Fri, 16 Jun 2023 14:30:33 GMT, Xue-Lei Andrew Fan wrote: >> I see what you're saying with respect to SSLEngineImpl. It looks like all of the public methods are synchronized with `engineLock` so I shouldn't have made any changes there. I will revert them. >> >> Are you ok with the changes in SSLSocketImpl? > > I may update both SSLSocketImpl and SSLEngineImpl, as SSLSocketImpl uses the locks similar to SSLEngineImpl. There is a difference, though. The close() method in SSLSocketImpl is not synchronized and there is the chance of a NullPointerException in duplexCloseOutput() because `conContext.handshakeContext` is being set to null by the TransportContext class in a different thread. I think that can affect any method in SSLSocketImpl that accesses that field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1232350669 From xuelei at openjdk.org Fri Jun 16 14:56:10 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 16 Jun 2023 14:56:10 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v4] In-Reply-To: References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> <0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com> Message-ID: On Fri, 16 Jun 2023 14:45:52 GMT, Matthew Donovan wrote: >> I may update both SSLSocketImpl and SSLEngineImpl, as SSLSocketImpl uses the locks similar to SSLEngineImpl. > > There is a difference, though. The close() method in SSLSocketImpl is not synchronized and there is the chance of a NullPointerException in duplexCloseOutput() because `conContext.handshakeContext` is being set to null by the TransportContext class in a different thread. I think that can affect any method in SSLSocketImpl that accesses that field. Yes, socket close is a headache problem for me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1232359603 From jnimeh at openjdk.org Fri Jun 16 15:01:09 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 16 Jun 2023 15:01:09 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v4] In-Reply-To: References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> <0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com> Message-ID: <2XuGMZnGZ8-4EACWi1YLy8rXEmWHwulFOK6QJkcPNrk=.80ab389c-ecf1-4597-83c1-1ff02b884124@github.com> On Fri, 16 Jun 2023 14:52:44 GMT, Xue-Lei Andrew Fan wrote: >> There is a difference, though. The close() method in SSLSocketImpl is not synchronized and there is the chance of a NullPointerException in duplexCloseOutput() because `conContext.handshakeContext` is being set to null by the TransportContext class in a different thread. I think that can affect any method in SSLSocketImpl that accesses that field. > > Yes, socket close is a headache problem for me. There's a bit of a history with SSLSocket closures since the new handshaker was brought into JDK11. Some of it dealt with synchronization, others with properly handling full vs. half-duplex closes. You may want to look up some of the bug history on changes surrounding the SSLSocket closures just to make sure we don't undo any fixes that were previously integrated. As Xuelei's comment indicates, this is a delicate part of the handshaker. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1232367902 From jjg at openjdk.org Fri Jun 16 15:09:14 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 16 Jun 2023 15:09:14 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com> On Tue, 13 Jun 2023 18:38:28 GMT, Naoto Sato wrote: > Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways. 1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594844435 From rriggs at openjdk.org Fri Jun 16 15:19:05 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 Jun 2023 15:19:05 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 12:14:49 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Pass PrintStream to security helper src/java.base/share/classes/sun/launcher/SecuritySettings.java line 66: > 64: ostream.println("Unrecognized security subcommand. See \"java -X\" for help"); > 65: ostream.println("Printing all security settings"); > 66: printAllSecurityConfig(); The error message is going to get lost in the volume of settings. Allowing bad command input reinforces learning the wrong suboption; though it may duplicate the help, I'd print the allowed options. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232388914 From duke at openjdk.org Fri Jun 16 16:50:11 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 16 Jun 2023 16:50:11 GMT Subject: Integrated: 8308808: SunMSCAPI public keys returns internal key array In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 18:49:59 GMT, Ben Perez wrote: > Changed `getEncoded` for both EC and RSA to return a copy of the internal key array to avoid mutability issues. This pull request has now been integrated. Changeset: 4eb4f20a Author: Ben Perez Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/4eb4f20ae22a8f6a49cbbcaa6603ee19ed078e8b Stats: 53 lines in 2 files changed: 48 ins; 0 del; 5 mod 8308808: SunMSCAPI public keys returns internal key array Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/14425 From naoto at openjdk.org Fri Jun 16 17:16:33 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Jun 2023 17:16:33 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com> References: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com> Message-ID: On Fri, 16 Jun 2023 15:06:30 GMT, Jonathan Gibbons wrote: >> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways. > >> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways. > > 1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. > 2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order. > 3. The iteration order would be undefined when resources are removed from one or more resource files Makes sense. Thanks for the explanation @jonathan-gibbons ------------- PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594999086 From sean.mullan at oracle.com Fri Jun 16 17:33:10 2023 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Jun 2023 13:33:10 -0400 Subject: JDK-8280491 and JEP411 In-Reply-To: <60f4faba-21a9-07d8-a1bb-36e7605dd40d@oracle.com> References: <97a17898-59d8-731d-6fe5-0096a0661c03@zeus.net.au> <60f4faba-21a9-07d8-a1bb-36e7605dd40d@oracle.com> Message-ID: See also https://bugs.openjdk.org/browse/JDK-8296244 --Sean On 6/16/23 1:48 AM, Alan Bateman wrote: > On 16/06/2023 03:48, Peter Firmstone wrote: >> : >> >> As it isn't yet clear how a Subject context will be preserved across >> threads in future version of OpenJDK, (currently we use the >> AccessControlContext for that), for example we capture the existing >> context, to establish TLS connections in call back communications for >> network event listeners. >> > > It's good to think about a Subject.current/callAs re-implemented to use > ScopedValue [1], currently in preview with JEP 446 in Java 21. > ScopedValue allows for sharing in structured concurrency contexts. > > -Alan > > [1] > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/ScopedValue.html > [2] https://openjdk.org/jeps/446 From weijun at openjdk.org Fri Jun 16 17:35:04 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Jun 2023 17:35:04 GMT Subject: RFR: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 12:52:00 GMT, Weijun Wang wrote: >> The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. >> >> The test uses some reflection to get this field and try updating it in multiple threads. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > more cases to cover I'm closing this PR since the bug is a P4 and is not allowed to be fixed in JDK 21. I'll look for a more thorough fix for JDK 22. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14506#issuecomment-1595017841 From weijun at openjdk.org Fri Jun 16 17:35:05 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Jun 2023 17:35:05 GMT Subject: Withdrawn: 8309667: TLS handshake fails because of ConcurrentModificationException in PKCS12KeyStore.engineGetEntry In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 01:21:57 GMT, Weijun Wang wrote: > The `attributes` field inside the `PKCS12KeyStore.Entry` class might be modified and retrieved at the same time. Make it concurrent. > > The test uses some reflection to get this field and try updating it in multiple threads. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14506 From jnimeh at openjdk.org Fri Jun 16 18:27:39 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 16 Jun 2023 18:27:39 GMT Subject: RFR: 8309740: Expand timeout windows for tests in JDK-8179502 Message-ID: This PR is for tests that were modified/added in JDK-8179502. The timeout windows for those tests were a little too short on some test systems, especially when the system is under heavy load. After a few iterations trying out various longer time windows I have a set that should not run into issues. ------------- Commit messages: - 8309740: Expand timeout windows for tests in JDK-8179502 Changes: https://git.openjdk.org/jdk/pull/14526/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14526&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309740 Stats: 21 lines in 3 files changed: 5 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/14526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14526/head:pull/14526 PR: https://git.openjdk.org/jdk/pull/14526 From xuelei at openjdk.org Fri Jun 16 18:45:10 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 16 Jun 2023 18:45:10 GMT Subject: RFR: 8309740: Expand timeout windows for tests in JDK-8179502 In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 18:19:45 GMT, Jamil Nimeh wrote: > This PR is for tests that were modified/added in JDK-8179502. The timeout windows for those tests were a little too short on some test systems, especially when the system is under heavy load. After a few iterations trying out various longer time windows I have a set that should not run into issues. Marked as reviewed by xuelei (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14526#pullrequestreview-1484122264 From ascarpino at openjdk.org Fri Jun 16 20:24:17 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 16 Jun 2023 20:24:17 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base Message-ID: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Hi, I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. Thanks Tony ------------- Commit messages: - CheckSecurityProvider test - fix module check test - whitespace and apple - merge - cleanup - cleanup - find/replace and ide screwups - add test - Initial - cleanup - ... and 4 more: https://git.openjdk.org/jdk/compare/8aad881e...85870520 Changes: https://git.openjdk.org/jdk/pull/14457/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308398 Stats: 172 lines in 57 files changed: 62 ins; 40 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/14457.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14457/head:pull/14457 PR: https://git.openjdk.org/jdk/pull/14457 From weijun at openjdk.org Fri Jun 16 20:37:11 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Jun 2023 20:37:11 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino wrote: > Hi, > > I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. > > There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. > > Thanks > > Tony src/java.base/share/classes/sun/security/jca/ProviderConfig.java line 179: > 177: } > 178: > 179: switch (provName) { Looks like you can use a switch expression here, i.e. `p = switch ...`. src/jdk.crypto.ec/share/classes/module-info.java line 36: > 34: @Deprecated(since="22", forRemoval = true) > 35: module jdk.crypto.ec { > 36: //provides java.security.Provider with sun.security.ec.SunEC; Just remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1232745489 PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1232749460 From naoto at openjdk.org Fri Jun 16 21:02:17 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Jun 2023 21:02:17 GMT Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 04:39:42 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> image >> >> >> Please note that the HTML files only apply to .properties, and not .java resources. > > Justin Lu has updated the pull request incrementally with five additional commits since the last revision: > > - Review: correct previous commit, remove ? as well > - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN > - Review: Use old 'err.crash' zh_CN value > - Review: use Naoto's recommended ja values > - Revert 'main.help.opt.any.file' value for _de Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/11#pullrequestreview-1484380340 From jlu at openjdk.org Fri Jun 16 21:14:20 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 16 Jun 2023 21:14:20 GMT Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > image > > > Please note that the HTML files only apply to .properties, and not .java resources. This pull request has now been integrated. Changeset: a1c1d97a Author: Justin Lu URL: https://git.openjdk.org/jdk21/commit/a1c1d97a4e07bae872b5608b4d8d8f85195edd82 Stats: 460 lines in 50 files changed: 279 ins; 48 del; 133 mod 8309632: JDK 21 RDP1 L10n resource files update Reviewed-by: naoto Backport-of: 81bfd78901ff540ad0355a466cfad097e701028a ------------- PR: https://git.openjdk.org/jdk21/pull/11 From vlivanov at openjdk.org Sat Jun 17 00:44:23 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 17 Jun 2023 00:44:23 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Wed, 14 Jun 2023 19:29:45 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'openjdk:master' into rematerialization-of-merges > - Rome minor refactorings. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > Catching up with master. > - Address PR review 6: debug format output & some refactoring. > - Catching up with master branch. > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address PR review 6: refactoring around rematerialization & improve test cases. > - Address PR review 5: refactor on rematerialization & add tests. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address part of PR review 4 & fix a bug setting only_candidate > - Catching up with master > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - ... and 9 more: https://git.openjdk.org/jdk/compare/57b82512...939dcffe Testing results (both functional and performance) are good. In addition, I tested with a `C.failure_reason_is(retry_no_reduce_allocation_merges()) == true` guarantee and there were no failures observed. Once you address my latest comments I'll mark the PR as reviewed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1595520571 From weijun at openjdk.org Sat Jun 17 01:54:12 2023 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 17 Jun 2023 01:54:12 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 12:14:49 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Pass PrintStream to security helper src/java.base/share/classes/sun/launcher/SecuritySettings.java line 93: > 91: for (String key : p.stringPropertyNames().stream().sorted().toList()) { > 92: String val = p.getProperty(key); > 93: if (val.contains(",") && val.length() > 60) { Do you want to do the same for `;`? `jceks.key.serialFilter` uses it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232926833 From peter.firmstone at zeus.net.au Sat Jun 17 10:12:23 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 17 Jun 2023 20:12:23 +1000 Subject: JDK-8280491 and JEP411 In-Reply-To: References: <97a17898-59d8-731d-6fe5-0096a0661c03@zeus.net.au> <60f4faba-21a9-07d8-a1bb-36e7605dd40d@oracle.com> Message-ID: <5626bba1-cd52-c08c-05b9-0ad04aac4843@zeus.net.au> Thanks Sean. It's a pity we're not permitted to redesign a light weight authorization mechanism from the ashes of the existing system, something that allowed the use of PrivilegedAction et al. The reality is, authorization could be so much simpler and more useful than it is today, especially if outside of privileged action's, no privileges were granted at all, it addresses problems with preservation of context over threads and executors. The reason the original designers chose to allow granting permission outside of privileged actions, was to make it compatible with existing deployments, but since SM didn't need to be enabled and often wasn't enabled by default, it probably wasn't the right choice, as it led to the viral permission problem. The remaining use case for authorization is to allow the coming together of trusted parties within one JVM, for access decisions and we could so easily make it high scaling, performant, simpler with far better tooling, but sadly, the applet use case shone so brightly people are unable to see other uses for it. OpenJDK still relies on DNS for identity decisions in SecureClassLoader, which is subject to DNS cache poisoning attacks, easily solved using RFC3986 and RFC5952 URI normalization, and doesn't it just speed up class loading so nicely. ;)?? Outside of OpenJDK, some of these things were solved over a decade ago and have been thoroughly tested and are well understood.?? The Jini development branch, inherited from Sun Microsystems had comprehensive network deployment, regression and unit tests, which significantly contributed to its understanding. -- Regards, Peter On 17/06/2023 3:33 am, Sean Mullan wrote: > See also https://bugs.openjdk.org/browse/JDK-8296244 > > --Sean > > On 6/16/23 1:48 AM, Alan Bateman wrote: >> On 16/06/2023 03:48, Peter Firmstone wrote: >>> : >>> >>> As it isn't yet clear how a Subject context will be preserved across >>> threads in future version of OpenJDK, (currently we use the >>> AccessControlContext for that), for example we capture the existing >>> context, to establish TLS connections in call back communications for >>> network event listeners. >>> >> >> It's good to think about a Subject.current/callAs re-implemented to use >> ScopedValue [1], currently in preview with JEP 446 in Java 21. >> ScopedValue allows for sharing in structured concurrency contexts. >> >> -Alan >> >> [1] >> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/ScopedValue.html >> >> [2] https://openjdk.org/jeps/446 From alanb at openjdk.org Sat Jun 17 12:56:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jun 2023 12:56:07 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Fri, 16 Jun 2023 20:32:23 GMT, Weijun Wang wrote: >> Hi, >> >> I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. >> >> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. >> >> Thanks >> >> Tony > > src/jdk.crypto.ec/share/classes/module-info.java line 36: > >> 34: @Deprecated(since="22", forRemoval = true) >> 35: module jdk.crypto.ec { >> 36: //provides java.security.Provider with sun.security.ec.SunEC; > > Just remove it. Yes, it should be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1233041891 From alanb at openjdk.org Sat Jun 17 13:13:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jun 2023 13:13:07 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino wrote: > This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. The proposed changes look okay, meaning it should be okay to have the SunEC provider in java.base. However, the motivation isn't clear as there isn't an issue with JCE providers in java.base using native code. I know there were non-technical issues with libsunec in the past but that would haven't prevent the SunEC code form being compiled into java.base. I assume the main implications of the change is that 3rd party JCE providers signed with an EC certificate can now be deployed on the module path. Another way to solve that issue is that delay verification of signed JARs until the boot layer is created - if we did that, would you still want to move the SunEC provider into java.base? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1595748679 From peter.firmstone at zeus.net.au Sun Jun 18 01:28:42 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 18 Jun 2023 11:28:42 +1000 Subject: PrivilegedAction et al and JEP411 Message-ID: Curious to know OpenJDK's plans for removal of AccessController::doPrivileged calls? PrivilegedAction shows intent, that an action about to be executed requires privileges. Can OpenJDK retain instances of PrivilegedAction and PrivilegedExceptionAction? We can find PrivilegedAction::run in stack walks to capture this intent. We can also instrument the run method, to call our own Authorization framework. https://github.com/pfirmstone/HighPerformanceSecurity/blob/main/HPS/src/main/java/au/net/zeus/auth/Authorization.java https://github.com/opensearch-project/OpenSearch/issues/1687 -- Regards, Peter From Alan.Bateman at oracle.com Sun Jun 18 08:21:50 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 18 Jun 2023 09:21:50 +0100 Subject: PrivilegedAction et al and JEP411 In-Reply-To: References: Message-ID: On 18/06/2023 02:28, Peter Firmstone wrote: > Curious to know OpenJDK's plans for removal of > AccessController::doPrivileged calls? As JEP 411 alludes, the likely next step for this one is to degrade it so that it just runs the action. This should be transparent to most code, esp. library code that uses it so the library works when the application is deployed with a security manager. Not early to say which release a change like this might be proposed for. -Alan From peter.firmstone at zeus.net.au Sun Jun 18 11:52:13 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 18 Jun 2023 21:52:13 +1000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: References: Message-ID: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> Thanks Alan, Personally, I would hope that nothing happens until after Java 21, time is precious, we'll need all the time we can get. I was hoping, that all privileged actions might be retained indefinitely, so that we may instrument them.?? Perhaps in future they may also have other uses with Subject. I only ask that we be allowed the opportunity to build a better authorization framework (we have to build one, but I'd like it to be an improvement, rather than a compromise), there have been many lessons learned from Li Gong's work.?? I think I've demonstrated what's possible with JGDMS.?? Previously, I've only been able to work around the problems in OpenJDK, as a downstream developer, but within the JDK, there is so much more opportunity.?? Beyond any doubt, concurrency was a far greater challenge than authorization ever was and look how good concurrency is today. The three design issues, fix these and maintenance is significantly reduced (I couldn't solve these as a downstream developer): 1. Privileged calls need to be short and sweet, outside of privileged calls, there should be zero privileges, this addresses viral permissions. 2. The trusted computing base is far too large, it should be limited to a small part of the Java platform. 3. Parsing of remote data required permission checks, to allow decisions to parse based on trust with the remotely authenticated subject, this could have prevented the much of the de-serialization security debacle in server side programming, similar to how Elasticsearch avoided the log2j problem. 4. Make it easy to set up and use (I was able to mostly solve this with tooling). I certainly solved the performance issues and wrote tools to generate policy files, which made life a lot easier. Personally I'd like to replace all blocks with System::getSecurityManager and permission checks, with Guard::checkGuard, as it would allow us to instrument guards too, while also allowing a level of indirection to simplify the removal of SecurityManager as a no-op. I've previously solved problems far more difficult than this. For example, RMI has problems with class resolution, the original designers tried to append codebase annotations within the marshalled streams, performing class resolution during deserialization using RMIClassLoader. https://web.archive.org/web/20060514011913/http://research.sun.com/technical-reports/2006/smli_tr-2006-149.pdf To solve this problem, instead of annotating streams with codebase annotations (a poor design), each Endpoint is assigned a ClassLoader, following authentication, the ClassLoader at each endpoint is responsible for class resolution of all deserialized classes of that stream, stream based annotations are not required.? Also separate streams are created for different concerns, even when an object is marshalled within a stream it doesn't belong to, a separate stream is created, authenticated and established with appropriate ClassLoaders at the Endpoints. RMIClassLoader was a design mistake, it wasn't needed, ClassLoader already existed for class resolution, a duplicate class resolution mechanism was never going to succeed.?? I also reimplemented a subset of Java deserialization, using constructors with input validation, it's immune to gadget attacks, it fails atomically when input validation fails, no incomplete or partially constructed objects are created, no need to create serial filters or whitelists, I looked at de-serialization whitelists circa 2010, I chose not to implement them, as it would have been brittle and cumbersome to maintain. There were many difficult technical problems that prevented Sun's success with Jini, today, every single one has been solved.?? JERI (Jini Extensible Remote Invocation) today is a far superior framework than RMI could ever hope to be, and yet, RMI is still used by Java, JERI could replace it, which would allow the extensible replacement of Java Serialization, that's hardwired into RMI.? One day I would like to see Java serialization, not as part of the base platform, but an add in module for compatibility, that few need to use. Not only did we solve technical issues with Jini, we made strides in performance, Sun had a lot of DNS calls thanks to URL equals and CodeSource implies methods, so Java was making lots of network calls, OpenJDK still does, if you're using SecureClassLoader, URLClassLoader and network URL's, performance is terrible. Instead we're using RFC3986 and RFC5952 normalization, and we're using bitshift operations for case conversion in URI, because we had hotspots with string conversion during URI normalization. We're going as fast as the hardware, network and JDK allows, we only touch URL and DNS when we need to download something.?? This is why sometimes we expose race conditions in Java's TLS implementation, we made our software as concurrent and non blocking as possible.?? We've also got global IPv6 multicast discovery, we have end to end connectivity, we've got distributed network events and distributed garbage collection, everything is authenticated, validated and operating over secure network connections, it's all easily configured and extensible. ? This isn't your publish subscribe web service model.? It turns out everything they dreamed of was possible, it just required time to sort it out. Comparatively, problems with Authorization are small and simple, easily solved. Thank you for your time and responses, I hope what I've said will be considered. -- Regards, Peter On 18/06/2023 6:21 pm, Alan Bateman wrote: > > On 18/06/2023 02:28, Peter Firmstone wrote: >> Curious to know OpenJDK's plans for removal of >> AccessController::doPrivileged calls? > > As JEP 411 alludes, the likely next step for this one is to degrade it > so that it just runs the action. This should be transparent to most > code, esp. library code that uses it so the library works when the > application is deployed with a security manager. Not early to say > which release a change like this might be proposed for. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Jun 18 12:15:41 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 18 Jun 2023 13:15:41 +0100 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> Message-ID: <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> On 18/06/2023 12:52, Peter Firmstone wrote: > > Thanks Alan, > > Personally, I would hope that nothing happens until after Java 21, > time is precious, we'll need all the time we can get. > > I was hoping, that all privileged actions might be retained > indefinitely, so that we may instrument them. > Once the SM operating mode goes away then I would expect most usages of privileged actions in the JDK can be removed. Leaving them for an "authorization layer" to instrument would be misleading. Existing usages will quickly bit rot. It would also be a tax on all future features and all ongoing maintenance. -Alan. From ascarpino at openjdk.org Sun Jun 18 20:30:20 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Sun, 18 Jun 2023 20:30:20 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Sat, 17 Jun 2023 12:53:17 GMT, Alan Bateman wrote: >> src/jdk.crypto.ec/share/classes/module-info.java line 36: >> >>> 34: @Deprecated(since="22", forRemoval = true) >>> 35: module jdk.crypto.ec { >>> 36: //provides java.security.Provider with sun.security.ec.SunEC; >> >> Just remove it. > > Yes, it should be removed. Yep ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1233372709 From peter.firmstone at zeus.net.au Sun Jun 18 22:30:48 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 19 Jun 2023 08:30:48 +1000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> Message-ID: <2ab0f21f-e3d1-9b9f-9090-54d14edd1938@zeus.net.au> Thank you for clarifying. OpenJDK advised us it was possible to implement a new Authorization layer above the JVM, but without any suitable hooks from within the JVM, it's not feasible. We will support Java until the last version we can, it's not possible for us to re-secure our software on the Java platform going forward. -- Regards, Peter On 18/06/2023 10:15 pm, Alan Bateman wrote: > On 18/06/2023 12:52, Peter Firmstone wrote: >> >> Thanks Alan, >> >> Personally, I would hope that nothing happens until after Java 21, >> time is precious, we'll need all the time we can get. >> >> I was hoping, that all privileged actions might be retained >> indefinitely, so that we may instrument them. >> > Once the SM operating mode goes away then I would expect most usages > of privileged actions in the JDK can be removed. Leaving them for an > "authorization layer" to instrument would be misleading. Existing > usages will quickly bit rot. It would also be a tax on all future > features and all ongoing maintenance. > > -Alan. From chap at anastigmatix.net Sun Jun 18 22:42:17 2023 From: chap at anastigmatix.net (chap at anastigmatix.net) Date: Sun, 18 Jun 2023 18:42:17 -0400 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> Message-ID: On 2023-06-18 08:15, Alan Bateman wrote: > Once the SM operating mode goes away then I would expect most usages of > privileged actions in the JDK can be removed. Leaving them for an > "authorization layer" to instrument would be misleading. Existing > usages will quickly bit rot. It would also be a tax on all future > features and all ongoing maintenance. Perhaps it would be more feasible to look at some lower-hanging fruit, such as making sure all file accesses go through the default filesystem implementation (once that is imposed at startup, of course), sockets can be controlled with socket factories, similarly for processes, and so on. Is the intention to have all system properties (even those that contain critical platform information) be writable as a free-for-all, or will there be some means to limit writing of those? Regards, Chapman Flack From ascarpino at openjdk.org Mon Jun 19 05:49:25 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 19 Jun 2023 05:49:25 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Sat, 17 Jun 2023 13:10:35 GMT, Alan Bateman wrote: > > This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. > > The proposed changes look okay, meaning it should be okay to have the SunEC provider in java.base. However, the motivation isn't clear as there isn't an issue with JCE providers in java.base using native code. I know there were non-technical issues with libsunec in the past but that would haven't prevent the SunEC code form being compiled into java.base. > >From what I was told, the native library was one of the reasons it was not in the base pkg before modularization and just remained so afterwards. > I assume the main implications of the change is that 3rd party JCE providers signed with an EC certificate can now be deployed on the module path. Another way to solve that issue is that delay verification of signed JARs until the boot layer is created - if we did that, would you still want to move the SunEC provider into java.base? Maybe you want it in java.base so there is an alternative to RSA in all run-time images? Just before this review went out I tried JDK-8215932. At this point, I'm unable to reproduce the original problem with EC JCE signed jars. I talked to the submitter and at this point I'm not sure if JDK-8215932 was incorrect or it was fixed elsewhere. That doesn't reduce the motivation to remove the module. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1596540890 From alanb at openjdk.org Mon Jun 19 06:19:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jun 2023 06:19:07 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Mon, 19 Jun 2023 05:46:34 GMT, Anthony Scarpino wrote: > From what I was told, the native library was one of the reasons it was not in the base pkg before modularization and just remained so afterwards. Maybe you are thinking about the size of libsunec or non-technical issues that meant it wasn't included by some distributions? There weren't an issue with deciding which providers to include to java.base. I think the motivation for having the SunEC provider in java.base now is probably TLS so there are more secure cipher suites available for those that create a small run-image with jlink and don't include all security providers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1596574579 From peter.firmstone at zeus.net.au Mon Jun 19 11:48:32 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 19 Jun 2023 21:48:32 +1000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> Message-ID: For most Java developers, and Jvm users, it means that all Java bytecodes need to be audited and trusted, to be fair OpenJDK provide flight recorder and other tools.? The drawback of this approach, is that Java allows dynamic code downloads, attackers will attempt to introduce gadgets, or injections into data consumed by Java programs, to gain control of the Jvm.? If you have sensitive data, such as certificates, or ldap passwords, well, once an attacker gains access to one jvm in the network, it provides the opportunity to gain access to sensitive data and other network resources also.? Having an authorization layer, made it more difficult for attackers to gain access to sensitive information, such as properties, especially if you were using policy files with least privilege principles. Over the last decade or so, the Java trusted platform was allowed to grow too large, and there were no permission checks on deserialization, or xml parsing, which would have prevented many such attacks, by allowing authorization decisions, based on the authentication of data sources (provided they haven't been compromised). In our software, we authenticate, then we dynamically grant permissions based on least privilege principles (and dynamically revoke them when no longer needed), we allow dynamic code downloads for dynamic services, our software is very dynamic, you can have a service wrapped with a JavaFX front end, and multiple services might be combined together for form a dynamic system, that's continually evolving, replacing and updating itself.? We can do this securely now, but without authorization, it falls apart, there are no restrictions and anyone who is authenticated will have free access to everything.? The people who think we can do these things without an authorization layer, are thinking of more traditional uses for Java, things that are static, no dynamic code, all code is audited and trusted, then deployed. But I digress and I guess it doesn't matter, there are no upcoming features in OpenJDK that would tempt me to trade off security.? Java has been good enough for a long time, I guess the biggest thing will be maintaining security and being able to continue on LTS would have been nice.? SM is still here for now, so we will be able to continue testing and reporting bugs with OpenJDK, but once SM is removed, then that's when we will be forced to stop upgrading.?? We've spent a lot of time investigating our options, this is the way it has to be.?? We've run with a SecurityManager for over two decades now, we solved performance and usability issues, it's served us well and will continue to do so for many years to come. -- Regards, Peter On 19/06/2023 8:42 am, chap at anastigmatix.net wrote: > On 2023-06-18 08:15, Alan Bateman wrote: >> Once the SM operating mode goes away then I would expect most usages >> of privileged actions in the JDK can be removed. Leaving them for an >> "authorization layer" to instrument would be misleading. Existing >> usages will quickly bit rot. It would also be a tax on all future >> features and all ongoing maintenance. > > Perhaps it would be more feasible to look at some lower-hanging > fruit, such as making sure all file accesses go through the default > filesystem implementation (once that is imposed at startup, of course), > sockets can be controlled with socket factories, similarly for > processes, and so on. > > Is the intention to have all system properties (even those that > contain critical platform information) be writable as a free-for-all, > or will there be some means to limit writing of those? > > Regards, > Chapman Flack From chap at anastigmatix.net Mon Jun 19 12:28:01 2023 From: chap at anastigmatix.net (chap at anastigmatix.net) Date: Mon, 19 Jun 2023 08:28:01 -0400 Subject: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> Message-ID: <21a72f053fcfc4b37b24da59dc242e2b@anastigmatix.net> On 2023-06-19 07:48, Peter Firmstone wrote: > Having an authorization layer, made it more difficult for attackers > to gain access to sensitive information, such as properties, especially > if you were using policy files with least privilege principles. Agreed. I hope it did not seem as if my recent questions/suggestions were directed at your efforts ... I meant them for the OpenJDK devs. It does seem that the deprecation/removal of what's being called "the security manager" does not signal a complete abandonment of all aspirations for safety in Java. There is the strong encapsulation in JPMS (unavailable when Li Gong's work was first done), and new APIs like the foreign function and memory access are being designed with an eye to restricting certain operations that could permit arbitrary behavior. The new tactic seems to be to control such operations by command-line options that permit the operations only to specific named modules. It seems that the approach being taken offers at least some rudiments with which secure APIs might be built, albeit with less configurability than the former approach (and no answer to the confused-deputy problem). My own interests are chiefly in being able to control access to operations outside the process: file and socket I/O, process manipulation, and the like. There seem to be some pieces of solutions to some of that. There is a FileSystem API that allows a default implementation to be specified on the command line at startup (and is passed a reference to the underlying implementation, so it could be used to mediate access). I seem to recall, though, a conversation indicating the JDK may still have some file accesses that don't use the newer API and so would not be mediated. While there is obviously a bootstrapping challenge--some of those accesses have to work early, before the FileSystem classes are ready-- making sure that all such remaining exceptions are fixed to go through the new API once the early startup is complete could be some low-hanging fruit for the OpenJDK devs to make sure the platform at least offers a plausible way to control those operations. It likewise seems there is a SocketFactory API that could be used to control those IPC operations. I am not aware of any current API that could be used to mediate Process or ProcessHandle operations, and that might be another piece of low-hanging fruit. I still wonder whether it is intended, after the last stages of JEP 411, that all system properties will end up being read-write. Quite a few of them now are read-only sources of important platform information, and I'm not sure what evaluation has been made of the possibilities for mischief when arbitrary modification is permitted to any of those. Of course there is a separate 'security property' API that currently puts limits of its own on modification of those properties. Will that still exist, and will there be some form of control on modification? Regards, Chapman Flack From sean.mullan at oracle.com Mon Jun 19 14:54:22 2023 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Jun 2023 10:54:22 -0400 Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: <119efe37-132c-4d9f-5b32-c7f60c302599@oracle.com> On 6/19/23 2:19 AM, Alan Bateman wrote: > On Mon, 19 Jun 2023 05:46:34 GMT, Anthony Scarpino wrote: > >> From what I was told, the native library was one of the reasons it was not in the base pkg before modularization and just remained so afterwards. > > Maybe you are thinking about the size of libsunec or non-technical issues that meant it wasn't included by some distributions? There weren't an issue with deciding which providers to include to java.base. I think the motivation for having the SunEC provider in java.base now is probably TLS so there are more secure cipher suites available for those that create a small run-image with jlink and don't include all security providers. Yes, I think the motivation is more that Elliptic Curve Cryptography is a widely used form of crypto and should be in java.base. I haven't tried this, but I think TLS 1.3 would simply not work if you just had java.base in your runtime. --Sean From ron.pressler at oracle.com Mon Jun 19 15:11:10 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 19 Jun 2023 15:11:10 +0000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> Message-ID: <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> > On 19 Jun 2023, at 12:48, Peter Firmstone wrote: > > For most Java developers, and Jvm users, it means that all Java bytecodes need to be audited and trusted, That has always been the case for *server* applications because SecurityManager has never protected against some of the most common attacks against servers. Secure servers employ OS-level defences, and that?s the approach the vast majority of secure Java servers ? and secure servers in any other language ? already take. However, note that with "integrity by default" (https://openjdk.org/jeps/8305968) Java is now making it easier than ever before to establish invariants locally and trust them globally regardless of what any other code does. This is precisely to allow more robust reasoning about important program properties, whether they?re used for correctness, security, or performance. It also establishes a more robust and convenient separation of responsibilities among the different layers ? hardware, OS, JVM ? over which invariants they each maintain. ? Ron From cslucas at openjdk.org Mon Jun 19 15:46:34 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 19 Jun 2023 15:46:34 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <-A7bd8C0q5o1WuRSeSkYYnUoApV4s9uijPmiNB2Wteo=.c5bc944c-88a3-4228-bd41-091ac6c8fb1d@github.com> On Sat, 17 Jun 2023 00:41:32 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: >> >> - Merge branch 'openjdk:master' into rematerialization-of-merges >> - Rome minor refactorings. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> Catching up with master. >> - Address PR review 6: debug format output & some refactoring. >> - Catching up with master branch. >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address PR review 6: refactoring around rematerialization & improve test cases. >> - Address PR review 5: refactor on rematerialization & add tests. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - ... and 9 more: https://git.openjdk.org/jdk/compare/57b82512...939dcffe > > Testing results (both functional and performance) are good. > > In addition, I tested with a guarantee that no `retry_no_reduce_allocation_merges()` failures are observed and there were no failures observed. > > Once you address my latest comments I'll mark the PR as reviewed. Thank you once more for the comments @iwanowww . I?ll address them asap. Can I ask what requirements are there for a product flag? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1597395112 From coffeys at openjdk.org Mon Jun 19 16:13:30 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Jun 2023 16:13:30 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v6] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey has updated the pull request incrementally with two additional commits since the last revision: - restore more informative help message - Split long properties for ; also ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/91dc41f3..8abd2fe9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=04-05 Stats: 25 lines in 1 file changed: 16 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From coffeys at openjdk.org Mon Jun 19 16:15:13 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Jun 2023 16:15:13 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v4] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 11:23:48 GMT, Alan Bateman wrote: >> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor out security code to helper class >> - Print aliases. Order Provider type/service output. > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 276: > >> 274: first = false; >> 275: } else { // following lines prefix with indents >> 276: ostream.println(TWOINDENT + s); > > I assume these changes are be reverted now. @AlanBateman - I was planning to keep this trivial change. Does it not read better ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234248828 From coffeys at openjdk.org Mon Jun 19 16:15:17 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Jun 2023 16:15:17 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 15:15:59 GMT, Roger Riggs wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass PrintStream to security helper > > src/java.base/share/classes/sun/launcher/SecuritySettings.java line 66: > >> 64: ostream.println("Unrecognized security subcommand. See \"java -X\" for help"); >> 65: ostream.println("Printing all security settings"); >> 66: printAllSecurityConfig(); > > The error message is going to get lost in the volume of settings. > Allowing bad command input reinforces learning the wrong suboption; though it may duplicate the help, I'd print the allowed options. @RogerRiggs - do you mean to print nothing in the "bad command input" scenario ? The current -XshowSettings launch behaviour prints all data if a bad value is passed to it. I was mimicking this for security subcommands. Are you suggesting to print the relevant part of the "java -X" help menu here or is restoring the message with value subcommands sufficient ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234251237 From coffeys at openjdk.org Mon Jun 19 16:15:19 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Jun 2023 16:15:19 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v5] In-Reply-To: References: Message-ID: On Sat, 17 Jun 2023 01:51:36 GMT, Weijun Wang wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass PrintStream to security helper > > src/java.base/share/classes/sun/launcher/SecuritySettings.java line 93: > >> 91: for (String key : p.stringPropertyNames().stream().sorted().toList()) { >> 92: String val = p.getProperty(key); >> 93: if (val.contains(",") && val.length() > 60) { > > Do you want to do the same for `;`? `jceks.key.serialFilter` uses it. fair point. done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234252148 From ascarpino at openjdk.org Mon Jun 19 16:44:12 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 19 Jun 2023 16:44:12 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino wrote: > Hi, > > I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. > > There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. > > Thanks > > Tony > TLS is mentioned in the CSR as a reason for the merger. With EC not being in java.base and an alternative for RSA, it could lead to slimmed down, custom images not having the best crypto algorithms available moving in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1597475346 From alanb at openjdk.org Mon Jun 19 17:05:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jun 2023 17:05:22 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v4] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 11:23:48 GMT, Alan Bateman wrote: >> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor out security code to helper class >> - Print aliases. Order Provider type/service output. > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 276: > >> 274: first = false; >> 275: } else { // following lines prefix with indents >> 276: ostream.println(TWOINDENT + s); > > I assume these changes are be reverted now. > @AlanBateman - I was planning to keep this trivial change. Does it not read better ? It would be better if the name is shortened to printSecuritySettings and it takes an indent parameter, that avoid needing to change the accessibility of INDENT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234287743 From rriggs at openjdk.org Mon Jun 19 18:25:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 19 Jun 2023 18:25:06 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v5] In-Reply-To: References: Message-ID: On Mon, 19 Jun 2023 16:11:12 GMT, Sean Coffey wrote: >> src/java.base/share/classes/sun/launcher/SecuritySettings.java line 66: >> >>> 64: ostream.println("Unrecognized security subcommand. See \"java -X\" for help"); >>> 65: ostream.println("Printing all security settings"); >>> 66: printAllSecurityConfig(); >> >> The error message is going to get lost in the volume of settings. >> Allowing bad command input reinforces learning the wrong suboption; though it may duplicate the help, I'd print the allowed options. > > @RogerRiggs - do you mean to print nothing in the "bad command input" scenario ? The current -XshowSettings launch behaviour prints all data if a bad value is passed to it. I was mimicking this for security subcommands. > > Are you suggesting to print the relevant part of the "java -X" help menu here or is restoring the message with value subcommands sufficient ? Restoring the message with value subcommands is what I would prefer. I do disagree with the original choice of printing everything if the command is wrong and would not propagate that behavior to the new command. Separately, I would consider changing the existing behavior but I suspect that would fail to achieve consensus based on compatibility concerns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234344945 From coffeys at openjdk.org Mon Jun 19 19:44:02 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Jun 2023 19:44:02 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v5] In-Reply-To: References: Message-ID: <5OSXZElHFtjr7Gg1sUxoQmC0lD8hhqbO_9ljh4_PR3I=.a0a3bbd0-2b67-4e60-9d1d-1bf38589c7b8@github.com> On Mon, 19 Jun 2023 18:21:49 GMT, Roger Riggs wrote: >> @RogerRiggs - do you mean to print nothing in the "bad command input" scenario ? The current -XshowSettings launch behaviour prints all data if a bad value is passed to it. I was mimicking this for security subcommands. >> >> Are you suggesting to print the relevant part of the "java -X" help menu here or is restoring the message with value subcommands sufficient ? > > Restoring the message with value subcommands is what I would prefer. > I do disagree with the original choice of printing everything if the command is wrong and would not propagate that behavior to the new command. > Separately, I would consider changing the existing behavior but I suspect that would fail to achieve consensus based on compatibility concerns. Fair point. Modified the code so that we don't print any security settings if a bad security subcommand value is specified. Info message instead. I'll update the CSR on that point also. Agreed on the compatibility concerns of changing the existing behaviour already present in this area. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234416659 From coffeys at openjdk.org Mon Jun 19 19:43:40 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Jun 2023 19:43:40 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v7] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Don't allow bad subcommand values for security component ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/8abd2fe9..77c9f5e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=05-06 Stats: 13 lines in 2 files changed: 0 ins; 6 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From dholmes at openjdk.org Mon Jun 19 22:32:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jun 2023 22:32:05 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 [v2] In-Reply-To: References: Message-ID: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Pick up javac and jshell changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14462/files - new: https://git.openjdk.org/jdk/pull/14462/files/3efc518f..e8ff96d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=00-01 Stats: 74 lines in 2 files changed: 71 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462 PR: https://git.openjdk.org/jdk/pull/14462 From dholmes at openjdk.org Mon Jun 19 22:32:07 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jun 2023 22:32:07 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. The javac changes have been restored so I am merging them into this PR - the only difference should be minor formatting changes. This has also now picked up the jshell changes from JDK-8308988. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1597836257 From dholmes at openjdk.org Mon Jun 19 22:34:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jun 2023 22:34:28 GMT Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. The javac update has also now pulled in JDK-8308456 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1597839767 From dholmes at openjdk.org Mon Jun 19 22:34:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Jun 2023 22:34:29 GMT Subject: Integrated: 8304478: Initial nroff manpage generation for JDK 22 In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character > - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410) > - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option > > The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22: > - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor > > Thanks. This pull request has now been integrated. Changeset: b2e86aef Author: David Holmes URL: https://git.openjdk.org/jdk/commit/b2e86aef65f4d579896b6db83aaad408b6c580d4 Stats: 129 lines in 28 files changed: 24 ins; 57 del; 48 mod 8304478: Initial nroff manpage generation for JDK 22 Reviewed-by: alanb, sspitsyn, mchung, lancea ------------- PR: https://git.openjdk.org/jdk/pull/14462 From peter.firmstone at zeus.net.au Mon Jun 19 22:44:55 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 20 Jun 2023 08:44:55 +1000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <21a72f053fcfc4b37b24da59dc242e2b@anastigmatix.net> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <21a72f053fcfc4b37b24da59dc242e2b@anastigmatix.net> Message-ID: <52df8496-adea-8e98-001e-53ba84873c73@zeus.net.au> It looks like you got their attention. :) Although we've had the assurance from OpenJDK that we could implement an authorization framework using StackWalker and agents, I've found it's not feasible, since privileged actions will be lost and there will be no support from OpenJDK, it would destroy the principle of least privilege that we currently have; permissions would have to be granted to all domains on the call stack, privileged actions currently allow those permissions to be limited, but clearly there is no way we can add this functionality back after its removal.? Defending a privilege is waste of time if it has to be granted to everyone anyway. In recent years, we've been seeing more and more permissions required by JDK implementation code, leaking out, such as the following, our code doesn't import any of these packages, but we have to grant permission to our code, because JDK implementation code isn't using privileged actions to access them, removal of privileged actions from the platform would cause an exponential explosion in the number of permissions required. ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.reflect"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.action"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.ec"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.rsa"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; One of the lessons that have come from the discussions of JEP411, is we can use agents to insert permission checks, where there are none currently, so we'll be able to further lock down the JVM, than is currently possible, this will allow us to make decisions on data parsing, such as the trust relationship with the entity that provided the data, it also means we can forget about the complexity of serialization filters, by not allowing deserialization of data from outside the JVM and limiting its use within, the best option is to disable Java serialization completely of course, but then Java Flight recorder, and other visibility tooling use RMI and Java Serialization. ? One of the things I would have liked to do, would be to reduce the size of the trusted platform, by restricting permissions for parts of OpenJDK itself, this would only be possible if we rolled our own JDK, maybe we'll do that one day, but we can't call it Java ;) We try to support multiple versions of Java, from Java 8, up to the most recent version, the only way to stay compatible will all versions is to use deprecated API, hopefully OpenJDK will backport some of their new API for developers who don't use SM. Even we have small utility command line programs, where we don't use or require authorization, where SM doesn't need to be enabled. OpenJDK dev's have worked hard to improve encapsulation, however OpenJDK has made it abundantly clear, that even if the community could maintain and improve a feature, corporate has the final say and will do whatever they want anyway, as much as I appreciate the hard work of OpenJDK developers, corporate has the last say.?? We saw this previously with JPMS v's OSGi, JPMS has no versioning capability,? OSGi's service model is superior to ServiceLoader, while everyone agrees JPMS is good for the Java platform's encapsulation, my personal preference is OSGi for its superior long term maintenance of application code, JPMS missed some of the lessons OSGi had to offer.? OSGi also has very good automated tooling, which allows us to support it, without forcing our downstream developers to adopt it.? It isn't clear how to support both OSGi and JPMS, it's not something we want to dictate to users, we want them to have the freedom to choose, so we've focused on OSGi support, without requiring users to adopt it. It's also worth mentioning, the flaw in the argument that OpenJDK is for server side programming now (a publish subscribe model, that only parses data); that all code must be audited prior to deployment, the reality is that Maven, the most commonly used build environment, pulls in a lot of transitive dependencies that needs auditing and there needs to be more tools to audit it, static analysis and known vulnerabilities are a good start, but these don't capture everything, for over a decade we also use SM for auditing, there currently aren't any tools that provide the same level of visibility, perhaps there will be in future. ? But more important than auditing alone, we can enforce what we audit. Until something better comes along, we don't have a choice and must continue using it. Currently we use Spotbugs, Owasp and our own tool to determine permissions required by software.?? Even if you aren't using SM in deployed code, it's a good auditing tool and I'd recommend it's use while it remains available, even if that means using an older JVM to audit your code. The tool can be found here, in case anyone is interested: https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java Here's are some good videos I recommend people watch, if they find Java security interesting, be warned however, ignorance is better if you value your sleep: https://www.youtube.com/watch?v=uVob-4aXbxY https://www.youtube.com/watch?v=sIuVbVbjZcw -- Regards, Peter On 19/06/2023 10:28 pm, chap at anastigmatix.net wrote: > On 2023-06-19 07:48, Peter Firmstone wrote: >> Having an authorization layer, made it more difficult for attackers >> to gain access to sensitive information, such as properties, especially >> if you were using policy files with least privilege principles. > > Agreed. I hope it did not seem as if my recent questions/suggestions were > directed at your efforts ... I meant them for the OpenJDK devs. > > It does seem that the deprecation/removal of what's being called > "the security manager" does not signal a complete abandonment of > all aspirations for safety in Java. There is the strong encapsulation > in JPMS (unavailable when Li Gong's work was first done), and new > APIs like the foreign function and memory access are being designed > with an eye to restricting certain operations that could permit > arbitrary behavior. The new tactic seems to be to control such > operations by command-line options that permit the operations > only to specific named modules. > > It seems that the approach being taken offers at least some > rudiments with which secure APIs might be built, albeit with > less configurability than the former approach (and no answer to > the confused-deputy problem). My own interests are chiefly in > being able to control access to operations outside the process: > file and socket I/O, process manipulation, and the like. > > There seem to be some pieces of solutions to some of that. > There is a FileSystem API that allows a default implementation > to be specified on the command line at startup (and is passed > a reference to the underlying implementation, so it could be > used to mediate access). I seem to recall, though, a conversation > indicating the JDK may still have some file accesses that don't > use the newer API and so would not be mediated. While there is > obviously a bootstrapping challenge--some of those accesses > have to work early, before the FileSystem classes are ready-- > making sure that all such remaining exceptions are fixed to > go through the new API once the early startup is complete > could be some low-hanging fruit for the OpenJDK devs to make > sure the platform at least offers a plausible way to control > those operations. > > It likewise seems there is a SocketFactory API that could > be used to control those IPC operations. > > I am not aware of any current API that could be used to > mediate Process or ProcessHandle operations, and that might > be another piece of low-hanging fruit. > > I still wonder whether it is intended, after the last > stages of JEP 411, that all system properties will end up > being read-write. Quite a few of them now are read-only > sources of important platform information, and I'm not sure > what evaluation has been made of the possibilities for > mischief when arbitrary modification is permitted to any > of those. > > Of course there is a separate 'security property' API that > currently puts limits of its own on modification of those > properties. Will that still exist, and will there be some > form of control on modification? > > Regards, > Chapman Flack From peter.firmstone at zeus.net.au Tue Jun 20 05:26:45 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 20 Jun 2023 15:26:45 +1000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> Message-ID: <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> Don't get me wrong, it's good that OpenJDK is improving encapsulation, it's just OpenJDK is also undoing years of tested and hardened API's, that we're expected to come up with DIY solutions for, with zero care from OpenJDK and some very bad examples of alternative solutions, not to mention a completely wrong assessment of SM based on an outdated poorly maintained implementation, with lack of use and maintenance burden (when the community is willing but not allowed to maintain it) as justification for it's removal. SecurityManager is just an authorization layer (that allows assigning different levels of trust), not a magic wand designed to solve all security problems (or sandbox, it was only a component in the sandbox, along with bytecode verification and ClassLoader visibility), to be discarded because it doesn't solve some other unrelated security flaw, it's an Non Functional Requirement, it doesn't bring in any revenue for Oracle, nor does it for many other development projects, so management have knocked it on the head, we get it. ? SM's only benefit is a little more sleep at night as a mitigating factor in avoiding becoming tomorrow's news headline.?? It might not be perfect, it could be better, it's just the best authentication layer currently available, which makes Java an enterprise ready solution.? So now Java is only marketed for server code, where all code must be trusted and audited prior to deployment, it has me wondering if OpenJDK will be removing dynamic ClassLoading in future, we don't need that for static code do we?? Don't answer that, I'm being sarcastic. We know that Oracle intends to remove authorization from the Java platform, we also know that there is nothing we can say to convince Oracle it's a bad idea, the only thing management will understand is bad consequences, such as bad news headlines.?? I understand that Oracle needs to monetize Java, they've done a great job reviving Java from where Sun was failing and it's given us many more years of Java. Elasticsearch is a good example of SecurityManager applied properly, there are many other things that Elasticsearch does, in combination with SecurityManager to secure their platform, SecurityManager is only a part of their security strategy. Security is like a chain, remove a link and the chain is broken, no one's offering to repair the chain, OpenJDK is only attempting to reassure us we don't need that link, but experience tells us the chain is broken.??? We've been working hard at implementing authorization for many years, to protect against attacks, but suddenly the threat is gone??? Yeah right, there's a bridge in Brooklyn for sale. https://spinscale.de/posts/2020-04-07-elasticsearch-securing-a-search-engine-while-maintaining-usability.html The decision has been made, it's final, the debate is over, we're just waiting for the removal notice now.?? How about someone raise a JEP to remove security manager, targeting a particular release version (preferably 22, but so be it if it's 21) so we can remove uncertainty and notify our users of the versions of Java we'll be supporting going forward??? Then it's over and we can stop worrying about it. There's a cloud outside and I've got some yelling to do. -- Regards, Peter On 20/06/2023 1:11 am, Ron Pressler wrote: > >> On 19 Jun 2023, at 12:48, Peter Firmstone wrote: >> >> For most Java developers, and Jvm users, it means that all Java bytecodes need to be audited and trusted, > That has always been the case for *server* applications because SecurityManager has never protected against some of the most common attacks against servers. Secure servers employ OS-level defences, and that?s the approach the vast majority of secure Java servers ? and secure servers in any other language ? already take. > > However, note that with "integrity by default" (https://openjdk.org/jeps/8305968) Java is now making it easier than ever before to establish invariants locally and trust them globally regardless of what any other code does. This is precisely to allow more robust reasoning about important program properties, whether they?re used for correctness, security, or performance. It also establishes a more robust and convenient separation of responsibilities among the different layers ? hardware, OS, JVM ? over which invariants they each maintain. > > ? Ron From adinn at redhat.com Tue Jun 20 09:33:40 2023 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 20 Jun 2023 10:33:40 +0100 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <52df8496-adea-8e98-001e-53ba84873c73@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <21a72f053fcfc4b37b24da59dc242e2b@anastigmatix.net> <52df8496-adea-8e98-001e-53ba84873c73@zeus.net.au> Message-ID: <8cd3a086-c0f7-fc77-d0f8-f4e2bedd2131@redhat.com> On 19/06/2023 23:44, Peter Firmstone wrote: > OpenJDK dev's have worked hard to improve encapsulation, however OpenJDK > has made it abundantly clear, that even if the community could maintain > and improve a feature, corporate has the final say and will do whatever > they want anyway, as much as I appreciate the hard work of OpenJDK > developers, corporate has the last say. Peter, just because you keep repeating this garbage it does not become any more true by that mere fact of repetition. Any OpenJDK project contributor is able to raise reasoned objections to changes if grounded in problems that they might entail and any reviewer can prohibit a change on the basis of a legitimate such objection. The truth your repeated claims belie is that no one in the project has tried to stop removal of the security manager because no reviewer has heard any argument for keeping it that outweighs the overwhelming benefits to the great majority of our users of not having it (including yours). You may not agree with that judgement but pretending to yourself that this is happening because of some corporate plot to stop the project doing the right thing is delusional. regards, Andrew Dinn ----------- From peter.firmstone at zeus.net.au Tue Jun 20 10:27:07 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 20 Jun 2023 20:27:07 +1000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <8cd3a086-c0f7-fc77-d0f8-f4e2bedd2131@redhat.com> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <21a72f053fcfc4b37b24da59dc242e2b@anastigmatix.net> <52df8496-adea-8e98-001e-53ba84873c73@zeus.net.au> <8cd3a086-c0f7-fc77-d0f8-f4e2bedd2131@redhat.com> Message-ID: I understand the economic motivations behind the decision, call that a corporate plot if you like.?? Do I have to be happy about it?? No. There is no practical way to reimplement authorization, at the application level, without some underlying support from the JVM, if I remove it from my application, there will be security holes, it will be vulnerable, therefore, I am unable to do anything about it, I have come to the conclusion it is outside of my control. Do I have the budget to rearchitect?? No.? There's no guarantee if I redesign from the ground up, that it would be any more secure anyway, the cost is sunk I have to live with it. Maybe try seeing it from my perspective, I can see it from yours.?? Of course you can continue name calling / making an assessment of my mental state if you want, but it only diminishes your character in my eyes, it doesn't insult me.? Usually when the name calling starts it means the argument has been lost.? I think you're smart enough to come up with some good technical arguments and don't need to resort to name calling.?? Maybe try cooling off and replying later, that is of course if you want to.?? I haven't taken it personally, everyone has their good and bad days. The new encapsulation improvements sound promising, if I was a young developer, without existing software to maintain, I think I would be happy about it. -- Regards, Peter On 20/06/2023 7:33 pm, Andrew Dinn wrote: > On 19/06/2023 23:44, Peter Firmstone wrote: >> OpenJDK dev's have worked hard to improve encapsulation, however >> OpenJDK has made it abundantly clear, that even if the community >> could maintain and improve a feature, corporate has the final say and >> will do whatever they want anyway, as much as I appreciate the hard >> work of OpenJDK developers, corporate has the last say. > > Peter, just because you keep repeating this garbage it does not become > any more true by that mere fact of repetition. > > Any OpenJDK project contributor is able to raise reasoned objections > to changes if grounded in problems that they might entail and any > reviewer can prohibit a change on the basis of a legitimate such > objection. > > The truth your repeated claims belie is that no one in the project has > tried to stop removal of the security manager because no reviewer has > heard any argument for keeping it that outweighs the overwhelming > benefits to the great majority of our users of not having it > (including yours). You may not agree with that judgement but > pretending to yourself that this is happening because of some > corporate plot to stop the project doing the right thing is delusional. > > regards, > > > Andrew Dinn > ----------- > From alanb at openjdk.org Tue Jun 20 10:52:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 Jun 2023 10:52:18 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino wrote: > Hi, > > I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. > > There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. > > Thanks > > Tony test/jdk/sun/security/ec/ecModuleCheck.java line 43: > 41: throw new AssertionError("jdk.crypto.ec module does not exist"); > 42: } > 43: System.out.println("jdk.crypto.ec module exists"); `@modules jdk.crypto.ec` in the test description means this test will not be selected/executed if the jdk.crypto.ec is not the run-time image. It also means the test with run with `--add-modules jdk.crypto.ec` which is not what you want. I think this is closer to what you want in this test: assertTrue(ModuleFinder.ofSystem().find("jdk.crypto.ec").isPresent()); assertFalse(ModuleLayer.boot().findModule("jdk.crypto.ec").isPresent()); This tests that the jdk.crypto.ec is observable but is not resolved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1235086798 From alanb at openjdk.org Tue Jun 20 10:58:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 Jun 2023 10:58:04 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: <119efe37-132c-4d9f-5b32-c7f60c302599@oracle.com> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> <119efe37-132c-4d9f-5b32-c7f60c302599@oracle.com> Message-ID: On Tue, 20 Jun 2023 00:57:46 GMT, Sean Mullan wrote: > > Maybe you are thinking about the size of libsunec or non-technical issues that meant it wasn't included by some distributions? There weren't an issue with deciding which providers to include to java.base. I think the motivation for having the SunEC provider in java.base now is probably TLS so there are more secure cipher suites available for those that create a small run-image with jlink and don't include all security providers. > > Yes, I think the motivation is more that Elliptic Curve Cryptography is a widely used form of crypto and should be in java.base. I haven't tried this, but I think TLS 1.3 would simply not work if you just had java.base in your runtime. I think we've converged on the right motivation. If would be good to check if there are TLS tests that could run with --limit-modules java.base, that would give confidence that the API/implementation will work when the run-time image only contains java.base. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1598552414 From ron.pressler at oracle.com Tue Jun 20 11:04:43 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 20 Jun 2023 11:04:43 +0000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> Message-ID: > On 20 Jun 2023, at 06:26, Peter Firmstone wrote: > > Don't get me wrong, it's good that OpenJDK is improving encapsulation, it's just OpenJDK is also undoing years of tested and hardened API's, You probably meant that as a bad thing, but I read it as thank you for serving your users! Our duty is to maximise the utility of the JDK. The reality of the economics of software ? in this case, the finite resources available to us ? demands that we work on features with a relatively high ratio of utility to cost and that we do not work on features with a relatively low ratio of utility to cost. And by ?utility? I mean economic utility, i.e. the total value to the ecosystem. If someone invented a galactic teleporter that no one uses, even for silly reasons ? say, they don?t like its colour ? its economic utility is zero. Let me put it bluntly and only somewhat inaccurately: Every feature added to Java over the past few years is one that we believe will serve at least a million Java developers (directly or indirectly); in fact, most features added to Java have had a million users in other languages before even being considered for addition to Java based on their technical merits (of course, the calculus changes depending on cost). > that we're expected to come up with DIY solutions for, with zero care from OpenJDK and some very bad examples of alternative solutions, The alternative solutions are the ones preferred by the vast majority of users who, I would assume, think they are superior solutions. We are simply unable to also provide a separate solution, let alone such an expensive one, for a very small minority. It would be unfair to most of our users. > not to mention a completely wrong assessment of SM based on an outdated poorly maintained implementation, with lack of use and maintenance burden (when the community is willing but not allowed to maintain it) as justification for it's removal. The community has not shown any willingness to maintain SM. As with other features, we only ever keep something to be maintained by others if they show both the commitment and the requisite ability (e.g. the JDK ports and GCs that are not maintained by Oracle). There are other companies beside Oracle that regularly contribute substantial, excellent work to OpenJDK, but to date none of them do so at the scale required for this, and we?re talking companies that pay several developers to work full time on OpenJDK. And that?s not even the worst of it. One of the things that makes SM so costly is that it?s not a separable feature but a cross-cutting concern that every JDK developer working primarily in the core-libraries area needs to worry about it when working on many changes in many areas. I don?t think you?ve begun to appreciate the enormity of this task, but even you complained that injecting doPrivileged calls in keeping up with all the changes to the JDK is too much work and that?s before studying the test suite that tests all of these places. > > SecurityManager is just an authorization layer (that allows assigning different levels of trust), not a magic wand designed to solve all security problems (or sandbox, it was only a component in the sandbox, along with bytecode verification and ClassLoader visibility), to be discarded because it doesn't solve some other unrelated security flaw, it's an Non Functional Requirement, it doesn't bring in any revenue for Oracle, nor does it for many other development projects, so management have knocked it on the head, we get it. You don?t get it, because it wasn't management. The technical leadership decided to remove SM on the advice of our security experts because they?ve judged that it?s harming our users by demanding too much effort for something that too few people want to use. If management gave us fifty more developers tomorrow to employ as we please, we still wouldn?t be able to maintain SM because our responsibility to our users would still demand that we use those resources for things that would give our users more utility. Even the most security-conscious of our users have shown a clear preference for other solutions. Your argument is that you know better than the market, but one of the world?s most popular mainstream languages cannot be led in this way. Perhaps you believe that better marketing would make the market see the light, but we have a hard enough time educating our users about features that a million others already enjoy in other languages, and an even harder time educating them about more unique features (such as strong encapsulation) that in a few short years have already paid more dividends than SM. Imagine how hard it would be to convince them of an approach that?s been abandoned after a couple of decades by the users of *both* popular platforms that adopted it. > > We know that Oracle intends to remove authorization from the Java platform, we also know that there is nothing we can say to convince Oracle it's a bad idea, the only thing management will understand is bad consequences, such as bad news headlines. I understand that Oracle needs to monetize Java If you mean that a small group of users is unable to convince us to do what they wish at the expense of most of our users, then you?re right. You say ?monetize Java?, but what that really means is that you understand ? without acknowledging ? that most people don?t find your solution to be superior and don?t want it. I fully sympathise with the frustration when the wider public doesn?t share our views as I frequently experience it myself, but you seem to blaming us for acting rationally and accepting the reality of the market we serve. > the only thing management will understand is bad consequences, such as bad news headlines. I think what they?ll understand is actual demand. Get some real traction then we can talk again. > > We've been working hard at implementing authorization for many years, to protect against attacks, but suddenly the threat is gone? Yeah right, there's a bridge in Brooklyn for sale. That is untrue, and you speak as if it?s 1996, not 2023. The threat is not gone, but the vast majority of those writing secure servers prefer other solutions to address such threats, in particular those provided at the OS level. That approach has pros and cons and we could argue on the intellectual merits of both approaches all day, but no one can deny that the economic utility of the popular approach is much higher than the one you like. Maybe you?re right and you know better than everyone else, but in that case it?s not us that you need to convince; you need to convince the market. BTW, we?re not removing authorisation from the Java platform. Most Java applications have authorisation and virtually none of them use SM. What you mean is removing independent checks from low level operations inside the JDK. > > The decision has been made, it's final, the debate is over, we're just waiting for the removal notice now. How about someone raise a JEP to remove security manager, targeting a particular release version (preferably 22, but so be it if it's 21) so we can remove uncertainty and notify our users of the versions of Java we'll be supporting going forward? Then it's over and we can stop worrying about it. We will (try to) follow the same process we follow for all changes, including more impactful ones. We don?t yet know what changes will be in JDK 22, let alone later releases. When we do, so will everyone else. I hope we?ll find ways to improve our process in the future so that it will inconvenience you less. ? Ron From adinn at redhat.com Tue Jun 20 11:08:41 2023 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 20 Jun 2023 12:08:41 +0100 Subject: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <21a72f053fcfc4b37b24da59dc242e2b@anastigmatix.net> <52df8496-adea-8e98-001e-53ba84873c73@zeus.net.au> <8cd3a086-c0f7-fc77-d0f8-f4e2bedd2131@redhat.com> Message-ID: On 20/06/2023 11:27, Peter Firmstone wrote: > I understand the economic motivations behind the decision, call that a > corporate plot if you like.?? Do I have to be happy about it?? No. Well, no, actually ... I won't call it that. Indeed, you are signally missing (or evading) my point with that comment. Which is that you raised the spectre of a corporate plot simply because you are unhappy that no one agrees with you on the importance of this feature. Contrary to what you state above this is not really anything to do with economic costs. There are costs we are actually interested in avoiding here but they are lost opportunity costs. We as a project apply our efforts to maintain and upgrade a language runtime that is simple, clear, coherent and effective. It is true that we do not have an unlimited budget to achieve that end. However, dropping the security manager is not being done to free up resources for something else. If we had more people and money we would still want to drop it. The reason for that is that it is provides a bad model for managing security concerns, which is hard to use and, hence, hardly used as a result. We have already provided better ways to address security concerns and we will continue to do so as Java evolves. regards, Andrew Dinn ----------- From vlivanov at openjdk.org Tue Jun 20 16:47:16 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 20 Jun 2023 16:47:16 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: <-A7bd8C0q5o1WuRSeSkYYnUoApV4s9uijPmiNB2Wteo=.c5bc944c-88a3-4228-bd41-091ac6c8fb1d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <-A7bd8C0q5o1WuRSeSkYYnUoApV4s9uijPmiNB2Wteo=.c5bc944c-88a3-4228-bd41-091ac6c8fb1d@github.com> Message-ID: <72OcyhmFKGyTwDy8LQ0blp5HG5dg5l9OsU5dh9osVxo=.73b3a79e-ff24-4f41-b39b-650a9036ee76@github.com> On Mon, 19 Jun 2023 15:36:15 GMT, Cesar Soares Lucas wrote: > Can I ask what requirements are there for a product flag? Product flags are treated as part of public API of the JVM. So, changes in behavior have to through CSR process. Also, a product flag has to be deprecated/obsoleted first before it can be removed which takes multiple releases to happen. Better to avoid introducing new product flags unless it is well-justified or necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1599149350 From ascarpino at openjdk.org Tue Jun 20 18:52:06 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 20 Jun 2023 18:52:06 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> <119efe37-132c-4d9f-5b32-c7f60c302599@oracle.com> Message-ID: On Tue, 20 Jun 2023 10:55:12 GMT, Alan Bateman wrote: > I think we've converged on the right motivation. If would be good to check if there are TLS tests that could run with --limit-modules java.base, that would give confidence that the API/implementation will work when the run-time image only contains java.base. I can add a case for one of the TLS tests I changed in this PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1599336912 From peter.firmstone at zeus.net.au Wed Jun 21 00:36:03 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 21 Jun 2023 10:36:03 +1000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> Message-ID: <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> On 20/06/2023 9:04 pm, Ron Pressler wrote: > >> On 20 Jun 2023, at 06:26, Peter Firmstone wrote: >> >> Don't get me wrong, it's good that OpenJDK is improving encapsulation, it's just OpenJDK is also undoing years of tested and hardened API's, > You probably meant that as a bad thing, but I read it as thank you for serving your users! No, not at all, you're welcome. ? I recognise there are different levels of trust, for different applications, you're bringing some of the benefits a well deployed SM provides, without the deployment cost to people who aren't using it now and in doing so improving their security.?? Although we don't agree on everything, there are things we agree on, and just because we disagree on some things doesn't mean I don't respect your opinions.?? I realise that SM will be removed, I'm just disappointed that we are being prevented from reimplementing a replacement authorization layer in Java, without any compromise from OpenJDK it's not possible.? We at least need to retain some kind of privilege action mechanism. That doesn't even have to be a privileged action, maybe it could be an annotation, that we can find using StackWalker. Authorization isn't a one size fits all, it's for high value assets, usually determined by risk assessment, Java was once promoted as a secure language for enterprise. If data protected isn't of high value, or is of low complexity, a solution of appropriate cost will be applied, in many cases that isn't SM, however removing SM will reduce security below an acceptable level for a percentage of developers and software projects, the number may be small, but the impact will be widespread, just look at how widely deployed ElasticSearch and OpenSearch are. ? JGDMS only gets about 30 unique cloners per fortnight, and about 50 clones, but sometimes its up around 200, I don't know how widely used it is. ? But we aren't the only projects using it for where there is no replacement possible. There are many parts of the Java API, which aren't used by all developers.?? So far, even though I still use some of the other API's which have been removed from OpenJDK, it's been pretty straightforward to replace them with something else.? SM (JAAS Authorization) isn't replaceable. I've been using and SM for 20 years, it's a lot simpler than people realise, there is a way to use it, that makes it easy, and there are ways not to, that are guaranteed to cause pain. Arguments against SM, that I've read on this list are based on bad practises, or the lack of tooling provided with the default implementation, this indicates a lack of experience in use, I know that Alan and Sean were involved during the early days with Li Gong, but I'm pretty sure they don't have much experience deploying it, feel free to prove me wrong if my assumption is incorrect. ? I'd suggest cost of maintenance also appears overestimated, this is partly due to policy, I have offered to assist with maintenance, however my offer was rejected, as this is considered part of security, I am not permitted to assist, I could submit patches to this list, but I'm not sure they'll be welcomed or accepted. When SM is used incorrectly, complexity is significantly increased, however the API's could be simplified, which would improve security and reduce complexity and maintenance. SM no more impacts developers who don't use it, than developers who don't use XML.?? The biggest maintenance burden I see on OpenJDK is Java Serialization. One dedicated full time resource should be sufficient, to review code changes to check for compliance.? It's not difficult for me to track down where permissions are leaking from Java API's, however I've assumed that as it's deprecated, there will be little interest in fixing them, is my assumption incorrect??? I think this looks like a big task, because there is a lack of tooling. SpotBugs also provides static analysis to find these problems, although now that SM is deprecated, users are requesting it to be removed from SpotBugs. Even an imperfect authorization layer is far better than no authorization layer at all. Lets discuss how it should be used, and what benefits it provides and the situations when you might want to use it.??? I only ask that people keep an open mind and for the moment, forget all the horror stories.? I realise this is academic now, and unlikely to change anything, however documenting it here might serve some historical purpose. Firstly, if used correctly, using authorization is no more difficult than using an Executor framework. Some ground rules: 1. Users create data.? The level of trust you have for the user determines the level of trust you have for their data. 2. Developers create code.?? The level of trust you have for the developers determines the level of trust you have for their code. 3. Always, always, use automated tooling for the creation and management of policy files, start with an empty policy file with no permissions. 4. Apply the principle of least privilege. 5. Developers, users and administrators will make mistakes, no one is perfect, mistakes can be fixed once identified, try to find ways to identify mistakes, for example, check generated policy files for leaking privileges, this indicates that a developer has forgotten to use a PrivilegedAction. 6. Attempts at sandboxing have always failed historically, with increasing language complexity, the more likely a sandbox will be broken through, never run untrusted code, avoid parsing data from unauthenticated sources.? For example, code can perform DOS and use up all the memory on your system to bring it down. Pictures can contain code, which can be compiled and run, data can contain SQL injection attacks.?? Always validate input, eg use pattern matching to sanitize text. 7. Some architectures are more secure than others, for example, OpenBSD on Sparc or ARM is not susceptible to Spectre, Meltdown or similar attacks. 8. SM is not a sandbox, it is an authorization layer only. There are different levels of trust, for different users and different developers.?? Note that historically, Sun or the JRE had unlimited trust for its own developers, this was a mistake.?? 100% Trusted code should be minimised to bootstrap code. Trust is from 0% to 100%.? 0% is an unauthenticated user (unauthenticated unknown data source), while 100% is your administrator, there are many levels of trust in between. Applied to developers, 0% is the unknown software your user downloaded from the internet, 100% shouldn't be given to developers, only bootstrap code.? I don't trust myself 100% either. General guidance: 1. ?If you are not authenticating users, using data integrity checksums, or encryption, then you are unlikely to benefit from SM.? SM only provides authorization, you cannot make authorization decisions without first authenticating, you have to establish trust exists, before you can determine an appropriate level of trust. 2. Privileges must be granted to both users and developers, for software to function, using tooling to determine permissions required. 3. There is no such thing as 100% trusted developers, all developers make mistakes.?? Java Serialization is my case in point, it bypassed all protections and there was no DataPermission("deserialize") to allow authorization decisions to be made based on the authenticated user who supplied the data, in many cases, due to the 100% trust given to Java de-serialization code, there were no adequate defences. 4. When the developer is given 100% trust (AllPermission, or a JRE ProtectionDomain with a null codesource), then the user will also be trusted 100%, when this code parses the user data, this is why so many gadget attacks were successful. 5. If 100% trust is given to developers, it adds unnecessary programming complexity to reduce that trust for users, that's seldom applied in practise. 6. As the developer, if you are writing code that parses data, you must add permission checks before parsing, this allows the prevention of parsing data from an untrusted user. 7. As the developer, if you are opening a network socket, accessing the file system, key stores or properties, do so using a PrivilegedAction.? Keep the privileged action short and sweet, eg if opening a socket, only do what's necessary to open the socket, and return it. 8. PrivilegedAction's can be used with AccessController, and AccessControlContext, to elevate, preserve or reduce privilege, however it is most commonly used to elevate it. 9. Don't use the Policy provider supplied with OpenJDK, it relies on DNS.?? Performance and scaling is horrible, with many synchronized locks, network and file system access, sorry I don't intend to offend, it was written a long time ago, it's basically broken. 10. Generate your policy files using a deployment environment, by working the software through all of its use cases, for each role.?? Properties should be defined, so the policy file generation tool can replace file paths and network addresses in policy files with configurable properties.?? The policy writing tool only appends missing permissions, this is to allow policy files to be built up incrementally, periodically, the entire policy file should be regenerated, for example, following a software update. 11. Permissions in policy files will determine the users who can access properties, files, network, or developers who use agents. 12. All external connections should require authentication.?? All authenticated connections should be given a thread of execution with the Subject of the authenticated user. 13. All code should either be signed, or be given a SHA256 hash or better. 14. Permissions can be used to control many Java features, such as the attach api, reflection, code downloads, network connections, but has no power to control Java serialization for example. Example of a policy grant made by the policy writing tool, notice how both the code and principal are required to have these permissions, that means the user cannot accidentally grant these privileges to untrusted code, and it means the code doesn't have permission if the user isn't authenticated, or has the wrong credentials, the tooling works this out for you, following the rules of the principle of least privilege, you don't have to figure it out yourself, tooling significantly reduces complexity and provides for embarrassment free, well organised deployment: grant codebase "file:/${qa.home}/lib/jinitests.jar", ??? principal javax.security.auth.x500.X500Principal "CN=Tester" { ??? permission net.jini.security.GrantPermission "java.lang.reflect.ReflectPermission \"newProxyInPackage.org.apache.river.mahalo\", \"\"; org.apache.river.api.io.DeSerializationPermission \"ATOMIC\"; java.lang.RuntimePermission \"accessClassInPackage.com.sun.proxy\", \"\"; org.apache.river.api.io.DeSerializationPermission \"ATOMIC\"; java.lang.RuntimePermission \"accessClassInPackage.com.sun.proxy\", \"\";"; ??? permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\"\", \"connect\";"; ??? permission java.net.URLPermission "http://${HOST}:9080/mahalo-dl-3.1.1-SNAPSHOT.jar", "GET:"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Mahalo\"", "accept"; ??? permission java.io.FilePermission "${jsk.home}${/}lib-dl${/}${mahalo-dl.jar}", "read"; ??? permission java.io.FilePermission "${jsk.home}${/}lib${/}${mahalo.jar}", "read"; ??? permission java.io.FilePermission "${qa.home}${/}harness${/}configs${/}jsse${/}mahalo${/}mahalo.config", "read"; ??? permission java.io.FilePermission "${qa.home}${/}harness${/}policy${/}defaultsecuremahalo.policy", "read"; ??? permission java.io.FilePermission "${qa.home}${/}harness${/}trust${/}mahalo.keystore", "read"; ??? permission java.io.FilePermission "${qa.home}${/}lib${/}qa1-mahalo-dl.jar", "read"; }; If we remove the ability of the Java platform to manage different levels of trust, by removing authorization, then all trust becomes 100%, for users who authenticate and developers whose code you run, you grant them 100% trust, to access anything that might be available from within the JVM.?? So now you have to set file permissions and firewall permissions to prevent the application from doing unauthorized things. I would also go as far to say that no permissions is the right approach for loom, one perform a privileged action in a Thread, maybe using a task in a thread pool, then hand it off to loom, the same goes for ForkJoin thread pools. > Our duty is to maximise the utility of the JDK. The reality of the economics of software ? in this case, the finite resources available to us ? demands that we work on features with a relatively high ratio of utility to cost and that we do not work on features with a relatively low ratio of utility to cost. And by ?utility? I mean economic utility, i.e. the total value to the ecosystem. If someone invented a galactic teleporter that no one uses, even for silly reasons ? say, they don?t like its colour ? its economic utility is zero. > > Let me put it bluntly and only somewhat inaccurately: Every feature added to Java over the past few years is one that we believe will serve at least a million Java developers (directly or indirectly); in fact, most features added to Java have had a million users in other languages before even being considered for addition to Java based on their technical merits (of course, the calculus changes depending on cost). > > >> that we're expected to come up with DIY solutions for, with zero care from OpenJDK and some very bad examples of alternative solutions, > The alternative solutions are the ones preferred by the vast majority of users who, I would assume, think they are superior solutions. We are simply unable to also provide a separate solution, let alone such an expensive one, for a very small minority. It would be unfair to most of our users. > >> not to mention a completely wrong assessment of SM based on an outdated poorly maintained implementation, with lack of use and maintenance burden (when the community is willing but not allowed to maintain it) as justification for it's removal. > > The community has not shown any willingness to maintain SM. As with other features, we only ever keep something to be maintained by others if they show both the commitment and the requisite ability (e.g. the JDK ports and GCs that are not maintained by Oracle). There are other companies beside Oracle that regularly contribute substantial, excellent work to OpenJDK, but to date none of them do so at the scale required for this, and we?re talking companies that pay several developers to work full time on OpenJDK. And that?s not even the worst of it. One of the things that makes SM so costly is that it?s not a separable feature but a cross-cutting concern that every JDK developer working primarily in the core-libraries area needs to worry about it when working on many changes in many areas. > > I don?t think you?ve begun to appreciate the enormity of this task, but even you complained that injecting doPrivileged calls in keeping up with all the changes to the JDK is too much work and that?s before studying the test suite that tests all of these places. > >> SecurityManager is just an authorization layer (that allows assigning different levels of trust), not a magic wand designed to solve all security problems (or sandbox, it was only a component in the sandbox, along with bytecode verification and ClassLoader visibility), to be discarded because it doesn't solve some other unrelated security flaw, it's an Non Functional Requirement, it doesn't bring in any revenue for Oracle, nor does it for many other development projects, so management have knocked it on the head, we get it. > You don?t get it, because it wasn't management. The technical leadership decided to remove SM on the advice of our security experts because they?ve judged that it?s harming our users by demanding too much effort for something that too few people want to use. If management gave us fifty more developers tomorrow to employ as we please, we still wouldn?t be able to maintain SM because our responsibility to our users would still demand that we use those resources for things that would give our users more utility. The message I got, was it was a maintenance expense OpenJDK doesn't want, that indicates a commercial decision. ? I have seen arguments against it documented on JEP411, but these only apply to the implementation of the Policy provider supplied with OpenJDK and lack of tooling for policy file creation.?? These arguments are in error, and I've demonstrated that previously, with fully functional high performance high scaling code. The problem is not that SecurityManager is being removed, the problem is we have come to depend on using Authorization in Java, and now we are being prevented from reimplementing anything to replace it. We can handle the stack walk, using the attach api to insert guards, but without privileged calls in OpenJDK, permissions cannot be applied using the principle of least privilege, it will be broken and not useful.?? Basically all authorization support foundations are being removed along with SecurityManager, there's nothing we can do to fix it.?? Java's no longer a platform that supports authorization. SM was just the implementation, maybe it wasn't right, and maybe the experts are right to remove it.? But maybe they're wrong too. > > Even the most security-conscious of our users have shown a clear preference for other solutions. Your argument is that you know better than the market, but one of the world?s most popular mainstream languages cannot be led in this way. Perhaps you believe that better marketing would make the market see the light, but we have a hard enough time educating our users about features that a million others already enjoy in other languages, and an even harder time educating them about more unique features (such as strong encapsulation) that in a few short years have already paid more dividends than SM. Imagine how hard it would be to convince them of an approach that?s been abandoned after a couple of decades by the users of *both* popular platforms that adopted it. > >> We know that Oracle intends to remove authorization from the Java platform, we also know that there is nothing we can say to convince Oracle it's a bad idea, the only thing management will understand is bad consequences, such as bad news headlines. I understand that Oracle needs to monetize Java > If you mean that a small group of users is unable to convince us to do what they wish at the expense of most of our users, then you?re right. You say ?monetize Java?, but what that really means is that you understand ? without acknowledging ? that most people don?t find your solution to be superior and don?t want it. I fully sympathise with the frustration when the wider public doesn?t share our views as I frequently experience it myself, but you seem to blaming us for acting rationally and accepting the reality of the market we serve. > >> the only thing management will understand is bad consequences, such as bad news headlines. > I think what they?ll understand is actual demand. Get some real traction then we can talk again. > >> We've been working hard at implementing authorization for many years, to protect against attacks, but suddenly the threat is gone? Yeah right, there's a bridge in Brooklyn for sale. > That is untrue, and you speak as if it?s 1996, not 2023. The threat is not gone, but the vast majority of those writing secure servers prefer other solutions to address such threats, in particular those provided at the OS level. That approach has pros and cons and we could argue on the intellectual merits of both approaches all day, but no one can deny that the economic utility of the popular approach is much higher than the one you like. Maybe you?re right and you know better than everyone else, but in that case it?s not us that you need to convince; you need to convince the market. Most of the market has low risk, low consequences for security breaches, that's why security is often an afterthought, or non functional requirement.?? It's the low probability, high consequence outcomes that need protection, and these are a much smaller part of the market.?? Still it will be damaging to Java's reputation when one of the high consequence outcomes is realised.?? There's going to be a lot of legacy code that isn't taking advantage of module encapsulation, something will go bang at some point. > > BTW, we?re not removing authorisation from the Java platform. Most Java applications have authorisation and virtually none of them use SM. What you mean is removing independent checks from low level operations inside the JDK. Yes, JEP 411 is removing JAAS authorization from the Java platform.? Here's a refresher if you need it: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/AcnAndAzn.html > >> The decision has been made, it's final, the debate is over, we're just waiting for the removal notice now. How about someone raise a JEP to remove security manager, targeting a particular release version (preferably 22, but so be it if it's 21) so we can remove uncertainty and notify our users of the versions of Java we'll be supporting going forward? Then it's over and we can stop worrying about it. > We will (try to) follow the same process we follow for all changes, including more impactful ones. We don?t yet know what changes will be in JDK 22, let alone later releases. When we do, so will everyone else. I hope we?ll find ways to improve our process in the future so that it will inconvenience you less. What will help will be a predictable roadmap, so we can do some planning around that. Thank you for your time, we both know SM is being removed, lets not waste any more of each others time discussing it, we just need to know which versions of Java we'll be unable to support and a timeline around that.?? Then that opens the door to assessing which language platform is best suited to our needs going forward. Thank you, respectfully, Peter. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Wed Jun 21 00:47:47 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 21 Jun 2023 10:47:47 +1000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <21a72f053fcfc4b37b24da59dc242e2b@anastigmatix.net> <52df8496-adea-8e98-001e-53ba84873c73@zeus.net.au> <8cd3a086-c0f7-fc77-d0f8-f4e2bedd2131@redhat.com> Message-ID: On 20/06/2023 9:08 pm, Andrew Dinn wrote: > We have already provided better ways to address security concerns Maybe the documentation hasn't been updated, I can't find the "better ways" to do authorization, unless it's not considered a security concern any more.? But I don't feel like arguing with you, we're just talking around in circles, lets not waste any more of each others time. https://docs.oracle.com/en/java/javase/20/security/jaas-authorization.html#GUID-80F0B546-1E95-457B-8EF7-5BB1519E20A4 From djelinski at openjdk.org Wed Jun 21 07:48:10 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 21 Jun 2023 07:48:10 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v5] In-Reply-To: References: Message-ID: On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - update > - update > - update > - update > - 8308286 Fix clang warnings in linux code Please update copyright years where they aren't at 2023 yet. I verified these changes on Ubuntu 20.04 + clang 10; they are both necessary and sufficient to make the build pass with warnings as errors. I saw one more warning: clang: warning: argument unused during compilation: '-static-libstdc++' [-Wunused-command-line-argument] in `BUILD_SYSLOOKUPLIB_link.log`, but that one does not break the build. I'm going to approve this once you fix the mentioned issues. Thanks for working on this! make/modules/java.desktop/lib/Awt2dLibraries.gmk line 235: > 233: DISABLED_WARNINGS_gcc := int-to-pointer-cast, \ > 234: DISABLED_WARNINGS_gcc_awt_Taskbar.c := parentheses, \ > 235: DISABLED_WARNINGS_clang_awt_Taskbar.c := parentheses, \ please group the disabled warnings by compiler (gcc, then clang, then clang_aix) ------------- PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1489972241 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1236510850 From ron.pressler at oracle.com Wed Jun 21 10:52:14 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 21 Jun 2023 10:52:14 +0000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> Message-ID: > On 21 Jun 2023, at 01:36, Peter Firmstone wrote: > > > I'm just disappointed that we are being prevented from reimplementing a replacement authorization layer in Java, without any compromise from OpenJDK it's not possible. We at least need to retain some kind of privilege action mechanism. That doesn't even have to be a privileged action, maybe it could be an annotation, that we can find using StackWalker. Maintaining that information is the very thing that makes the mechanism so expensive. Annotations wouldn?t make it any easier, because their placement would still have to be tested and maintained. No one is preventing you from maintaining that information yourself, and you are free to inject such annotations into the JDK to your heart?s content. If it really isn't too much work then we all win ? we don?t have to do it and test it, and you still get to have it. > If data protected isn't of high value, or is of low complexity, a solution of appropriate cost will be applied, in many cases that isn't SM, however removing SM will reduce security below an acceptable level for a percentage of developers and software projects, the number may be small, but the impact will be widespread, just look at how widely deployed ElasticSearch and OpenSearch are. That is clearly untrue because even the most security sensitive applications already prefer alternatives that they find superior. We?re not sending people over to other alternatives; people first abandoned SM in favour of alternatives and *then* we figured it?s time to remove SM when few were left using it. I believe ElasticSearch are now relying on strong encapsulation to maintain their Java-level security invariants. > Arguments against SM, that I've read on this list are based on bad practises, or the lack of tooling provided with the default implementation, this indicates a lack of experience in use, I know that Alan and Sean were involved during the early days with Li Gong, but I'm pretty sure they don't have much experience deploying it, feel free to prove me wrong if my assumption is incorrect. While we disagree ? and the ?ground state?, i.e. what?s available without SM is very different today from what it was in 1997 ? it isn?t our job to prove you wrong because even our most security-conscious users demand something else. If you?re absolutely certain that you have the answer, then it is you who have to prove us wrong by making your answer popular. > I'd suggest cost of maintenance also appears overestimated It isn?t. We have nothing to gain from removing a feature whose benefits outweigh its cost, and removing a feature is itself a rather costly process. Not to mention the negative social dynamics: the majority don?t care and don?t know what they gain, while the minority who use the feature become understandably upset. It?s unpleasant all around. So if we do it, we?re sure the cost of the feature is high. > , this is partly due to policy, I have offered to assist with maintenance, however my offer was rejected, as this is considered part of security, I am not permitted to assist, I could submit patches to this list, but I'm not sure they'll be welcomed or accepted. The resources you can contribute aren't nearly sufficient and, like I said, the problem is that maintaining the doPrivileged information is not localised but imposes a tax on *everything*. > however I've assumed that as it's deprecated, there will be little interest in fixing them, is my assumption incorrect? Actual bugs will have to be fixed until the mechanism is fully degraded, but you are generally correct. > > Lets discuss how it should be used, and what benefits it provides and the situations when you might want to use it. I only ask that people keep an open mind and for the moment, forget all the horror stories. I realise this is academic now, and unlikely to change anything, however documenting it here might serve some historical purpose. Okay, but we, .NET (the other platform that had a similar mechanism), and most security experts have lost faith in the approach and gained faith in newish OS-level protections that weren?t available when SM was introduced (and also offer protection for native code as well as better protection from some DOS attacks); no new security sensitive platform seems to take that stack-based approach, either. This means that even if we?re wrong on the technical merits, such a feature is so far from the mainstream practice that it has no room in a mainstream language. If some day it becomes mainstream again things may change. Still, here?s one thing about the technical aspect: ?Trusted? does not mean ?free of vulnerabilities? but "assumed to not be malicious.? Libraries can and do have vulnerabilities, but I think that strong encapsulation is much more effective in controlling their blast radius, and it has significant non-security-related benefits, too (not that most developers are rushing to apply strong encapsulation to their own code, but at least we?re able to encapsulate the JDK itself). By ?effective? I don?t mean ?powerful?, but rather ?provides more value on average when all aspects are considered?. With strong encapsulation you only need to check that a particular code unit that performs an operation on behalf of a user (authorised at the application operation level) doesn?t do anything problematic. Other units cannot break your unit?s invariants, so only local reasoning is required (true, the size of the unit is not as small as could be afforded by a stack-based approach, but it is still local and contained). If you?re interested in gadget attacks, I suggest you think about how many of them can be prevented by strong encapsulation alone and how many could be prevented by a combination of strong encapsulation and OS-level protections that apply to the entire process (you can throw in serialization filters, too). In other words, don?t think just about what SM could do for you, but also think about what the more popular approaches do for you, too (taking your own advice of considering how they can be best applied, not misapplied) and then consider how much effort should be put to close the *delta* between the two. Code signing is a completely separate topic; expect some developments in that area. ? Ron From mdonovan at openjdk.org Wed Jun 21 12:09:33 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 21 Jun 2023 12:09:33 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v5] In-Reply-To: References: Message-ID: > In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. > > Thanks Matthew Donovan 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 seven additional commits since the last revision: - Merge branch 'master' into socket-close-null - reverted changes in SSLEngineImpl - I missed a method that needed updating - Merge branch 'master' into socket-close-null - made handshake context lock final - using try/finally in terminateHandshakeContext and using local context variable in all places it should be - 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13742/files - new: https://git.openjdk.org/jdk/pull/13742/files/e95cef8e..ba27e19e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=03-04 Stats: 11334 lines in 452 files changed: 6644 ins; 1916 del; 2774 mod Patch: https://git.openjdk.org/jdk/pull/13742.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13742/head:pull/13742 PR: https://git.openjdk.org/jdk/pull/13742 From mdonovan at openjdk.org Wed Jun 21 12:09:33 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 21 Jun 2023 12:09:33 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v2] In-Reply-To: <2XuGMZnGZ8-4EACWi1YLy8rXEmWHwulFOK6QJkcPNrk=.80ab389c-ecf1-4597-83c1-1ff02b884124@github.com> References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> <0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com> <2XuGMZnGZ8-4EACWi1YLy8rXEmWHwulFOK6QJkcPNrk=.80ab389c-ecf1-4597-83c1-1ff02b884124@github.com> Message-ID: On Fri, 16 Jun 2023 14:58:06 GMT, Jamil Nimeh wrote: >> Yes, socket close is a headache problem for me. > > There's a bit of a history with SSLSocket closures since the new handshaker was brought into JDK11. Some of it dealt with synchronization, others with properly handling full vs. half-duplex closes. You may want to look up some of the bug history on changes surrounding the SSLSocket closures just to make sure we don't undo any fixes that were previously integrated. As Xuelei's comment indicates, this is a delicate part of the handshaker. I reverted the changes to SSLEngineImpl and looked at the history of SSLSocketImpl and TransportContext but didn't see anything that I would be undoing with this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1236889784 From mbaesken at openjdk.org Wed Jun 21 14:18:15 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 21 Jun 2023 14:18:15 GMT Subject: RFR: JDK-8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns Message-ID: In src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m there are a few JNU_CHECK_EXCEPTION macro usages that could potentially cause leaks. ------------- Commit messages: - JDK-8310549 Changes: https://git.openjdk.org/jdk/pull/14590/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14590&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310549 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14590/head:pull/14590 PR: https://git.openjdk.org/jdk/pull/14590 From weijun at openjdk.org Wed Jun 21 15:37:02 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 21 Jun 2023 15:37:02 GMT Subject: RFR: JDK-8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 14:10:20 GMT, Matthias Baesken wrote: > In src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m there are a few JNU_CHECK_EXCEPTION macro usages that could potentially cause leaks. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14590#pullrequestreview-1491089235 From mdonovan at openjdk.org Wed Jun 21 18:53:08 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 21 Jun 2023 18:53:08 GMT Subject: RFR: 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC Message-ID: <-xB1zqcVXPIUSY6gIfdmEINZnN7KeTYh8CkJfRyrTe0=.8e052bc3-25b7-4ad7-a540-42f981b98f6d@github.com> In this PR I updated the EC key size and updated the regular expressions used to parse the output of the jarsigner. In addition to updating default key sizes base on Java version, I also updated the logic for determining the default signing algorithm which is based on the version of jarsigner/java used to sign the jar file and the size of the key being used. I ran this test with JDKs 17.0.8, 20.0.2, and 21b26. ------------- Commit messages: - 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC Changes: https://git.openjdk.org/jdk/pull/14602/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14602&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292704 Stats: 58 lines in 2 files changed: 44 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14602/head:pull/14602 PR: https://git.openjdk.org/jdk/pull/14602 From tprinzing at openjdk.org Wed Jun 21 22:46:20 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 21 Jun 2023 22:46:20 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events Message-ID: The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. In the java.base module: Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. In the jdk.jfr module: jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: Passed: jdk/jfr/event/io/TestSocketChannelEvents.java Passed: jdk/jfr/event/io/TestSocketEvents.java I added a micro benchmark which measures the overhead of handling the jfr socket events. test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk ------------- Commit messages: - some changes from review. - fix copyright date - Added micro benchmark to measure socket event overhead. - Some changes from review. - remove unnecessary cast - 8308995: Update Network IO JFR events to be static mirror events Changes: https://git.openjdk.org/jdk/pull/14342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308995 Stats: 896 lines in 12 files changed: 523 ins; 367 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From alanb at openjdk.org Wed Jun 21 22:46:24 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jun 2023 22:46:24 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk src/java.base/share/classes/java/net/Socket.java line 43: > 41: import java.util.Collections; > 42: > 43: import jdk.internal.event.SocketWriteEvent; You'll probably want to clean up the imports to avoid having import of jdk.internal classes in two places. src/java.base/share/classes/java/net/Socket.java line 1109: > 1107: nbytes = read0(b, off, len); > 1108: } finally { > 1109: SocketReadEvent.checkForCommit(start, nbytes, parent.getRemoteSocketAddress(), parent.getSoTimeout()); So if read throws, this will commit a jdk.SocketReadEvent with size 0, maybe this will change later to include the exception? src/java.base/share/classes/java/net/Socket.java line 1114: > 1112: } > 1113: > 1114: private int read0(byte[] b, int off, int len) throws IOException { Can you rename this to implRead? src/java.base/share/classes/java/net/Socket.java line 1215: > 1213: return; > 1214: } > 1215: int bytesWritten = 0; Is bytesWritten needed? src/java.base/share/classes/java/net/Socket.java line 1226: > 1224: } > 1225: > 1226: public void write0(byte[] b, int off, int len) throws IOException { Can you change this to be private and rename to implWrite? src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 421: > 419: } > 420: > 421: private int read0(ByteBuffer buf) throws IOException { Can you rename this to implRead too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236731407 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237226982 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719052 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719603 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719373 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237227861 From smarks at openjdk.org Wed Jun 21 22:46:25 2023 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Jun 2023 22:46:25 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 09:46:35 GMT, Alan Bateman wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > src/java.base/share/classes/java/net/Socket.java line 1114: > >> 1112: } >> 1113: >> 1114: private int read0(byte[] b, int off, int len) throws IOException { > > Can you rename this to implRead? Are we using a convention of `implRead` or `readImpl`? Either is ok with me, but I think we had been using `readImpl` and similar elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237316630 From alanb at openjdk.org Wed Jun 21 22:46:25 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jun 2023 22:46:25 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 16:59:22 GMT, Stuart Marks wrote: > Are we using a convention of `implRead` or `readImpl`? Either is ok with me, but I think we had been using `readImpl` and similar elsewhere. This code is already using implXXX so it's just be consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237319486 From serb at openjdk.org Wed Jun 21 22:48:16 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 21 Jun 2023 22:48:16 GMT Subject: [jdk21] RFR: 8304885: Reuse stale data to improve DNS resolver resiliency Message-ID: Hi all, This pull request contains a backport of commit [bdd81b31](https://github.com/openjdk/jdk/commit/bdd81b31825a9eb6a0f0883fca56a011ac2aebf8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Sergey Bylokhov on 9 Jun 2023 and was reviewed by Michael McMahon and Daniel Fuchs. CSR is approved for JDK 21: https://bugs.openjdk.org/browse/JDK-8306653 "jdk21-enhancement-yes" label is added to the JBS. Thanks! ------------- Commit messages: - Backport bdd81b31825a9eb6a0f0883fca56a011ac2aebf8 Changes: https://git.openjdk.org/jdk21/pull/53/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=53&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304885 Stats: 516 lines in 16 files changed: 429 ins; 55 del; 32 mod Patch: https://git.openjdk.org/jdk21/pull/53.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/53/head:pull/53 PR: https://git.openjdk.org/jdk21/pull/53 From peter.firmstone at zeus.net.au Thu Jun 22 01:21:17 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 22 Jun 2023 11:21:17 +1000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> Message-ID: <9fb94c92-358b-18ba-3993-85b137233e2b@zeus.net.au> On 21/06/2023 8:52 pm, Ron Pressler wrote: > >> On 21 Jun 2023, at 01:36, Peter Firmstone wrote: >> >> >> I'm just disappointed that we are being prevented from reimplementing a replacement authorization layer in Java, without any compromise from OpenJDK it's not possible. We at least need to retain some kind of privilege action mechanism. That doesn't even have to be a privileged action, maybe it could be an annotation, that we can find using StackWalker. > Maintaining that information is the very thing that makes the mechanism so expensive. Annotations wouldn?t make it any easier, because their placement would still have to be tested and maintained. No one is preventing you from maintaining that information yourself, and you are free to inject such annotations into the JDK to your heart?s content. If it really isn't too much work then we all win ? we don?t have to do it and test it, and you still get to have it. I wish it was that simple, it's an auditors nightmare. > >> If data protected isn't of high value, or is of low complexity, a solution of appropriate cost will be applied, in many cases that isn't SM, however removing SM will reduce security below an acceptable level for a percentage of developers and software projects, the number may be small, but the impact will be widespread, just look at how widely deployed ElasticSearch and OpenSearch are. > That is clearly untrue because even the most security sensitive applications already prefer alternatives that they find superior. We?re not sending people over to other alternatives; people first abandoned SM in favour of alternatives and *then* we figured it?s time to remove SM when few were left using it. I believe ElasticSearch are now relying on strong encapsulation to maintain their Java-level security invariants. I would suggest looking into it a little further before dismissing it out of hand or making assumptions. This discussion on OpenSearch is worth a read. https://github.com/opensearch-project/OpenSearch/issues/1687 > My question is still/why/? That's why I asked at davidlago > of what actual CVEs JSM mitigated. > There's some effort to "move security into core", with that, at rmuir > @uschindler > what is your argument for not > removing JSM? > > Because currently I don't see replacements for a lot of the > functionality. Meanwhile the protection still works so why discard the > only security mechanism that you have? I think I explained above, but > to summarize for specific vulnerabilities that are of concern (e.g. > have happened before), in a world without a security manager, I think > the easiest win is to harden the systemd service, Currently it is very > weak and > insecure:https://github.com/opensearch-project/OpenSearch/blob/main/distribution/packages/src/common/systemd/opensearch.service > > These are some of the historically problematic issues that the > security manager prevents... aka the worst-of-the-worst: > > * RCE: there's some protection by seccomp etc via systemcallfilter > which disables fork/exec at OS level. So even without security > manager, there is at least basic protection from allowing someone > to execute coin miner or whatever. This piece has to remain as you > can't block fork/exec with systemd seccomp filters... But I'd > still recommend to start hardening the systemd service > with|SystemCallFilter=|to take it further (the seccomp bpf rules > will "nest" just fine). > * File/Directory traversal et al: currently the security manager is > the only thing restricting the filesystem. opensearch does not > need to be able to access files in users home directories or > anything like that. If there is a bug in the code that would allow > this, instead of accessing users private files, security manager > will deliver a SecurityException. but, alternatively, the > directories that can be read and written can be nicely restricted > with systemd service as well (stuff like|ReadWritePaths=|) > > I recommend looking at a secure systemd service as an example, and > comparing it to the current one, here is a good > one:https://github.com/archlinux/svntogit-community/blob/packages/dnscrypt-proxy/trunk/dnscrypt-proxy.service > > You may also use|systemd-analyze security opensearch.service|to track > your progress, it will suggest improvements. > >> Lets discuss how it should be used, and what benefits it provides and the situations when you might want to use it. I only ask that people keep an open mind and for the moment, forget all the horror stories. I realise this is academic now, and unlikely to change anything, however documenting it here might serve some historical purpose. > Okay, but we, .NET (the other platform that had a similar mechanism), and most security experts have lost faith in the approach and gained faith in newish OS-level protections that weren?t available when SM was introduced (and also offer protection for native code as well as better protection from some DOS attacks); no new security sensitive platform seems to take that stack-based approach, either. This means that even if we?re wrong on the technical merits, such a feature is so far from the mainstream practice that it has no room in a mainstream language. If some day it becomes mainstream again things may change. > > Still, here?s one thing about the technical aspect: ?Trusted? does not mean ?free of vulnerabilities? but "assumed to not be malicious.? Libraries can and do have vulnerabilities, but I think that strong encapsulation is much more effective in controlling their blast radius, and it has significant non-security-related benefits, too (not that most developers are rushing to apply strong encapsulation to their own code, but at least we?re able to encapsulate the JDK itself). By ?effective? I don?t mean ?powerful?, but rather ?provides more value on average when all aspects are considered?. With strong encapsulation you only need to check that a particular code unit that performs an operation on behalf of a user (authorised at the application operation level) doesn?t do anything problematic. Other units cannot break your unit?s invariants, so only local reasoning is required (true, the size of the unit is not as small as could be afforded by a stack-based approach, but it is still local and contained). If you?re interested in gadget attacks, I suggest you think about how many of them can be prevented by strong encapsulation alone and how many could be prevented by a combination of strong encapsulation and OS-level protections that apply to the entire process (you can throw in serialization filters, too). In other words, don?t think just about what SM could do for you, but also think about what the more popular approaches do for you, too (taking your own advice of considering how they can be best applied, not misapplied) and then consider how much effort should be put to close the *delta* between the two. I agree with you regarding the benefits of encapsulation. Prior to serial filters, we reimplemented Java deserialization, we used a standardised constructor signature, and we removed the ability to serialize graphs with circular references, we placed data limits on streams, cumulative limits on array sizes and required a periodical reset, we basically applied strong encapsulation with atomic failure and input validation to serialization to eliminate gadget attacks. We've got a mature implementation for managing authentication and authorization in a dynamic distributed environment.?? It's not a simple problem to solve, so the complexity likely comes from the problem domain, rather than the solution.?? I've been using it many years, and over those years, the problems have all been solved one by one, to the point where it's a well understood stable solution for our problem domain. But the reality is, there are no other existing solutions, so we are unable to migrate, we need an actual concrete implementation, promising future developments are great, but we need a clear migration path, today no such alternative technology exists.? As you pointed out .NET has removed their equivalent, so we can't migrate to .NET either.?? Like all problems, someone will come up with a better solution at some point, when they do, we'll migrate to that, until then, we have to continue using what we have. OpenJDK doesn't know the answer, and they don't want the burden of the existing solution, that's fair enough.?? We need to be honest with our users, we don't have a future migration path with Java at this time. Perhaps it will be solved like concurrency was with functional programming, another language will solve it elegantly, hey maybe Java will copy the functionality :) Anyway, we know where we stand now and that's better than thinking we had a migration option when we didn't. - Peter. > > Code signing is a completely separate topic; expect some developments in that area. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbaesken at openjdk.org Thu Jun 22 07:12:12 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 22 Jun 2023 07:12:12 GMT Subject: RFR: JDK-8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 14:10:20 GMT, Matthias Baesken wrote: > In src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m there are a few JNU_CHECK_EXCEPTION macro usages that could potentially cause leaks. Hi Weijun, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14590#issuecomment-1602118584 From mbaesken at openjdk.org Thu Jun 22 07:12:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 22 Jun 2023 07:12:13 GMT Subject: Integrated: JDK-8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 14:10:20 GMT, Matthias Baesken wrote: > In src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m there are a few JNU_CHECK_EXCEPTION macro usages that could potentially cause leaks. This pull request has now been integrated. Changeset: 7da3f199 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/7da3f1999fc5d1b9162443d97dfae7fe7b04dfc5 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/14590 From egahlin at openjdk.org Thu Jun 22 07:52:08 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 22 Jun 2023 07:52:08 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk I believe the fields SOCKET_READ and SOCKET_WRITE in the jdk.jfr.events.EventConfigurations class can be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602173783 From asemenov at openjdk.org Thu Jun 22 09:13:21 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 22 Jun 2023 09:13:21 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v6] In-Reply-To: References: Message-ID: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14033/files - new: https://git.openjdk.org/jdk/pull/14033/files/101bf062..842d33d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=04-05 Stats: 26 lines in 5 files changed: 11 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From asemenov at openjdk.org Thu Jun 22 09:13:24 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 22 Jun 2023 09:13:24 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v5] In-Reply-To: References: Message-ID: <1uzHyJeBll4YnB4uuKYWFX8e7z66iWHoYK4Ksu8T3Ic=.c2a86584-ea77-48f9-8306-368edb33d0af@github.com> On Wed, 21 Jun 2023 07:35:16 GMT, Daniel Jeli?ski wrote: >> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - update >> - update >> - update >> - update >> - 8308286 Fix clang warnings in linux code > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 235: > >> 233: DISABLED_WARNINGS_gcc := int-to-pointer-cast, \ >> 234: DISABLED_WARNINGS_gcc_awt_Taskbar.c := parentheses, \ >> 235: DISABLED_WARNINGS_clang_awt_Taskbar.c := parentheses, \ > > please group the disabled warnings by compiler (gcc, then clang, then clang_aix) Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238236415 From djelinski at openjdk.org Thu Jun 22 10:02:09 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 22 Jun 2023 10:02:09 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v6] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 09:13:21 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > update make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241: > 239: DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ > 240: DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ > 241: DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \ Suggestion: DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \ DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \ DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \ DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \ DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \ make/modules/java.desktop/lib/Awt2dLibraries.gmk line 260: > 258: DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ > 259: DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \ > 260: DISABLED_WARNINGS_clang_screencast_pipewire.c := format-nonliteral, \ move this one closer to the other clang (non-aix) suppressions ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238296391 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238297332 From alanb at openjdk.org Thu Jun 22 10:25:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Jun 2023 10:25:09 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com> On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk src/java.base/share/classes/java/net/Socket.java line 1101: > 1099: @Override > 1100: public int read(byte[] b, int off, int len) throws IOException { > 1101: if (! SocketReadEvent.enabled()) { Drop the space in "! SocketReadEvent" as it is inconsistent with the existing code. src/java.base/share/classes/jdk/internal/event/SocketReadEvent.java line 119: > 117: public static void checkForCommit(long start, long nbytes, SocketAddress remote, long timeout) { > 118: long duration = timestamp() - start; > 119: if (shouldCommit(duration)) { I think you know this, but this will need to be re-examined for SocketChannel configured non-blocking. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408: > 406: @Override > 407: public int read(ByteBuffer buf) throws IOException { > 408: if (!SocketReadEvent.enabled()) { The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does not go through SC.read/write so I think SocketAdaptor read/write will need attention, maybe a future PR as there are other code paths that aren't covered in this PR. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 416: > 414: nbytes = implRead(buf); > 415: } finally { > 416: SocketReadEvent.checkForCommit(start, nbytes, getRemoteAddress(), 0); This will need to be changed to use remoteAddress(), can't use getRemoteAddress() as it might throw. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 466: > 464: throws IOException > 465: { > 466: if (! SocketReadEvent.enabled()) { Spurious space here too, several other places. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 474: > 472: nbytes = implRead(dsts, offset, length); > 473: } finally { > 474: SocketReadEvent.checkForCommit(start, nbytes, getRemoteAddress(), 0); This has to be remoteAddress() too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238312001 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238317470 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238323035 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238318572 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238318875 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238319120 From alanb at openjdk.org Thu Jun 22 10:25:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Jun 2023 10:25:11 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: <-CBspYQOiQx_e5vmZhTtyJkmVQAyr129m3xJIlVJy3k=.f4b5bc13-35bf-4bfe-85df-a84fa8362186@github.com> On Wed, 21 Jun 2023 15:48:30 GMT, Alan Bateman wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > src/java.base/share/classes/java/net/Socket.java line 1109: > >> 1107: nbytes = read0(b, off, len); >> 1108: } finally { >> 1109: SocketReadEvent.checkForCommit(start, nbytes, parent.getRemoteSocketAddress(), parent.getSoTimeout()); > > So if read throws, this will commit a jdk.SocketReadEvent with size 0, maybe this will change later to include the exception? The other issue to think about here is where the Socket is asynchronously closed. In t hat case, implRead will throw but we'll end up with a confusing suppressed exception due to the call to getSoTimeout. I think this will have to be replaced with a call to a helper method that returns the timeout or 0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238315000 From ron.pressler at oracle.com Thu Jun 22 11:00:34 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 22 Jun 2023 11:00:34 +0000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: <9fb94c92-358b-18ba-3993-85b137233e2b@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> <9fb94c92-358b-18ba-3993-85b137233e2b@zeus.net.au> Message-ID: <33A3153A-116D-49A9-ACE0-611075447C3D@oracle.com> > On 22 Jun 2023, at 02:21, Peter Firmstone wrote: > > This discussion on OpenSearch is worth a read. https://github.com/opensearch-project/OpenSearch/issues/1687 The cross-platform API (SystemCallFilter) is something that looks like it would make for an interesting separate library. I am well aware that there are things that SM could do that OS-level protection couldn?t, but the delta is small (although it isn?t small in the other direction). That thread essentially says, ?why not have both?? That?s irrational from the perspective of prioritising investment. Even from the security perspective alone there are better gains elsewhere. ? Ron From dfuchs at openjdk.org Thu Jun 22 11:57:04 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 22 Jun 2023 11:57:04 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk The new code seems to accurately correspond to what the various `*Instrumentor` classes were doing, so that is good. I agree with Alan that potential exception that may arise when generating the event are an issue (e.g. call to getRemoteAddress() or other getter that may make a check on the socket state) - though that was already present in the original code. Maybe that could be fixed here though. In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602505386 From egahlin at openjdk.org Thu Jun 22 13:43:04 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 22 Jun 2023 13:43:04 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 11:53:59 GMT, Daniel Fuchs wrote: > The new code seems to accurately correspond to what the various `*Instrumentor` classes were doing, so that is good. I agree with Alan that potential exception that may arise when generating the event are an issue (e.g. call to getRemoteAddress() or other getter that may make a check on the socket state) - though that was already present in the original code. Maybe that could be fixed here though. > In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead? An exception event will be emitted. The event is disabled by default, but there is ongoing work on a throttling mechanism, so it can be always-on. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602659051 From erik.gahlin at oracle.com Thu Jun 22 14:35:00 2023 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 22 Jun 2023 14:35:00 +0000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> Message-ID: > I'd suggest cost of maintenance also appears overestimated It isn?t. We have nothing to gain from removing a feature whose benefits outweigh its cost The cost is very high. I've spent probably a year on the SM just for jdk.jfr module. Erik ________________________________ From: security-dev on behalf of Ron Pressler Sent: Wednesday, June 21, 2023 12:52 PM To: Peter Firmstone Cc: chap at anastigmatix.net ; security-dev at openjdk.org Subject: Re: [External] : Re: PrivilegedAction et al and JEP411 > On 21 Jun 2023, at 01:36, Peter Firmstone wrote: > > > I'm just disappointed that we are being prevented from reimplementing a replacement authorization layer in Java, without any compromise from OpenJDK it's not possible. We at least need to retain some kind of privilege action mechanism. That doesn't even have to be a privileged action, maybe it could be an annotation, that we can find using StackWalker. Maintaining that information is the very thing that makes the mechanism so expensive. Annotations wouldn?t make it any easier, because their placement would still have to be tested and maintained. No one is preventing you from maintaining that information yourself, and you are free to inject such annotations into the JDK to your heart?s content. If it really isn't too much work then we all win ? we don?t have to do it and test it, and you still get to have it. > If data protected isn't of high value, or is of low complexity, a solution of appropriate cost will be applied, in many cases that isn't SM, however removing SM will reduce security below an acceptable level for a percentage of developers and software projects, the number may be small, but the impact will be widespread, just look at how widely deployed ElasticSearch and OpenSearch are. That is clearly untrue because even the most security sensitive applications already prefer alternatives that they find superior. We?re not sending people over to other alternatives; people first abandoned SM in favour of alternatives and *then* we figured it?s time to remove SM when few were left using it. I believe ElasticSearch are now relying on strong encapsulation to maintain their Java-level security invariants. > Arguments against SM, that I've read on this list are based on bad practises, or the lack of tooling provided with the default implementation, this indicates a lack of experience in use, I know that Alan and Sean were involved during the early days with Li Gong, but I'm pretty sure they don't have much experience deploying it, feel free to prove me wrong if my assumption is incorrect. While we disagree ? and the ?ground state?, i.e. what?s available without SM is very different today from what it was in 1997 ? it isn?t our job to prove you wrong because even our most security-conscious users demand something else. If you?re absolutely certain that you have the answer, then it is you who have to prove us wrong by making your answer popular. > I'd suggest cost of maintenance also appears overestimated It isn?t. We have nothing to gain from removing a feature whose benefits outweigh its cost, and removing a feature is itself a rather costly process. Not to mention the negative social dynamics: the majority don?t care and don?t know what they gain, while the minority who use the feature become understandably upset. It?s unpleasant all around. So if we do it, we?re sure the cost of the feature is high. > , this is partly due to policy, I have offered to assist with maintenance, however my offer was rejected, as this is considered part of security, I am not permitted to assist, I could submit patches to this list, but I'm not sure they'll be welcomed or accepted. The resources you can contribute aren't nearly sufficient and, like I said, the problem is that maintaining the doPrivileged information is not localised but imposes a tax on *everything*. > however I've assumed that as it's deprecated, there will be little interest in fixing them, is my assumption incorrect? Actual bugs will have to be fixed until the mechanism is fully degraded, but you are generally correct. > > Lets discuss how it should be used, and what benefits it provides and the situations when you might want to use it. I only ask that people keep an open mind and for the moment, forget all the horror stories. I realise this is academic now, and unlikely to change anything, however documenting it here might serve some historical purpose. Okay, but we, .NET (the other platform that had a similar mechanism), and most security experts have lost faith in the approach and gained faith in newish OS-level protections that weren?t available when SM was introduced (and also offer protection for native code as well as better protection from some DOS attacks); no new security sensitive platform seems to take that stack-based approach, either. This means that even if we?re wrong on the technical merits, such a feature is so far from the mainstream practice that it has no room in a mainstream language. If some day it becomes mainstream again things may change. Still, here?s one thing about the technical aspect: ?Trusted? does not mean ?free of vulnerabilities? but "assumed to not be malicious.? Libraries can and do have vulnerabilities, but I think that strong encapsulation is much more effective in controlling their blast radius, and it has significant non-security-related benefits, too (not that most developers are rushing to apply strong encapsulation to their own code, but at least we?re able to encapsulate the JDK itself). By ?effective? I don?t mean ?powerful?, but rather ?provides more value on average when all aspects are considered?. With strong encapsulation you only need to check that a particular code unit that performs an operation on behalf of a user (authorised at the application operation level) doesn?t do anything problematic. Other units cannot break your unit?s invariants, so only local reasoning is required (true, the size of the unit is not as small as could be afforded by a stack-based approach, but it is still local and contained). If you?re interested in gadget attacks, I suggest you think about how many of them can be prevented by strong encapsulation alone and how many could be prevented by a combination of strong encapsulation and OS-level protections that apply to the entire process (you can throw in serialization filters, too). In other words, don?t think just about what SM could do for you, but also think about what the more popular approaches do for you, too (taking your own advice of considering how they can be best applied, not misapplied) and then consider how much effort should be put to close the *delta* between the two. Code signing is a completely separate topic; expect some developments in that area. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski at openjdk.org Thu Jun 22 14:43:05 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 22 Jun 2023 14:43:05 GMT Subject: [jdk21] RFR: 8304885: Reuse stale data to improve DNS resolver resiliency In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 14:50:21 GMT, Sergey Bylokhov wrote: > Hi all, > > This pull request contains a backport of commit [bdd81b31](https://github.com/openjdk/jdk/commit/bdd81b31825a9eb6a0f0883fca56a011ac2aebf8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Sergey Bylokhov on 9 Jun 2023 and was reviewed by Michael McMahon and Daniel Fuchs. > > CSR is approved for JDK 21: https://bugs.openjdk.org/browse/JDK-8306653 > "jdk21-enhancement-yes" label is added to the JBS. > > Thanks! Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/53#pullrequestreview-1493363727 From asemenov at openjdk.org Thu Jun 22 17:25:08 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 22 Jun 2023 17:25:08 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v7] In-Reply-To: References: Message-ID: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14033/files - new: https://git.openjdk.org/jdk/pull/14033/files/842d33d8..c4ca2205 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=05-06 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From asemenov at openjdk.org Thu Jun 22 17:25:10 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 22 Jun 2023 17:25:10 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v6] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 09:58:49 GMT, Daniel Jeli?ski wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 260: > >> 258: DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ >> 259: DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \ >> 260: DISABLED_WARNINGS_clang_screencast_pipewire.c := format-nonliteral, \ > > move this one closer to the other clang (non-aix) suppressions Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238824459 From rhalade at openjdk.org Thu Jun 22 17:58:05 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 22 Jun 2023 17:58:05 GMT Subject: RFR: 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC In-Reply-To: <-xB1zqcVXPIUSY6gIfdmEINZnN7KeTYh8CkJfRyrTe0=.8e052bc3-25b7-4ad7-a540-42f981b98f6d@github.com> References: <-xB1zqcVXPIUSY6gIfdmEINZnN7KeTYh8CkJfRyrTe0=.8e052bc3-25b7-4ad7-a540-42f981b98f6d@github.com> Message-ID: On Wed, 21 Jun 2023 18:46:41 GMT, Matthew Donovan wrote: > In this PR I updated the EC key size and updated the regular expressions used to parse the output of the jarsigner. In addition to updating default key sizes base on Java version, I also updated the logic for determining the default signing algorithm which is based on the version of jarsigner/java used to sign the jar file and the size of the key being used. > > I ran this test with JDKs 17.0.8, 20.0.2, and 21b26. Marked as reviewed by rhalade (Reviewer). test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 26: > 24: /* > 25: * @test > 26: * @bug 8217375 8260286 8267319 8292704 Suggestion: * @bug 8217375 8260286 8267319 since this is test only update, you don't need to add bug id here. test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 861: > 859: } > 860: > 861: Suggestion: ------------- PR Review: https://git.openjdk.org/jdk/pull/14602#pullrequestreview-1493730690 PR Review Comment: https://git.openjdk.org/jdk/pull/14602#discussion_r1238856523 PR Review Comment: https://git.openjdk.org/jdk/pull/14602#discussion_r1238857117 From mdonovan at openjdk.org Thu Jun 22 18:09:23 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 22 Jun 2023 18:09:23 GMT Subject: RFR: 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC [v2] In-Reply-To: <-xB1zqcVXPIUSY6gIfdmEINZnN7KeTYh8CkJfRyrTe0=.8e052bc3-25b7-4ad7-a540-42f981b98f6d@github.com> References: <-xB1zqcVXPIUSY6gIfdmEINZnN7KeTYh8CkJfRyrTe0=.8e052bc3-25b7-4ad7-a540-42f981b98f6d@github.com> Message-ID: > In this PR I updated the EC key size and updated the regular expressions used to parse the output of the jarsigner. In addition to updating default key sizes base on Java version, I also updated the logic for determining the default signing algorithm which is based on the version of jarsigner/java used to sign the jar file and the size of the key being used. > > I ran this test with JDKs 17.0.8, 20.0.2, and 21b26. Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision: - whitespace cleanup Co-authored-by: Rajan Halade <17793999+rhalade at users.noreply.github.com> - removed unnecessary bug it Co-authored-by: Rajan Halade <17793999+rhalade at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14602/files - new: https://git.openjdk.org/jdk/pull/14602/files/729f59c6..93b97f94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14602&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14602&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14602.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14602/head:pull/14602 PR: https://git.openjdk.org/jdk/pull/14602 From mdonovan at openjdk.org Thu Jun 22 18:46:10 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 22 Jun 2023 18:46:10 GMT Subject: Integrated: 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC In-Reply-To: <-xB1zqcVXPIUSY6gIfdmEINZnN7KeTYh8CkJfRyrTe0=.8e052bc3-25b7-4ad7-a540-42f981b98f6d@github.com> References: <-xB1zqcVXPIUSY6gIfdmEINZnN7KeTYh8CkJfRyrTe0=.8e052bc3-25b7-4ad7-a540-42f981b98f6d@github.com> Message-ID: On Wed, 21 Jun 2023 18:46:41 GMT, Matthew Donovan wrote: > In this PR I updated the EC key size and updated the regular expressions used to parse the output of the jarsigner. In addition to updating default key sizes base on Java version, I also updated the logic for determining the default signing algorithm which is based on the version of jarsigner/java used to sign the jar file and the size of the key being used. > > I ran this test with JDKs 17.0.8, 20.0.2, and 21b26. This pull request has now been integrated. Changeset: 130a9f13 Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/130a9f138759c2f8504a83a6f3a93b1f219f0a42 Stats: 56 lines in 2 files changed: 43 ins; 1 del; 12 mod 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC Reviewed-by: rhalade ------------- PR: https://git.openjdk.org/jdk/pull/14602 From duke at openjdk.org Thu Jun 22 18:52:28 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 22 Jun 2023 18:52:28 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime Message-ID: Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. ------------- Commit messages: - removed unnecessary module in test - Fixed copyright in DerValue - Fixed copyright date - Added getTime method to DerValue that calls either getUTCTime or getGeneralizedTime depending on tag value. Added test - Added single argument method to correctly encode time Changes: https://git.openjdk.org/jdk/pull/14617/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14617&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8279254 Stats: 81 lines in 4 files changed: 77 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14617.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14617/head:pull/14617 PR: https://git.openjdk.org/jdk/pull/14617 From jnimeh at openjdk.org Thu Jun 22 19:53:03 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 22 Jun 2023 19:53:03 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:45:14 GMT, Ben Perez wrote: > Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. src/java.base/share/classes/sun/security/util/DerOutputStream.java line 490: > 488: public DerOutputStream putTime(Date d) { > 489: @SuppressWarnings("deprecation") > 490: Date low = new Date(1950,1,1); Isn't this form of the `Date` constructor deprecated? Alternately you could convert 1/1/1950 into epoch time as a long and use `new Date(long)` which is not deprecated. Same for line 492. test/jdk/sun/security/util/DerOutputStream/DerTimeEncoding.java line 40: > 38: //Check that dates after 2050 use GeneralizedTime > 39: DerOutputStream out = new DerOutputStream(); > 40: Date generalizedTimeDate = new Date(2055,3,17); Same comment as above for both this line and line 50. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14617#discussion_r1238963194 PR Review Comment: https://git.openjdk.org/jdk/pull/14617#discussion_r1238964501 From duke at openjdk.org Thu Jun 22 21:21:14 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 22 Jun 2023 21:21:14 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime [v2] In-Reply-To: References: Message-ID: > Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Replaced depreciated ctor in putTime. Added getTime method to DerInputStream ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14617/files - new: https://git.openjdk.org/jdk/pull/14617/files/214f1855..bb95533d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14617&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14617&range=00-01 Stats: 10 lines in 3 files changed: 4 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14617.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14617/head:pull/14617 PR: https://git.openjdk.org/jdk/pull/14617 From peter.firmstone at zeus.net.au Thu Jun 22 22:50:11 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 23 Jun 2023 08:50:11 +1000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> Message-ID: <8519a060-5fd6-cf5e-d689-0eb52e646bd7@zeus.net.au> Thanks Erik, This is the best argument I've heard for removal so far.?? Note that I understand it will be removed, I'm not arguing to keep it, we are stuck with versions of OpenJDK that provide it, as there are no migration options, I was hoping we might be able to reimplement it, but it's not possible without some low level language support.? If someone does think of something one day, a way that allows us to implement it, without great cost to OpenJDK, I would appreciate if you would keep us in mind. > It isn?t. We have nothing to gain from removing a feature whose > benefits outweigh its cost, and removing a feature is itself a rather > costly process. Not to mention the negative social dynamics: the > majority don?t care and don?t know what they gain, while the minority > who use the feature become understandably upset. It?s unpleasant all > around. So if we do it, we?re sure the cost of the feature is high. If you are able to share, I'd be interested to learn about challenges you had with SM, if we one day have the opportunity to reimplement it, the lessons might be valuable, so we can avoid the same mistakes. To quote Thomas Sowell: "There are no solutions, only trade-off's." Since we brought up encapsulation and serialization, which has been the cause of many Java security issues, there is one performance / security trade-off that I'd like to mention. Serialization filters are lazily initialized, this is a performance optimisation (a security trade off), however if a program doesn't utilise serialization and has disabled serialization using a filter, this provides an opportunity for an attacker.? For the attack to be successful, the attacker needs to change the serialization filter properties, prior to initialization, if the attacker is successful, they will be able to disable the only security mechanism protecting de-serialization against attack. Serialization filters are an "allow list", Security Policy also uses an "allow list", it would have been possible to add a simple permission check during de-serialization, and we could have captured the classes using tooling, it would have saved a lot of work creating serial filters, but understandably, the code in OpenJDK, especially the policy provider performs poorly, so I can see why the decision was made to implement serialization filters separately, but had it had some continued love when Java 5 introduced concurrency, and more tooling had been built up around it, perhaps today it would be simpler to use and more widely adopted... The problem with "allow lists", and serialization is, it still lacks encapsulation, so the vulnerability remains, this is why authentication is important, who are we allowing??? When we boil it all down, we call it Authentication and Authorization, perhaps there will be something new that provides this functionality again one day, and maybe the lessons learned will provide a better trade off.? That's why I'd like to understand the challenges you had with SM. :) Regards, Peter. On 23/06/2023 12:35 am, Erik Gahlin wrote: > > > I'd suggest cost of maintenance also appears overestimated > > It isn?t. We have nothing to gain from removing a feature whose > benefits outweigh its cost > > > The cost is very high. I've spent probably a year on the SM just for > jdk.jfr module. > > Erik > ------------------------------------------------------------------------ > *From:* security-dev on behalf of Ron > Pressler > *Sent:* Wednesday, June 21, 2023 12:52 PM > *To:* Peter Firmstone > *Cc:* chap at anastigmatix.net ; > security-dev at openjdk.org > *Subject:* Re: [External] : Re: PrivilegedAction et al and JEP411 > > > > On 21 Jun 2023, at 01:36, Peter Firmstone > wrote: > > > > > > I'm just disappointed that we are being prevented from > reimplementing a replacement authorization layer in Java, without any > compromise from OpenJDK it's not possible.? We at least need to retain > some kind of privilege action mechanism.?? That doesn't even have to > be a privileged action, maybe it could be an annotation, that we can > find using StackWalker. > > Maintaining that information is the very thing that makes the > mechanism so expensive. Annotations wouldn?t make it any easier, > because their placement would still have to be tested and maintained. > No one is preventing you from maintaining that information yourself, > and you are free to inject such annotations into the JDK to your > heart?s content. If it really isn't too much work then we all win ? we > don?t have to do it and test it, and you still get to have it. > > > If data protected isn't of high value, or is of low complexity, a > solution of appropriate cost will be applied, in many cases that isn't > SM, however removing SM will reduce security below an acceptable level > for a percentage of developers and software projects, the number may > be small, but the impact will be widespread, just look at how widely > deployed ElasticSearch and OpenSearch are. > > That is clearly untrue because even the most security sensitive > applications already prefer alternatives that they find superior. > We?re not sending people over to other alternatives; people first > abandoned SM in favour of alternatives and *then* we figured it?s time > to remove SM when few were left using it. I believe ElasticSearch are > now relying on strong encapsulation to maintain their Java-level > security invariants. > > > > Arguments against SM, that I've read on this list are based on bad > practises, or the lack of tooling provided with the default > implementation, this indicates a lack of experience in use, I know > that Alan and Sean were involved during the early days with Li Gong, > but I'm pretty sure they don't have much experience deploying it, feel > free to prove me wrong if my assumption is incorrect. > > While we disagree ? and the ?ground state?, i.e. what?s available > without SM is very different today from what it was in 1997 ? it isn?t > our job to prove you wrong because even our most security-conscious > users demand something else. If you?re absolutely certain that you > have the answer, then it is you who have to prove us wrong by making > your answer popular. > > > I'd suggest cost of maintenance also appears overestimated > > It isn?t. We have nothing to gain from removing a feature whose > benefits outweigh its cost, and removing a feature is itself a rather > costly process. Not to mention the negative social dynamics: the > majority don?t care and don?t know what they gain, while the minority > who use the feature become understandably upset. It?s unpleasant all > around. So if we do it, we?re sure the cost of the feature is high. > > > , this is partly due to policy, I have offered to assist with > maintenance, however my offer was rejected, as this is considered part > of security, I am not permitted to assist, I could submit patches to > this list, but I'm not sure they'll be welcomed or accepted. > > The resources you can contribute aren't nearly sufficient and, like I > said, the problem is that maintaining the doPrivileged information is > not localised but imposes a tax on *everything*. > > > > however I've assumed that as it's deprecated, there will be little > interest in fixing them, is my assumption incorrect? > > Actual bugs will have to be fixed until the mechanism is fully > degraded, but you are generally correct. > > > > > Lets discuss how it should be used, and what benefits it provides > and the situations when you might want to use it.??? I only ask that > people keep an open mind and for the moment, forget all the horror > stories.? I realise this is academic now, and unlikely to change > anything, however documenting it here might serve some historical purpose. > > Okay, but we, .NET (the other platform that had a similar mechanism), > and most security experts have lost faith in the approach and gained > faith in newish OS-level protections that weren?t available when SM > was introduced (and also offer protection for native code as well as > better protection from some DOS attacks); no new security sensitive > platform seems to take that stack-based approach, either. This means > that even if we?re wrong on the technical merits, such a feature is so > far from the mainstream practice that it has no room in a mainstream > language. If some day it becomes mainstream again things may change. > > Still, here?s one thing about the technical aspect: ?Trusted? does not > mean ?free of vulnerabilities? but "assumed to not be malicious.? > Libraries can and do have vulnerabilities, but I think that strong > encapsulation is much more effective in controlling their blast > radius, and it has significant non-security-related benefits, too (not > that most developers are rushing to apply strong encapsulation to > their own code, but at least we?re able to encapsulate the JDK > itself). By ?effective? I don?t mean ?powerful?, but rather ?provides > more value on average when all aspects are considered?. With strong > encapsulation you only need to check that a particular code unit that > performs an operation on behalf of a user (authorised at the > application operation level) doesn?t do anything problematic. Other > units cannot break your unit?s invariants, so only local reasoning is > required (true, the size of the unit is not as small as could be > afforded by a stack-based approach, but it is still local and > contained). If you?re interested in gadget attacks, I suggest you > think about how many of them can be prevented by strong encapsulation > alone and how many could be prevented by a combination of strong > encapsulation and OS-level protections that apply to the entire > process (you can throw in serialization filters, too). In other words, > don?t think just about what SM could do for you, but also think about > what the more popular approaches do for you, too (taking your own > advice of considering how they can be best applied, not misapplied) > and then consider how much effort should be put to close the *delta* > between the two. > > Code signing is a completely separate topic; expect some developments > in that area. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnimeh at openjdk.org Thu Jun 22 23:03:08 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 22 Jun 2023 23:03:08 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 19:50:10 GMT, Jamil Nimeh wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Replaced depreciated ctor in putTime. Added getTime method to DerInputStream > > test/jdk/sun/security/util/DerOutputStream/DerTimeEncoding.java line 40: > >> 38: //Check that dates after 2050 use GeneralizedTime >> 39: DerOutputStream out = new DerOutputStream(); >> 40: Date generalizedTimeDate = new Date(2055,3,17); > > Same comment as above for both this line and line 50. Don't forget to change these to use the long-based `Date` constructor, also in milliseconds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14617#discussion_r1239108332 From jnimeh at openjdk.org Thu Jun 22 23:03:05 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 22 Jun 2023 23:03:05 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 21:21:14 GMT, Ben Perez wrote: >> Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Replaced depreciated ctor in putTime. Added getTime method to DerInputStream src/java.base/share/classes/sun/security/util/DerOutputStream.java line 490: > 488: public DerOutputStream putTime(Date d) { > 489: Date low = new Date(-631152000L); // Dates before 1/1/1950 > 490: Date high = new Date(2524607999L); // Dates after 12/31/2049 These two values should be in milliseconds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14617#discussion_r1239107752 From duke at openjdk.org Thu Jun 22 23:22:14 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 22 Jun 2023 23:22:14 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime [v3] In-Reply-To: References: Message-ID: > Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. Ben Perez has updated the pull request incrementally with two additional commits since the last revision: - Fixed epoch literals to be in milliseconds - Updated copyright in DerInputStream ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14617/files - new: https://git.openjdk.org/jdk/pull/14617/files/bb95533d..fad36da0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14617&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14617&range=01-02 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14617.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14617/head:pull/14617 PR: https://git.openjdk.org/jdk/pull/14617 From ron.pressler at oracle.com Fri Jun 23 01:06:02 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 23 Jun 2023 01:06:02 +0000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: <8519a060-5fd6-cf5e-d689-0eb52e646bd7@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> <8519a060-5fd6-cf5e-d689-0eb52e646bd7@zeus.net.au> Message-ID: <3CEC3648-B1E9-4A62-9179-BCC3B6082AAB@oracle.com> > On 22 Jun 2023, at 23:50, Peter Firmstone wrote: > > > If you are able to share, I'd be interested to learn about challenges you had with SM, if we one day have the opportunity to reimplement it, the lessons might be valuable, so we can avoid the same mistakes. Much of the effort has to do with maintaining the doPrivileged calls in the right places, which needs to be done across the board, and testing all those locations with and without an installed SM. Let me just be clear that even though it?s the cost that made SM harmful and justified the effort involved in removing it, we believe that the stack-based approach is fundamentally flawed for an ecosystem where deep and wide dependency hierarchies are common and configurations must be tailored for a specific architecture and dependency set rather than in a black box fashion. We would advocate for simpler designs that have shown greater effectiveness. > > Serialization filters are lazily initialized, this is a performance optimisation (a security trade off), however if a program doesn't utilise serialization and has disabled serialization using a filter, this provides an opportunity for an attacker. For the attack to be successful, the attacker needs to change the serialization filter properties, prior to initialization, if the attacker is successful, they will be able to disable the only security mechanism protecting de-serialization against attack. I?m not sure that?s right. Briefly looking at the code, it seems that if you set jdk.serialFilter on the command line, you cannot set it again from the program (you can set the property, but it looks to me like the new value will be ignored). But I?m not familiar with the implementation at all and I could be wrong. In any event, that?s an unrelated topic. ? Ron From ron.pressler at oracle.com Fri Jun 23 01:06:03 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 23 Jun 2023 01:06:03 +0000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: <8519a060-5fd6-cf5e-d689-0eb52e646bd7@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> <8519a060-5fd6-cf5e-d689-0eb52e646bd7@zeus.net.au> Message-ID: <3CEC3648-B1E9-4A62-9179-BCC3B6082AAB@oracle.com> > On 22 Jun 2023, at 23:50, Peter Firmstone wrote: > > > If you are able to share, I'd be interested to learn about challenges you had with SM, if we one day have the opportunity to reimplement it, the lessons might be valuable, so we can avoid the same mistakes. Much of the effort has to do with maintaining the doPrivileged calls in the right places, which needs to be done across the board, and testing all those locations with and without an installed SM. Let me just be clear that even though it?s the cost that made SM harmful and justified the effort involved in removing it, we believe that the stack-based approach is fundamentally flawed for an ecosystem where deep and wide dependency hierarchies are common and configurations must be tailored for a specific architecture and dependency set rather than in a black box fashion. We would advocate for simpler designs that have shown greater effectiveness. > > Serialization filters are lazily initialized, this is a performance optimisation (a security trade off), however if a program doesn't utilise serialization and has disabled serialization using a filter, this provides an opportunity for an attacker. For the attack to be successful, the attacker needs to change the serialization filter properties, prior to initialization, if the attacker is successful, they will be able to disable the only security mechanism protecting de-serialization against attack. I?m not sure that?s right. Briefly looking at the code, it seems that if you set jdk.serialFilter on the command line, you cannot set it again from the program (you can set the property, but it looks to me like the new value will be ignored). But I?m not familiar with the implementation at all and I could be wrong. In any event, that?s an unrelated topic. ? Ron From djelinski at openjdk.org Fri Jun 23 06:22:06 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 23 Jun 2023 06:22:06 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v6] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 09:58:19 GMT, Daniel Jeli?ski wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241: > >> 239: DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ >> 240: DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ >> 241: DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \ > > Suggestion: > > DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \ > DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \ > DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \ > DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \ > DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ > DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ > DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \ Please remove the extra spaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1239364317 From peter.firmstone at zeus.net.au Fri Jun 23 07:16:54 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 23 Jun 2023 17:16:54 +1000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: <3CEC3648-B1E9-4A62-9179-BCC3B6082AAB@oracle.com> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> <8519a060-5fd6-cf5e-d689-0eb52e646bd7@zeus.net.au> <3CEC3648-B1E9-4A62-9179-BCC3B6082AAB@oracle.com> Message-ID: <206dc97d-c01b-508d-4390-b4f2990a85a7@zeus.net.au> On 23/06/2023 11:06 am, Ron Pressler wrote: > >> On 22 Jun 2023, at 23:50, Peter Firmstone wrote: >> >> >> If you are able to share, I'd be interested to learn about challenges you had with SM, if we one day have the opportunity to reimplement it, the lessons might be valuable, so we can avoid the same mistakes. > Much of the effort has to do with maintaining the doPrivileged calls in the right places, which needs to be done across the board, and testing all those locations with and without an installed SM. Of course, the very thing I was requesting to be preserved is the problem. It must be an incredible amount of work without tooling, I can't begin to imagine how much time is wasted hand editing policy files. We have to update all our test policy files for every release of Java. For example, lets say you needed to write a test that? confirmed a SecurityException is thrown, first we would run the tests to generate the policy files, this would add all required permissions to all domains on the stack for privileges to be granted, which causes the test to fail, then we remove the relevant permissions from the test domain code, and voila, the test passes. > > Let me just be clear that even though it?s the cost that made SM harmful and justified the effort involved in removing it, we believe that the stack-based approach is fundamentally flawed for an ecosystem where deep and wide dependency hierarchies are common and configurations must be tailored for a specific architecture and dependency set rather than in a black box fashion. We would advocate for simpler designs that have shown greater effectiveness. Ah yes, black box = encapsulation. So we have a very dynamic environment, Java's standard static policy provider is no good for our application, we would have SecurityExceptions all the time and you'd be forever editing policy files, so we have dynamically granted permissions on top of static permissions for policy.?? We took some inspiration from OSGi, and annotated jar files with their required permissions, these are remote micro service proxy's which are dynamically downloaded, each with their own ProtectionDomain, which is related to service identity, based on the authenticating service and it's CodeSource, it also has its own namespace, separate from other services with identical CodeSource's. Example of required permissions included in a jar file: https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/services/reggie/reggie-dl/src/main/resources/META-INF/PERMISSIONS.LIST Users are given a list of Permission's they are allowed to grant (in static policy files), called GrantPermission's.? Users and services authenticate each other, and users can dynamically grant Permission's to Service proxy's following authentication, the permissions required are declared, so it's kinda obvious, the Service's back end server runs threads with the authenticated users Subject, so we're not just using POLP on one jvm, we are distributed across many jvm's on different OS's or architectures.?? When the local service proxy is no longer in use, dynamically granted permissions become weakly reachable and are garbage collected, so they don't hang around any longer than needed.?? This is equivalent to you manually editing your policy files multiple times daily. There are also other permissions which are granted during the authentication process, eg to allow opening a socket for authentication, (typically using Certificates over TLS, but Kerberos is also possible), during the service lookup process, the service provides a URI list of resources, required for our RFC3986URIClassLoader, which is provisioned following service authentication, DownloadPermission (incorrectly named, should be DynamicClassLoadPermission) is dynamically granted, prior to any class files being dynamically class loaded.?? Any CodeSource certificates are transmitted with the URI list during authentication, so they don't need to be known in advance, alternatively we can also use SHA256 or SHA512 hash's to verify downloaded jar files, these policies are generated dynamically on the fly and only remain in memory for the period they apply. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredClassProvider.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/loader/ProxyCodebaseSpi.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java In our implementation, Permissions aren't stored in PermissionCollection instances, PermissionCollection instances are created on demand and are thread confined for high scalability, to avoid synchronization between threads, if there are many domains on a call stack, permission checks are sent as executor tasks, and executed concurrently, the first domain on the stack to fail a permission check throws SecurityException, and is returned to the permission check call, waiting permission check tasks from the same stack walk are cancelled, they're only all executed when a permission check passes, then the result of the permission check for that context is weakly cached, so we don't have to repeatedly check it.?? We also use Comparator's to arrange permissions in the most efficient order for checking, to improve performance, also since we generate our policy files, they contain equal matches for permission's, which often avoids slow implies checks that occur within PermissionCollection's. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java Honestly, it doesn't matter if we have 100's or even 1000's of ProtectionDomain's on a stack during permission checks, we could have 100's of services participate in a transaction, as I mentioned the checks go to executors and get processed concurrently and dynamic policy is held temporarily in memory only.?? Security is generally less than 3% of our system load. Horribly antiquated implementations included in OpenJDK are based on late 1990's design philosophy, they're not even deployable in our environment, damn!? It blocks on DNS network calls? ? I mean you can't compare a DNS network call performance wise with bitshift operations in RFC3986 URI normalization, or dynamic policy, with manual editing of policy files, there is no comparison, maybe you could compare it to an old man on a bicycle racing a top fueller at the drags, poor old bugger is gonna be at the line covered in rubber when the top fueller launches. Everything runs with only the permissions required and no more under least privilege principles. Anyway, it's been nice to think that what we achieved, was thought impossible.?? It's also worth mentioning we know of users who are using this with OSGi, and have many more domains than typically used, due to OSGi's fine grained package level modularity. Maybe it's our fault, for not widely promoting it, we just never expected JEP411, it came out of left field, we expected a core feature of Java would always be there and we were wrong. When someone comes up with a simpler design, I'm all up for the effectiveness challenge, I'm pretty sure that whatever it is, we'll blow it away both on performance and effectiveness, we've had years to perfect it, but I would also happily be proven wrong and challenge OpenJDK to implement something that does. Just be aware, that what you think you know, yours and your experts assumptions are based on theirs and your experiences with OpenJDK's implementation, that our experiences are worlds apart and are not the same.?? The leg of your pants getting caught in your bicycle chain as you launch your bicycle off the line is not the same as tuning a top fueller.?? Yes, I agree your bicycle is a piece of crap and you should get rid of it, it's just a shame you're removing the track too, since you determined that drag racing is fundamentally flawed based on your understanding of bicycles, were not going to be able to race top fueller's there now either, we need to find somewhere else to race. I'm sorry that we didn't come to your aid a decade ago, I can only imagine all the time wasted manually editing policy files in test cases, time we could have saved you. Anyway, it's time to go, I've said my piece, you all have work to do and so do I, the code's available for anyone who is interested, feel free to ask questions. One final word, I would like to thank Alan for his directness and honesty. Peter. > >> Serialization filters are lazily initialized, this is a performance optimisation (a security trade off), however if a program doesn't utilise serialization and has disabled serialization using a filter, this provides an opportunity for an attacker. For the attack to be successful, the attacker needs to change the serialization filter properties, prior to initialization, if the attacker is successful, they will be able to disable the only security mechanism protecting de-serialization against attack. > I?m not sure that?s right. Briefly looking at the code, it seems that if you set jdk.serialFilter on the command line, you cannot set it again from the program (you can set the property, but it looks to me like the new value will be ignored). But I?m not familiar with the implementation at all and I could be wrong. In any event, that?s an unrelated topic. ? > > ? Ron > From jnimeh at openjdk.org Fri Jun 23 07:42:10 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 23 Jun 2023 07:42:10 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 23:22:14 GMT, Ben Perez wrote: >> Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. > > Ben Perez has updated the pull request incrementally with two additional commits since the last revision: > > - Fixed epoch literals to be in milliseconds > - Updated copyright in DerInputStream src/java.base/share/classes/sun/security/util/DerOutputStream.java line 490: > 488: public DerOutputStream putTime(Date d) { > 489: Date low = new Date(-631152000000L); // Dates before 1/1/1950 > 490: Date high = new Date(2524607999000L); // Dates after 12/31/2049 Could these be `private static final` since they are constants? It would avoid the extra constructor calls each time this method is called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14617#discussion_r1239478167 From asemenov at openjdk.org Fri Jun 23 08:03:45 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Fri, 23 Jun 2023 08:03:45 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v8] In-Reply-To: References: Message-ID: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14033/files - new: https://git.openjdk.org/jdk/pull/14033/files/c4ca2205..92f629f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=06-07 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From asemenov at openjdk.org Fri Jun 23 08:09:05 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Fri, 23 Jun 2023 08:09:05 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v6] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 06:19:31 GMT, Daniel Jeli?ski wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241: >> >>> 239: DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ >>> 240: DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ >>> 241: DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \ >> >> Suggestion: >> >> DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \ >> DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \ >> DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \ >> DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \ >> DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \ >> DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ >> DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \ > > Please remove the extra spaces. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1239506015 From djelinski at openjdk.org Fri Jun 23 08:27:04 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 23 Jun 2023 08:27:04 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v8] In-Reply-To: References: Message-ID: <6Ii3MX8vMTxkr1M6OSPRK1MC3Mird6O_jeC6topuMdU=.e954d902-8b57-40bf-8fd9-9d88b82cd969@github.com> On Fri, 23 Jun 2023 08:03:45 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > update LGTM ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1494691850 From michaelm at openjdk.org Fri Jun 23 09:47:07 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 23 Jun 2023 09:47:07 GMT Subject: [jdk21] RFR: 8304885: Reuse stale data to improve DNS resolver resiliency In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 14:50:21 GMT, Sergey Bylokhov wrote: > Hi all, > > This pull request contains a backport of commit [bdd81b31](https://github.com/openjdk/jdk/commit/bdd81b31825a9eb6a0f0883fca56a011ac2aebf8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Sergey Bylokhov on 9 Jun 2023 and was reviewed by Michael McMahon and Daniel Fuchs. > > CSR is approved for JDK 21: https://bugs.openjdk.org/browse/JDK-8306653 > "jdk21-enhancement-yes" label is added to the JBS. > > Thanks! Marked as reviewed by michaelm (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/53#pullrequestreview-1494823853 From ron.pressler at oracle.com Fri Jun 23 10:10:55 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 23 Jun 2023 10:10:55 +0000 Subject: [External] : Re: PrivilegedAction et al and JEP411 In-Reply-To: <206dc97d-c01b-508d-4390-b4f2990a85a7@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <581A8F48-2C1B-436A-BD3E-311FF425CABF@oracle.com> <4e03ef19-da56-0595-ee2b-e945627318b5@zeus.net.au> <1a20cc98-b09e-ae49-2a56-ceb9b8b66468@zeus.net.au> <8519a060-5fd6-cf5e-d689-0eb52e646bd7@zeus.net.au> <3CEC3648-B1E9-4A62-9179-BCC3B6082AAB@oracle.com> <206dc97d-c01b-508d-4390-b4f2990a85a7@zeus.net.au> Message-ID: <22C8AF15-359C-46DA-A8B1-76BAC5A51782@oracle.com> > On 23 Jun 2023, at 08:16, Peter Firmstone wrote: > > > When someone comes up with a simpler design, I'm all up for the effectiveness challenge, I'm pretty sure that whatever it is, we'll blow it away both on performance and effectiveness, we've had years to perfect it, but I would also happily be proven wrong and challenge OpenJDK to implement something that does. The simpler design I was referring to is performing the low-level access checks in the OS (sometimes in cooperation with the hardware), not the JDK, and, more importantly, having a policy that treats the entire application as a black box with no regard to its composition and can even be shared among different applications, even those written in different languages. The first part is the same design chosen by all languages/platforms that allow the use of native code, and the second part is the same design chosen by pretty much every platform/language, certainly mainstream ones. ? Ron From serb at openjdk.org Fri Jun 23 11:40:16 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 23 Jun 2023 11:40:16 GMT Subject: [jdk21] Integrated: 8304885: Reuse stale data to improve DNS resolver resiliency In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 14:50:21 GMT, Sergey Bylokhov wrote: > Hi all, > > This pull request contains a backport of commit [bdd81b31](https://github.com/openjdk/jdk/commit/bdd81b31825a9eb6a0f0883fca56a011ac2aebf8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Sergey Bylokhov on 9 Jun 2023 and was reviewed by Michael McMahon and Daniel Fuchs. > > CSR is approved for JDK 21: https://bugs.openjdk.org/browse/JDK-8306653 > "jdk21-enhancement-yes" label is added to the JBS. > > Thanks! This pull request has now been integrated. Changeset: 8b127262 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk21/commit/8b127262a3dff9c4420945e902f6a688f8d05e2e Stats: 516 lines in 16 files changed: 429 ins; 55 del; 32 mod 8304885: Reuse stale data to improve DNS resolver resiliency Reviewed-by: djelinski, michaelm Backport-of: bdd81b31825a9eb6a0f0883fca56a011ac2aebf8 ------------- PR: https://git.openjdk.org/jdk21/pull/53 From mbaesken at openjdk.org Fri Jun 23 12:21:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 23 Jun 2023 12:21:02 GMT Subject: RFR: 8309740: Expand timeout windows for tests in JDK-8179502 In-Reply-To: References: Message-ID: <0EvqOlJkodD9VrpupWODRkGOQsVoNEfIRzE3IonOCzI=.8964a4f0-0963-40d5-b852-a92bf1da7619@github.com> On Fri, 16 Jun 2023 18:19:45 GMT, Jamil Nimeh wrote: > This PR is for tests that were modified/added in JDK-8179502. The timeout windows for those tests were a little too short on some test systems, especially when the system is under heavy load. After a few iterations trying out various longer time windows I have a set that should not run into issues. LGTM ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14526#pullrequestreview-1495034836 From jnimeh at openjdk.org Fri Jun 23 14:55:13 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 23 Jun 2023 14:55:13 GMT Subject: Integrated: 8309740: Expand timeout windows for tests in JDK-8179502 In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 18:19:45 GMT, Jamil Nimeh wrote: > This PR is for tests that were modified/added in JDK-8179502. The timeout windows for those tests were a little too short on some test systems, especially when the system is under heavy load. After a few iterations trying out various longer time windows I have a set that should not run into issues. This pull request has now been integrated. Changeset: 5ca4cdd2 Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/5ca4cdd2caceba9dad8025e5a8851740a3961921 Stats: 21 lines in 3 files changed: 5 ins; 0 del; 16 mod 8309740: Expand timeout windows for tests in JDK-8179502 Reviewed-by: xuelei, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/14526 From jnimeh at openjdk.org Fri Jun 23 15:03:17 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 23 Jun 2023 15:03:17 GMT Subject: RFR: 8309740: Expand timeout windows for tests in JDK-8179502 In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 18:42:32 GMT, Xue-Lei Andrew Fan wrote: >> This PR is for tests that were modified/added in JDK-8179502. The timeout windows for those tests were a little too short on some test systems, especially when the system is under heavy load. After a few iterations trying out various longer time windows I have a set that should not run into issues. > > Marked as reviewed by xuelei (Reviewer). @XueleiFan and/or @MBaesken, would you be able to check out the JDK21 backport (https://github.com/openjdk/jdk21/pull/58)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14526#issuecomment-1604405990 From cslucas at openjdk.org Fri Jun 23 15:03:19 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 23 Jun 2023 15:03:19 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Wed, 14 Jun 2023 20:19:58 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: >> >> - Merge branch 'openjdk:master' into rematerialization-of-merges >> - Rome minor refactorings. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> Catching up with master. >> - Address PR review 6: debug format output & some refactoring. >> - Catching up with master branch. >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address PR review 6: refactoring around rematerialization & improve test cases. >> - Address PR review 5: refactor on rematerialization & add tests. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - ... and 9 more: https://git.openjdk.org/jdk/compare/57b82512...939dcffe > > src/hotspot/share/opto/c2_globals.hpp line 473: > >> 471: " register allocation.") \ >> 472: \ >> 473: product(bool, ReduceAllocationMerges, true, \ > > I suggest to turn the flag into diagnostic one. There are much stricter requirements for product flags, so better to avoid introducing new ones. @iwanowww - I'm confused by what a "Diagnostic" flag is. According to [this documentation](https://wiki.openjdk.org/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process) "Diagnostic flags are not meant for VM tuning or for product modes. They are to be used for VM quality assurance or field diagnosis of VM bugs [...]" I believe the patch I'm proposing is a VM tuning optimization, so should it really be a diagnostic flag? Besides, I think we'll try _at a later moment_ to make this a product flag. Do you think an experimental flag is more appropriate? Thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1239928841 From jnimeh at openjdk.org Fri Jun 23 15:03:25 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 23 Jun 2023 15:03:25 GMT Subject: [jdk21] RFR: 8309740: Expand timeout windows for tests in JDK-8179502 Message-ID: <4yMtuJGh8lN7fcid3-3hNL3OulqNjjTLTXuE2tYCyaA=.a9574544-c4f0-4b45-bde7-fe009f737153@github.com> This is a backport of the test fixes comprising JDK-8309740. ------------- Commit messages: - Backport 5ca4cdd2caceba9dad8025e5a8851740a3961921 Changes: https://git.openjdk.org/jdk21/pull/58/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=58&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309740 Stats: 21 lines in 3 files changed: 5 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk21/pull/58.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/58/head:pull/58 PR: https://git.openjdk.org/jdk21/pull/58 From duke at openjdk.org Fri Jun 23 15:20:24 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 23 Jun 2023 15:20:24 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime [v4] In-Reply-To: References: Message-ID: > Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Moved UTC date range to constants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14617/files - new: https://git.openjdk.org/jdk/pull/14617/files/fad36da0..db70499b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14617&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14617&range=02-03 Stats: 13 lines in 1 file changed: 10 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14617.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14617/head:pull/14617 PR: https://git.openjdk.org/jdk/pull/14617 From jnimeh at openjdk.org Fri Jun 23 15:26:05 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 23 Jun 2023 15:26:05 GMT Subject: RFR: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 15:20:24 GMT, Ben Perez wrote: >> Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Moved UTC date range to constants Looks good to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14617#pullrequestreview-1495360483 From duke at openjdk.org Fri Jun 23 15:34:11 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 23 Jun 2023 15:34:11 GMT Subject: Integrated: 8279254: PKCS9Attribute SigningTime always encoded in UTFTime In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:45:14 GMT, Ben Perez wrote: > Added single-argument `putTime` method to `DerOutputStream` that selects the correct encoding based on the `Date` value. Similarly, a `getTime` method was added to `DerValue` to automatically call the correct decoding function based on the date type specified by the `tag`. Furthermore, the `encode` method in `PKCS9Attribute` was changed to utilize the new `putTime` method. This pull request has now been integrated. Changeset: 7628da20 Author: Ben Perez Committer: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/7628da200833d0d26215a91afdd1bf7fc110da1d Stats: 94 lines in 5 files changed: 87 ins; 1 del; 6 mod 8279254: PKCS9Attribute SigningTime always encoded in UTFTime Reviewed-by: jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/14617 From xuelei at openjdk.org Fri Jun 23 18:38:06 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 23 Jun 2023 18:38:06 GMT Subject: [jdk21] RFR: 8309740: Expand timeout windows for tests in JDK-8179502 In-Reply-To: <4yMtuJGh8lN7fcid3-3hNL3OulqNjjTLTXuE2tYCyaA=.a9574544-c4f0-4b45-bde7-fe009f737153@github.com> References: <4yMtuJGh8lN7fcid3-3hNL3OulqNjjTLTXuE2tYCyaA=.a9574544-c4f0-4b45-bde7-fe009f737153@github.com> Message-ID: On Fri, 23 Jun 2023 14:55:45 GMT, Jamil Nimeh wrote: > This is a backport of the test fixes comprising JDK-8309740. Looks good to me. I was just wondering, if the /backport tag could work from the original PR for backporting. ------------- Marked as reviewed by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk21/pull/58#pullrequestreview-1495698832 From hchao at openjdk.org Fri Jun 23 18:56:07 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 23 Jun 2023 18:56:07 GMT Subject: [jdk21] RFR: 8309740: Expand timeout windows for tests in JDK-8179502 In-Reply-To: <4yMtuJGh8lN7fcid3-3hNL3OulqNjjTLTXuE2tYCyaA=.a9574544-c4f0-4b45-bde7-fe009f737153@github.com> References: <4yMtuJGh8lN7fcid3-3hNL3OulqNjjTLTXuE2tYCyaA=.a9574544-c4f0-4b45-bde7-fe009f737153@github.com> Message-ID: On Fri, 23 Jun 2023 14:55:45 GMT, Jamil Nimeh wrote: > This is a backport of the test fixes comprising JDK-8309740. Marked as reviewed by hchao (Committer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/58#pullrequestreview-1495731841 From weijun at openjdk.org Fri Jun 23 19:30:09 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 23 Jun 2023 19:30:09 GMT Subject: [jdk21] RFR: 8309740: Expand timeout windows for tests in JDK-8179502 In-Reply-To: References: <4yMtuJGh8lN7fcid3-3hNL3OulqNjjTLTXuE2tYCyaA=.a9574544-c4f0-4b45-bde7-fe009f737153@github.com> Message-ID: On Fri, 23 Jun 2023 18:35:25 GMT, Xue-Lei Andrew Fan wrote: > Looks good to me. I was just wondering, if the /backport tag could work from the original PR for backporting. It looks Jamil did use the `/backport` command from the original commit. Or are you wondering why a review is still needed? It's because this is a "stabilization repository". See https://openjdk.org/jeps/3 for more details. ------------- PR Comment: https://git.openjdk.org/jdk21/pull/58#issuecomment-1604771546 From vlivanov at openjdk.org Fri Jun 23 21:28:17 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 23 Jun 2023 21:28:17 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <3G-J7S82KT6w5oWaxYK-3soNIQDfcR65ESTRLA_LfDc=.bdde8aa7-4044-44de-9c01-951013d7707d@github.com> On Fri, 23 Jun 2023 15:00:15 GMT, Cesar Soares Lucas wrote: >> src/hotspot/share/opto/c2_globals.hpp line 473: >> >>> 471: " register allocation.") \ >>> 472: \ >>> 473: product(bool, ReduceAllocationMerges, true, \ >> >> I suggest to turn the flag into diagnostic one. There are much stricter requirements for product flags, so better to avoid introducing new ones. > > @iwanowww - I'm confused by what a "Diagnostic" flag is. According to [this documentation](https://wiki.openjdk.org/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process) "Diagnostic flags are not meant for VM tuning or for product modes. They are to be used for VM quality assurance or field diagnosis of VM bugs [...]" I believe the patch I'm proposing is a VM tuning optimization, so should it really be a diagnostic flag? Besides, I think we'll try _at a later moment_ to make this a product flag. Do you think an experimental flag is more appropriate? Thank you. You can look at it in the following way: since the flag is set to true by default, the feature is unconditionally available in product binaries. The only reason to explicitly specify the flag is to turn the optimization off and it may be needed to diagnose VM crashes or performance regressions. As an afterthrought, maybe C2 should check a compiler directive (and not a global flag) to be able to control the optimization up to per-method granularity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1240415979 From jnimeh at openjdk.org Fri Jun 23 22:03:07 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 23 Jun 2023 22:03:07 GMT Subject: [jdk21] Integrated: 8309740: Expand timeout windows for tests in JDK-8179502 In-Reply-To: <4yMtuJGh8lN7fcid3-3hNL3OulqNjjTLTXuE2tYCyaA=.a9574544-c4f0-4b45-bde7-fe009f737153@github.com> References: <4yMtuJGh8lN7fcid3-3hNL3OulqNjjTLTXuE2tYCyaA=.a9574544-c4f0-4b45-bde7-fe009f737153@github.com> Message-ID: On Fri, 23 Jun 2023 14:55:45 GMT, Jamil Nimeh wrote: > This is a backport of the test fixes comprising JDK-8309740. This pull request has now been integrated. Changeset: 17b6f7b9 Author: Jamil Nimeh URL: https://git.openjdk.org/jdk21/commit/17b6f7b9a5a14a869d3f1efd0ab51fea4fa40c83 Stats: 21 lines in 3 files changed: 5 ins; 0 del; 16 mod 8309740: Expand timeout windows for tests in JDK-8179502 Reviewed-by: xuelei, hchao Backport-of: 5ca4cdd2caceba9dad8025e5a8851740a3961921 ------------- PR: https://git.openjdk.org/jdk21/pull/58 From duke at openjdk.org Sun Jun 25 22:20:14 2023 From: duke at openjdk.org (duke) Date: Sun, 25 Jun 2023 22:20:14 GMT Subject: Withdrawn: 8307143: CredentialsCache.cacheName should not be static In-Reply-To: <4ErtNxM1gNx8rPGo4X0O3QJMjoVTGHALHDpztmdqC48=.b01795e2-531a-48cb-8225-129e3c1924f9@github.com> References: <4ErtNxM1gNx8rPGo4X0O3QJMjoVTGHALHDpztmdqC48=.b01795e2-531a-48cb-8225-129e3c1924f9@github.com> Message-ID: On Sun, 30 Apr 2023 13:03:38 GMT, Weijun Wang wrote: > The CC can be loaded with any file and its name is not static. > > `MemoryCredentialsCache` is removed since it's not used anywhere. We've already supported native ccache reading directly with JNI method `Credentials::acquireDefaultNativeCreds`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13737 From peter.firmstone at zeus.net.au Sun Jun 25 23:15:41 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 26 Jun 2023 09:15:41 +1000 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> Message-ID: <0aaf4729-732b-d300-5ebb-e6bb3b1f90a3@zeus.net.au> Will the removal process be traceable using a bug ID or JEP, until it's completely removed, rather than bit rotted out over time? After much thought and consideration our best option is to maintain our own build, by maintaining patches against the upstream OpenJDK build, this will allow us to run all existing jtreg tests, as well as implement new tests and prevent bit rot. Support for SM will also be removed from jtreg, so we'll need a build of that too. This should at least secure our future roadmap until an alternative exists. -- Regards, Peter On 18/06/2023 10:15 pm, Alan Bateman wrote: > On 18/06/2023 12:52, Peter Firmstone wrote: >> >> Thanks Alan, >> >> Personally, I would hope that nothing happens until after Java 21, >> time is precious, we'll need all the time we can get. >> >> I was hoping, that all privileged actions might be retained >> indefinitely, so that we may instrument them. >> > Once the SM operating mode goes away then I would expect most usages > of privileged actions in the JDK can be removed. Leaving them for an > "authorization layer" to instrument would be misleading. Existing > usages will quickly bit rot. It would also be a tax on all future > features and all ongoing maintenance. > > -Alan. From jwaters at openjdk.org Mon Jun 26 02:38:02 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Jun 2023 02:38:02 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 Message-ID: Microsoft, your C "conformance" is garbage ------------- Commit messages: - ArrayReferenceImpl.c - GSSLibStub.c - 8310863 Changes: https://git.openjdk.org/jdk/pull/14645/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14645&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310863 Stats: 11 lines in 3 files changed: 0 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14645.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14645/head:pull/14645 PR: https://git.openjdk.org/jdk/pull/14645 From jwaters at openjdk.org Mon Jun 26 02:41:02 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Jun 2023 02:41:02 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Microsoft, your C "conformance" is garbage @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606505881 From dholmes at openjdk.org Mon Jun 26 04:18:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Jun 2023 04:18:03 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Microsoft, your C "conformance" is garbage https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606567568 From jwaters at openjdk.org Mon Jun 26 04:27:01 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Jun 2023 04:27:01 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 04:15:09 GMT, David Holmes wrote: > https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170 :/ > How was the original change tested? How was this change tested? I made the mistake of testing the original on gcc instead of the native compiler for Windows, I recompiled this one with the microsoft toolchain before writing the fix, which fortunately passes the compile step as is evident in the tests for this PR Sorry for the goof :( ------------- PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606570640 PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606572218 From jwaters at openjdk.org Mon Jun 26 04:27:03 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Jun 2023 04:27:03 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 _Alignas does work on Microsoft Visual C, fortunately ------------- PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606570803 From dholmes at openjdk.org Mon Jun 26 04:27:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Jun 2023 04:27:03 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 How was the original change tested? How was this change tested? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606571300 From dholmes at openjdk.org Mon Jun 26 04:30:07 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Jun 2023 04:30:07 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 04:23:58 GMT, Julian Waters wrote: > as is evident in the tests for this PR You mean the GHA builds? They don't seem to be building the failing `jdk.jdwp.agent-static-libs` target. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606573575 From jwaters at openjdk.org Mon Jun 26 04:41:02 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Jun 2023 04:41:02 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 04:26:47 GMT, David Holmes wrote: > > as is evident in the tests for this PR > > You mean the GHA builds? They don't seem to be building the failing `jdk.jdwp.agent-static-libs` target. I can't recompile the JDK at the moment to compile ArrayReferenceImpl.c, but I can devise a simple test for this: #include int main() { _Alignas(8) int i = 7; printf("%i", i); return 0; } `cl.exe -nologo -std:c11 -Fo:align.o align.c` align.exe 7 The _Alignas specifier does the same thing as the __declspec(align()) one, so there's no difference in which is used (which also means that the other places where this is used being able to compile is proof of it working as well) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606579037 From dholmes at openjdk.org Mon Jun 26 04:41:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Jun 2023 04:41:03 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 Okay I have it running through our tier1 builds at the moment. If that passes I will approve the PR. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606580347 From Alan.Bateman at oracle.com Mon Jun 26 05:18:29 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Jun 2023 06:18:29 +0100 Subject: PrivilegedAction et al and JEP411 In-Reply-To: <0aaf4729-732b-d300-5ebb-e6bb3b1f90a3@zeus.net.au> References: <62045d50-ff6e-058c-08d7-f133277a07fd@zeus.net.au> <5b9a3346-8cd9-5aea-6300-97c704a84f8d@oracle.com> <0aaf4729-732b-d300-5ebb-e6bb3b1f90a3@zeus.net.au> Message-ID: On 26/06/2023 00:15, Peter Firmstone wrote: > Will the removal process be traceable using a bug ID or JEP, until > it's completely removed, rather than bit rotted out over time? Details TBD but there will be a JEP as it a significant change. -Alan > > After much thought and consideration our best option is to maintain > our own build, by maintaining patches against the upstream OpenJDK > build, this will allow us to run all existing jtreg tests, as well as > implement new tests and prevent bit rot. > > Support for SM will also be removed from jtreg, so we'll need a build > of that too. > > This should at least secure our future roadmap until an alternative > exists. > From dholmes at openjdk.org Mon Jun 26 05:30:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Jun 2023 05:30:10 GMT Subject: RFR: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 Our tier 1 builds have passed. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14645#pullrequestreview-1497595990 From jwaters at openjdk.org Mon Jun 26 05:41:09 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Jun 2023 05:41:09 GMT Subject: Integrated: 8310863: Build failure after JDK- 8305341 In-Reply-To: References: Message-ID: <1sF7T0TaWs_9uqjxf3c0f1P6LAvg9ONJjMnPvhy1wR8=.f8a77de2-f674-4733-8be3-b43bf66e6a4f@github.com> On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote: > Build failure after JDK- 8305341 This pull request has now been integrated. Changeset: 8242c647 Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/8242c647b9d31320757363b69e7048a109ce86df Stats: 11 lines in 3 files changed: 0 ins; 5 del; 6 mod 8310863: Build failure after JDK- 8305341 Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/14645 From weijun at openjdk.org Mon Jun 26 13:14:07 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 26 Jun 2023 13:14:07 GMT Subject: RFR: 8308540: On Kerberos TGT referral, if krb5.conf is missing realm, bad exception message In-Reply-To: References: Message-ID: On Mon, 22 May 2023 15:03:15 GMT, Weijun Wang wrote: > Add realm name to the exception message, and make it the primary exception (retry exception added suppressed). Still worth fixing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14086#issuecomment-1607442146 From xuelei at openjdk.org Mon Jun 26 15:53:05 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 26 Jun 2023 15:53:05 GMT Subject: RFR: 8308540: On Kerberos TGT referral, if krb5.conf is missing realm, bad exception message In-Reply-To: References: Message-ID: On Mon, 22 May 2023 15:03:15 GMT, Weijun Wang wrote: > Add realm name to the exception message, and make it the primary exception (retry exception added suppressed). Marked as reviewed by xuelei (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14086#pullrequestreview-1498866747 From weijun at openjdk.org Mon Jun 26 15:58:11 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 26 Jun 2023 15:58:11 GMT Subject: Integrated: 8308540: On Kerberos TGT referral, if krb5.conf is missing realm, bad exception message In-Reply-To: References: Message-ID: On Mon, 22 May 2023 15:03:15 GMT, Weijun Wang wrote: > Add realm name to the exception message, and make it the primary exception (retry exception added suppressed). This pull request has now been integrated. Changeset: e624484e Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/e624484ecf2f31d9e52caf3fda2d18f0ef82123f Stats: 62 lines in 3 files changed: 33 ins; 15 del; 14 mod 8308540: On Kerberos TGT referral, if krb5.conf is missing realm, bad exception message Reviewed-by: xuelei ------------- PR: https://git.openjdk.org/jdk/pull/14086 From liach at openjdk.org Mon Jun 26 16:01:09 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jun 2023 16:01:09 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 15:25:08 GMT, Glavo wrote: > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. Since it appears you missed my edit to my comment, this part can be replaced by the newStringLatin1NoRepl as well: https://github.com/openjdk/jdk/blob/5ff42d14294199eb3bf10b66530f9249fb68810d/src/java.base/share/classes/java/lang/String.java#L812-L814 after this block: if (cd instanceof ArrayDecoder ad && ad.isASCIICompatible() && !StringCoding.hasNegatives(src, 0, src.length)) { I've created a JBS ticket for this patch: https://bugs.openjdk.org/browse/JDK-8310901 In the ticket, I included a more comprehensive description about the whole situation (which is also why I strongly support this patch) src/java.base/share/classes/java/lang/String.java line 803: > 801: } > 802: if (cs == US_ASCII.INSTANCE) { > 803: if (!StringCoding.hasNegatives(src, 0, src.length)) { The duplicated compact_string logic below this line and that one for arraydecoder can be replaced by a simple newStringLatin1NoRepl as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1607741464 PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1607760378 PR Review Comment: https://git.openjdk.org/jdk/pull/14655#discussion_r1242379842 From duke at openjdk.org Mon Jun 26 16:01:08 2023 From: duke at openjdk.org (Glavo) Date: Mon, 26 Jun 2023 16:01:08 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl Message-ID: Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. Reasons: * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. ------------- Commit messages: - clean newStringNoRepl1 - clean newStringNoRepl1 - Rename jla to JLA - Create new method JavaLangAccess::newStringLatin1NoRepl Changes: https://git.openjdk.org/jdk/pull/14655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310901 Stats: 66 lines in 4 files changed: 22 ins; 29 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/14655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655 PR: https://git.openjdk.org/jdk/pull/14655 From liach at openjdk.org Mon Jun 26 16:06:02 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jun 2023 16:06:02 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 15:25:08 GMT, Glavo wrote: > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 345: > 343: * > 344: * The caller of this method shall relinquish and transfer the ownership of > 345: * the byte array to the callee since the later will not make a copy. This comment isn't quite right; the byte array is simply trusted/shared, that it should never be changed or modifiable. The caller can freely retain the array (such as in a field) as long as it doesn't change the array. This is just a copycat of the original newStringNoRepl, which should be fixed; newStringUTF8NoRepl has no such issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14655#discussion_r1242426598 From duke at openjdk.org Mon Jun 26 16:17:08 2023 From: duke at openjdk.org (Glavo) Date: Mon, 26 Jun 2023 16:17:08 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v2] In-Reply-To: References: Message-ID: > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. Glavo has updated the pull request incrementally with one additional commit since the last revision: update javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14655/files - new: https://git.openjdk.org/jdk/pull/14655/files/6f682a3c..27bacac1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655 PR: https://git.openjdk.org/jdk/pull/14655 From duke at openjdk.org Mon Jun 26 16:19:04 2023 From: duke at openjdk.org (Glavo) Date: Mon, 26 Jun 2023 16:19:04 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 16:02:57 GMT, Chen Liang wrote: > This is just a copycat of the original newStringNoRepl, which should be fixed; newStringUTF8NoRepl has no such issue. Unfortunately, the behavior of `newStringUTF8NoRepl` is not the same as that of `newStringNoRepl`, as it actually always copy the byte array. I have tried to change its behavior to be consistent with newStringNoRepl, but unfortunately it was not accepted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14655#discussion_r1242442737 From duke at openjdk.org Mon Jun 26 17:17:27 2023 From: duke at openjdk.org (Glavo) Date: Mon, 26 Jun 2023 17:17:27 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v3] In-Reply-To: References: Message-ID: > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. Glavo 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 six additional commits since the last revision: - Merge branch 'openjdk:master' into latin1-no-repl - update javadoc - clean newStringNoRepl1 - clean newStringNoRepl1 - Rename jla to JLA - Create new method JavaLangAccess::newStringLatin1NoRepl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14655/files - new: https://git.openjdk.org/jdk/pull/14655/files/27bacac1..9958348b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=01-02 Stats: 147 lines in 13 files changed: 90 ins; 15 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/14655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655 PR: https://git.openjdk.org/jdk/pull/14655 From mdonovan at openjdk.org Mon Jun 26 17:44:14 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 26 Jun 2023 17:44:14 GMT Subject: RFR: 8310070: Test: javax/net/ssl/DTLS/DTLSWontNegotiateV10.java timed out Message-ID: In this PR, I updated the test to use read time-outs. The test is restarted if the read operations time-out within (default) 30 seconds. The test makes 5 attempts before giving up. ------------- Commit messages: - 8310070: Test: javax/net/ssl/DTLS/DTLSWontNegotiateV10.java timed out Changes: https://git.openjdk.org/jdk/pull/14658/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14658&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310070 Stats: 44 lines in 1 file changed: 30 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/14658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14658/head:pull/14658 PR: https://git.openjdk.org/jdk/pull/14658 From ascarpino at openjdk.org Mon Jun 26 22:52:18 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 26 Jun 2023 22:52:18 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v2] In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: > Hi, > > I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. > > There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: update for review: changed test, removed commented out code in module, fixed switch statement, added --limit-modules ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14457/files - new: https://git.openjdk.org/jdk/pull/14457/files/85870520..32b4cee1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=00-01 Stats: 34 lines in 5 files changed: 13 ins; 3 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/14457.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14457/head:pull/14457 PR: https://git.openjdk.org/jdk/pull/14457 From duke at openjdk.org Tue Jun 27 07:45:34 2023 From: duke at openjdk.org (Glavo) Date: Tue, 27 Jun 2023 07:45:34 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: References: Message-ID: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. Glavo 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 seven additional commits since the last revision: - Merge branch 'openjdk:master' into latin1-no-repl - Merge branch 'openjdk:master' into latin1-no-repl - update javadoc - clean newStringNoRepl1 - clean newStringNoRepl1 - Rename jla to JLA - Create new method JavaLangAccess::newStringLatin1NoRepl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14655/files - new: https://git.openjdk.org/jdk/pull/14655/files/9958348b..512029d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=02-03 Stats: 6443 lines in 195 files changed: 2377 ins; 2165 del; 1901 mod Patch: https://git.openjdk.org/jdk/pull/14655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655 PR: https://git.openjdk.org/jdk/pull/14655 From cslucas at openjdk.org Tue Jun 27 15:02:04 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 27 Jun 2023 15:02:04 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v19] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Merge branch 'openjdk:master' into rematerialization-of-merges - Rome minor refactorings. - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges Catching up with master. - Address PR review 6: debug format output & some refactoring. - Catching up with master branch. Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address PR review 6: refactoring around rematerialization & improve test cases. - Address PR review 5: refactor on rematerialization & add tests. - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address part of PR review 4 & fix a bug setting only_candidate - ... and 10 more: https://git.openjdk.org/jdk/compare/5ca4cdd2...d7cf00af ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=18 Stats: 2732 lines in 26 files changed: 2484 ins; 108 del; 140 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From coffeys at openjdk.org Tue Jun 27 15:06:45 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 27 Jun 2023 15:06:45 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey 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: - Avoid sharing INDENT variables - Merge branch 'master' into 8281658-showsettings-security - Don't allow bad subcommand values for security component - restore more informative help message - Split long properties for ; also - Pass PrintStream to security helper - Refactor out security code to helper class - Print aliases. Order Provider type/service output. - Incorporate review comments from Roger and tweak some code - Merge branch 'master' into 8281658-showsettings-security - ... and 5 more: https://git.openjdk.org/jdk/compare/698e2b5c...7e6f5090 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/77c9f5e2..7e6f5090 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=06-07 Stats: 31805 lines in 1150 files changed: 12787 ins; 12829 del; 6189 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From rriggs at openjdk.org Tue Jun 27 18:01:07 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Jun 2023 18:01:07 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> References: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> Message-ID: On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote: >> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. >> >> Reasons: >> >> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; >> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. > > Glavo 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 seven additional commits since the last revision: > > - Merge branch 'openjdk:master' into latin1-no-repl > - Merge branch 'openjdk:master' into latin1-no-repl > - update javadoc > - clean newStringNoRepl1 > - clean newStringNoRepl1 > - Rename jla to JLA > - Create new method JavaLangAccess::newStringLatin1NoRepl I don't think this is a productive change. It takes a local inconvenience try/catch and spreads the impact over multiple files and packages as well as bulking up JLA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1609977623 From liach at openjdk.org Tue Jun 27 18:13:03 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jun 2023 18:13:03 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: References: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> Message-ID: On Tue, 27 Jun 2023 17:58:05 GMT, Roger Riggs wrote: > I don't think this is a productive change. It takes a local inconvenience try/catch and spreads the impact over multiple files and packages as well as bulking up JLA. By this rationale, newStringUTF8NoRepl should be removed as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1609997762 From duke at openjdk.org Tue Jun 27 18:13:03 2023 From: duke at openjdk.org (Glavo) Date: Tue, 27 Jun 2023 18:13:03 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: References: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> Message-ID: On Tue, 27 Jun 2023 17:58:05 GMT, Roger Riggs wrote: > It takes a local inconvenience try/catch and spreads the impact over multiple files and packages as well as bulking up JLA. I don't quite understand what you mean. The main goal of this PR is to get rid of those annoying try-catch, but it looks like you misunderstood this PR? My English is poor, please forgive me if I misunderstood this sentence of yours. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1609997263 From tprinzing at openjdk.org Tue Jun 27 18:32:05 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 27 Jun 2023 18:32:05 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com> References: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com> Message-ID: On Thu, 22 Jun 2023 10:21:46 GMT, Alan Bateman wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408: > >> 406: @Override >> 407: public int read(ByteBuffer buf) throws IOException { >> 408: if (!SocketReadEvent.enabled()) { > > The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does not go through SC.read/write so I think SocketAdaptor read/write will need attention, maybe a future PR as there are other code paths that aren't covered in this PR. I've created https://bugs.openjdk.org/browse/JDK-8310978 to drive the future PR to support the missing code paths ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1244182424 From cslucas at openjdk.org Tue Jun 27 18:41:31 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 27 Jun 2023 18:41:31 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v20] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Addressing PR feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/d7cf00af..4acfcbcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=18-19 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From cslucas at openjdk.org Tue Jun 27 18:41:32 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 27 Jun 2023 18:41:32 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: <3G-J7S82KT6w5oWaxYK-3soNIQDfcR65ESTRLA_LfDc=.bdde8aa7-4044-44de-9c01-951013d7707d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <3G-J7S82KT6w5oWaxYK-3soNIQDfcR65ESTRLA_LfDc=.bdde8aa7-4044-44de-9c01-951013d7707d@github.com> Message-ID: <9deZcQk5phYkxtQtINTCxZ3gX4_jwN8L0gfqyjwtmho=.8fb89c9a-7577-4378-a5ca-6a1bcc356587@github.com> On Fri, 23 Jun 2023 21:24:20 GMT, Vladimir Ivanov wrote: >> @iwanowww - I'm confused by what a "Diagnostic" flag is. According to [this documentation](https://wiki.openjdk.org/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process) "Diagnostic flags are not meant for VM tuning or for product modes. They are to be used for VM quality assurance or field diagnosis of VM bugs [...]" I believe the patch I'm proposing is a VM tuning optimization, so should it really be a diagnostic flag? Besides, I think we'll try _at a later moment_ to make this a product flag. Do you think an experimental flag is more appropriate? Thank you. > > You can look at it in the following way: since the flag is set to true by default, the feature is unconditionally available in product binaries. The only reason to explicitly specify the flag is to turn the optimization off and it may be needed to diagnose VM crashes or performance regressions. > > As an afterthrought, maybe C2 should check a compiler directive (and not a global flag) to be able to control the optimization up to per-method granularity. Thank you @iwanowww for clarifying. Now I understand this better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1244190081 From tprinzing at openjdk.org Tue Jun 27 18:45:04 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 27 Jun 2023 18:45:04 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote: > In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead? Added issue https://bugs.openjdk.org/browse/JDK-8310979 to add a field to SocketReadEvent and SocketWriteEvent in a separate PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1610037645 From rhalade at openjdk.org Tue Jun 27 18:46:25 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 27 Jun 2023 18:46:25 GMT Subject: [jdk21] RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated Message-ID: This test update should be included in JDK 21 LTS release. ------------- Commit messages: - Backport 9f64a64376c677dbe1358807329b42737ac78ad9 Changes: https://git.openjdk.org/jdk21/pull/71/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=71&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301379 Stats: 311 lines in 2 files changed: 179 ins; 51 del; 81 mod Patch: https://git.openjdk.org/jdk21/pull/71.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/71/head:pull/71 PR: https://git.openjdk.org/jdk21/pull/71 From cslucas at openjdk.org Tue Jun 27 18:56:16 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 27 Jun 2023 18:56:16 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Wed, 14 Jun 2023 20:48:36 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: >> >> - Merge branch 'openjdk:master' into rematerialization-of-merges >> - Rome minor refactorings. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> Catching up with master. >> - Address PR review 6: debug format output & some refactoring. >> - Catching up with master branch. >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address PR review 6: refactoring around rematerialization & improve test cases. >> - Address PR review 5: refactor on rematerialization & add tests. >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - ... and 9 more: https://git.openjdk.org/jdk/compare/57b82512...939dcffe > > src/hotspot/share/opto/c2compiler.cpp line 150: > >> 148: if (C.failure_reason_is(retry_no_reduce_allocation_merges())) { >> 149: assert(do_reduce_allocation_merges, "must make progress"); >> 150: do_reduce_allocation_merges = false; > > I consider the check here as a safety net which is intended to provide graceful degradation in performance if RAM optimization misbehaves for some reason. But bailing out an optimization is better than bailing out the whole compilation. I suggest to introduce new diagnostic flag (e.g., `VerifyReduceAllocationMerges`) and add a guarantee call here which signals whenever we encounter a problematic case. I'm fine with handling that as a separate enhancement (it makes sense to dump additional diagnostic info at the place where such bail outs are triggered ). I created a new [work item](https://bugs.openjdk.org/browse/JDK-8310980) to track this work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1244208611 From rhalade at openjdk.org Tue Jun 27 20:51:08 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 27 Jun 2023 20:51:08 GMT Subject: [jdk21] RFR: 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC Message-ID: <96g545bCO4Wflik7nki1eULkMQ7HniGCHMAA4p4fal4=.e2a1bb73-d55d-4dc8-b83a-5b3481026acc@github.com> This test update should be included in JDK 21 LTS release. ------------- Commit messages: - Backport 130a9f138759c2f8504a83a6f3a93b1f219f0a42 Changes: https://git.openjdk.org/jdk21/pull/74/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=74&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292704 Stats: 56 lines in 2 files changed: 43 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk21/pull/74.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/74/head:pull/74 PR: https://git.openjdk.org/jdk21/pull/74 From rriggs at openjdk.org Tue Jun 27 21:06:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Jun 2023 21:06:06 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> References: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> Message-ID: On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote: >> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. >> >> Reasons: >> >> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; >> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. > > Glavo 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 seven additional commits since the last revision: > > - Merge branch 'openjdk:master' into latin1-no-repl > - Merge branch 'openjdk:master' into latin1-no-repl > - update javadoc > - clean newStringNoRepl1 > - clean newStringNoRepl1 > - Rename jla to JLA > - Create new method JavaLangAccess::newStringLatin1NoRepl The goal of removing the try/catch from HexFormat can be solved locally by creating a private method in HexFormat that swallows the exception. There is no need to add a method to Java Lang Access or change 3 other files. The method `newStringUTF8NoRepl` is different, it can/does throw runtime exceptions but there is no need for try/catch in that case, no change is needed there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610209289 From tprinzing at openjdk.org Tue Jun 27 21:06:54 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 27 Jun 2023 21:06:54 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v2] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: Avoid exceptions getting address/timeout for jfr event. Remove unused EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14342/files - new: https://git.openjdk.org/jdk/pull/14342/files/5faeb300..518adf8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=00-01 Stats: 21 lines in 3 files changed: 10 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From tprinzing at openjdk.org Tue Jun 27 21:52:08 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 27 Jun 2023 21:52:08 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - remove unused SOCKET_READ and SOCKET_WRITE configurations. - Merge branch 'master' into JDK-8308995 # Conflicts: # src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java - Avoid exceptions getting address/timeout for jfr event. Remove unused EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious whitespace. - some changes from review. read0() to implRead() write0() to implWrite() trailing whitespace - fix copyright date - Added micro benchmark to measure socket event overhead. - Some changes from review. Append a 0 to method names being wrapped. Use getHostString to avoid a reverse lookup when fetching the hostname of the remote address. - remove unnecessary cast - 8308995: Update Network IO JFR events to be static mirror events ------------- Changes: https://git.openjdk.org/jdk/pull/14342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=02 Stats: 908 lines in 13 files changed: 533 ins; 369 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From duke at openjdk.org Tue Jun 27 22:43:05 2023 From: duke at openjdk.org (Glavo) Date: Tue, 27 Jun 2023 22:43:05 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: References: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> Message-ID: On Tue, 27 Jun 2023 21:03:05 GMT, Roger Riggs wrote: > The goal of removing the try/catch from HexFormat can be solved locally by creating a private method in HexFormat that swallows the exception. There is no need to add a method to Java Lang Access or change 3 other files. The method `newStringUTF8NoRepl` is different, it can/does throw runtime exceptions but there is no need for try/catch in that case, no change is needed there. The different functions of `newStringNoRepl` from public APIs are: 1) It will try not to copy the byte array as much as possible; 2) It will throw an exception when there are malformed or unmappable byte sequence. Currently, `newStringNoRepl` has two use cases: 1) `HexFormat`; 2) `Files.readString`. If #14578 is merged, it will have a third use case. If we review these use cases, we will realize that `newStringNoRepl` did not make any use cases happy: * For `HexFormat` and [#14578](https://github.com/openjdk/jdk/pull/14578), `newStringNoRepl` is used to access `String(byte[],byte)` outside of `java.lang`. In this usage, `newStringNoRepl` is inconvenient to use. Users not only need to pass the charset, but also need to catch `CharacterCodingException`, even though it is actually impossible to occur. The purpose of this PR is to provide a better way of doing this. * For `Files.readString`: Although `newStringNoRepl` was originally created for `Files.readString`, `Files.readString` has changed. Currently `Files.readString` is implemented as follows: https://github.com/openjdk/jdk/blob/7f094353673f5047643a2d7b512d0de8c665f215/src/java.base/share/classes/java/nio/file/Files.java#L3342-L3350 Obviously, for security reasons, additional check `path.getClass().getModule() != Object.class.getModule()` has been added here. This makes `newStringNoRepl` awkward here. When reading a file containing non-ASCII characters from a non-default filesystem, an unnecessary copy of the byte array occurs here. --- Since this method is so lame, I'm planning to do some retrofits: 1. Create a new method `newStringLatin1NoRepl`, use it to access `String(byte[],byte)` outside of `java.lang`; 2. Delete `newStringUTF8NoRepl` and add a new parameter `boolean noShare` to `newStringNoRepl`. The new signature for `newStringNoRepl` looks like this: String newStringNoRepl(byte[] bytes, Charset cs, boolean noShare) throws CharacterCodingException; `newStringUTF8NoRepl(bytes)` can be replaced with `newStringNoRepl(bytes, UTF_8, true)`. `Files.readString` can be optimized to: return JLA.newStringNoRepl(readAllBytes(path), cs, path.getClass().getModule() != Object.class.getModule()); This is my idea. Can you take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610315852 From liach at openjdk.org Wed Jun 28 01:35:08 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 28 Jun 2023 01:35:08 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> References: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> Message-ID: On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote: >> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. >> >> Reasons: >> >> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; >> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. > > Glavo 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 seven additional commits since the last revision: > > - Merge branch 'openjdk:master' into latin1-no-repl > - Merge branch 'openjdk:master' into latin1-no-repl > - update javadoc > - clean newStringNoRepl1 > - clean newStringNoRepl1 > - Rename jla to JLA > - Create new method JavaLangAccess::newStringLatin1NoRepl I've investigated the few xxNoRepl methods and think they are best coalesced together into newStringNoRepl and getBytesNoRepl taking byte arrays. 1. The exceptions to the NoRepl methods was added in [8205058](https://bugs.openjdk.org/browse/JDK-8205058) when the access method only catered to Files use cases; these are applicable nowhere else. 2. The UTF8 noRepl methods are sometimes implemented incorrectly, especially getBytesUTF8NoRepl, which always copies the array. They are added specifically for Zip handling as well. Thus, I recommend the following changes: 1. Make the NoRepl methods throw IllegalArgument (like NoRepl1 do) by default; move the exception handling logic into Files implementation, the only place where it's actually needed. 2. Coalesce all charset-specific NoRepl methods in JLA into newStringNoRepl/getBytesNoRepl; the ones in String itself can stay, for they simplify code much. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610464404 From liach at openjdk.org Wed Jun 28 01:49:05 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 28 Jun 2023 01:49:05 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> References: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> Message-ID: On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote: >> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. >> >> Reasons: >> >> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; >> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. > > Glavo 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 seven additional commits since the last revision: > > - Merge branch 'openjdk:master' into latin1-no-repl > - Merge branch 'openjdk:master' into latin1-no-repl > - update javadoc > - clean newStringNoRepl1 > - clean newStringNoRepl1 > - Rename jla to JLA > - Create new method JavaLangAccess::newStringLatin1NoRepl On a side note, `NoRepl` means "no replication", implying the passed array is already trusted. I think you should do something like this instead: public static String readString(Path path, Charset cs) throws IOException { Objects.requireNonNull(path); Objects.requireNonNull(cs); byte[] ba = readAllBytes(path); if (path.getClass().getModule() != Object.class.getModule()) return new String(ba, 0, ba.length, cs); return JLA.newStringNoRepl(ba, cs); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610485537 From alanb at openjdk.org Wed Jun 28 06:12:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jun 2023 06:12:12 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 21:52:08 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - remove unused SOCKET_READ and SOCKET_WRITE configurations. > - Merge branch 'master' into JDK-8308995 > > # Conflicts: > # src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java > - Avoid exceptions getting address/timeout for jfr event. Remove unused > EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious > whitespace. > - some changes from review. > > read0() to implRead() > write0() to implWrite() > trailing whitespace > - fix copyright date > - Added micro benchmark to measure socket event overhead. > - Some changes from review. > > Append a 0 to method names being wrapped. Use getHostString to avoid > a reverse lookup when fetching the hostname of the remote address. > - remove unnecessary cast > - 8308995: Update Network IO JFR events to be static mirror events src/java.base/share/classes/java/net/Socket.java line 1133: > 1131: return parent.getSoTimeout(); > 1132: } catch (Throwable t) { > 1133: // ignored - avoiding exceptions in jfr event data gathering This should be SocketException, not Throwable. That said, I think it would be useful to know why the SocketReadEvent includes the timeout. Is this used to see If read durations are close to the timeout? I assume once this code is fixed to deal with the exceptional case that the need to include the timeout for the success case will mostly go away. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1244728684 From duke at openjdk.org Wed Jun 28 09:02:01 2023 From: duke at openjdk.org (Glavo) Date: Wed, 28 Jun 2023 09:02:01 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4] In-Reply-To: References: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com> Message-ID: On Wed, 28 Jun 2023 01:45:51 GMT, Chen Liang wrote: > On a side note, `NoRepl` means "no replication", implying the passed array is already trusted. I think you should do something like this instead: I think `NoRepl` means "no replace", it's an ambiguous acronym. It cannot be replaced by `new String(byte[], int, int, Charset)` because the constructor will replaces malformed-input and unmappable-character sequences with this charset's default replacement string. I think throwing an exception when malformed or unmappable bytes is encountered is a useful behavior, and maybe a new public API should be provided to users. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1611031664 From lkorinth at openjdk.org Wed Jun 28 17:04:24 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 28 Jun 2023 17:04:24 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files Message-ID: Remove trailing "blank" lines in source files. I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. The fix removes trailing lines matching ^[[:space:]]*$ in - *.java - *.cpp - *.hpp - *.c - *.h I have applied the following bash script to each file: file="$1" while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do truncate -s -1 "$file" done `git diff --ignore-space-change --ignore-blank-lines master` displays no changes `git diff --ignore-blank-lines master` displays one change ------------- Commit messages: - h - c - hpp - cpp - 8311043: Remove trailing blank lines in source files Changes: https://git.openjdk.org/jdk/pull/14698/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14698&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311043 Stats: 4529 lines in 4382 files changed: 0 ins; 4529 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14698/head:pull/14698 PR: https://git.openjdk.org/jdk/pull/14698 From valeriep at openjdk.org Wed Jun 28 18:18:59 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 28 Jun 2023 18:18:59 GMT Subject: [jdk21] RFR: 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC In-Reply-To: <96g545bCO4Wflik7nki1eULkMQ7HniGCHMAA4p4fal4=.e2a1bb73-d55d-4dc8-b83a-5b3481026acc@github.com> References: <96g545bCO4Wflik7nki1eULkMQ7HniGCHMAA4p4fal4=.e2a1bb73-d55d-4dc8-b83a-5b3481026acc@github.com> Message-ID: On Tue, 27 Jun 2023 20:44:01 GMT, Rajan Halade wrote: > This test update should be included in JDK 21 LTS release. Looks good. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk21/pull/74#pullrequestreview-1503703726 From hchao at openjdk.org Wed Jun 28 18:24:01 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 28 Jun 2023 18:24:01 GMT Subject: [jdk21] RFR: 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC In-Reply-To: <96g545bCO4Wflik7nki1eULkMQ7HniGCHMAA4p4fal4=.e2a1bb73-d55d-4dc8-b83a-5b3481026acc@github.com> References: <96g545bCO4Wflik7nki1eULkMQ7HniGCHMAA4p4fal4=.e2a1bb73-d55d-4dc8-b83a-5b3481026acc@github.com> Message-ID: On Tue, 27 Jun 2023 20:44:01 GMT, Rajan Halade wrote: > This test update should be included in JDK 21 LTS release. Marked as reviewed by hchao (Committer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/74#pullrequestreview-1503711317 From rhalade at openjdk.org Wed Jun 28 18:24:02 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 28 Jun 2023 18:24:02 GMT Subject: [jdk21] Integrated: 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC In-Reply-To: <96g545bCO4Wflik7nki1eULkMQ7HniGCHMAA4p4fal4=.e2a1bb73-d55d-4dc8-b83a-5b3481026acc@github.com> References: <96g545bCO4Wflik7nki1eULkMQ7HniGCHMAA4p4fal4=.e2a1bb73-d55d-4dc8-b83a-5b3481026acc@github.com> Message-ID: On Tue, 27 Jun 2023 20:44:01 GMT, Rajan Halade wrote: > This test update should be included in JDK 21 LTS release. This pull request has now been integrated. Changeset: ed98bd7d Author: Rajan Halade URL: https://git.openjdk.org/jdk21/commit/ed98bd7dbd167ba7ac5b7375ba236feeb0d4ad7a Stats: 56 lines in 2 files changed: 43 ins; 1 del; 12 mod 8292704: sun/security/tools/jarsigner/compatibility/Compatibility.java use wrong key size for EC Reviewed-by: valeriep, hchao Backport-of: 130a9f138759c2f8504a83a6f3a93b1f219f0a42 ------------- PR: https://git.openjdk.org/jdk21/pull/74 From tprinzing at openjdk.org Wed Jun 28 18:53:12 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 28 Jun 2023 18:53:12 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: less exception filtering when fetching socket read timeout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14342/files - new: https://git.openjdk.org/jdk/pull/14342/files/27a766c7..d6f7df72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From erikj at openjdk.org Thu Jun 29 07:23:54 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 29 Jun 2023 07:23:54 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14698#pullrequestreview-1504702261 From dholmes at openjdk.org Thu Jun 29 07:43:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jun 2023 07:43:58 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing. It also seems far too large and disruptive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612567676 From erikj at openjdk.org Thu Jun 29 08:00:58 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 29 Jun 2023 08:00:58 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes wrote: > This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing. The patch is leaving exactly one newline at the end of the file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612588091 From alanb at openjdk.org Thu Jun 29 08:31:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jun 2023 08:31:00 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 15:06:45 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey 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: > > - Avoid sharing INDENT variables > - Merge branch 'master' into 8281658-showsettings-security > - Don't allow bad subcommand values for security component > - restore more informative help message > - Split long properties for ; also > - Pass PrintStream to security helper > - Refactor out security code to helper class > - Print aliases. Order Provider type/service output. > - Incorporate review comments from Roger and tweak some code > - Merge branch 'master' into 8281658-showsettings-security > - ... and 5 more: https://git.openjdk.org/jdk/compare/6dc03296...7e6f5090 I looked through the current version (7e6f5090) and you've got it to a good place, the launcher changes look fine. The changes make me wonder if `-XshowSetting:aardvark` should be an error rather than default to print all settings. Something we should look at again. Same thing for `-XshowSettings:system` on non-Linux, probably should have been a bit more discussion when that was added as its more about the container environment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1612623972 From lkorinth at openjdk.org Thu Jun 29 08:58:59 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 08:58:59 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes wrote: > This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing. > > It also seems far too large and disruptive. Do you still think it is too disruptive after Erik's explanation? I could split it in more reviews, but I thought that maybe it would just make the review harder. I was hoping the two `git diff` commands I gave in my first comment in combination with the clean script would make the change seem reviewable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612660457 From asemenov at openjdk.org Thu Jun 29 09:11:05 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 29 Jun 2023 09:11:05 GMT Subject: Integrated: 8308286 Fix clang warnings in linux code In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. This pull request has now been integrated. Changeset: 98a954ee Author: Artem Semenov URL: https://git.openjdk.org/jdk/commit/98a954eebc4f97dd16cb89bd4f1122952c8482ca Stats: 20 lines in 6 files changed: 14 ins; 0 del; 6 mod 8308286: Fix clang warnings in linux code Reviewed-by: avu, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/14033 From coleenp at openjdk.org Thu Jun 29 12:03:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 Jun 2023 12:03:56 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Why do we care about this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613018234 From dholmes at openjdk.org Thu Jun 29 12:14:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jun 2023 12:14:55 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com> On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end. But to me this is too disruptive with no tangible benefit. And you need buy-in from all the different areas affected by this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613043398 From lkorinth at openjdk.org Thu Jun 29 12:38:57 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 12:38:57 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 12:01:03 GMT, Coleen Phillimore wrote: > Why do we care about this? I care because of global-whitespace-cleanup-mode (in emacs). It helps me remove trailing whitespaces and blanklines when saving but it will not fix a file that was "dirty" when it was opened. Trailing blank lines triggers it not to clean whitespaces for me. And it does not look good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613095390 From coleenp at openjdk.org Thu Jun 29 12:42:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 Jun 2023 12:42:56 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change You could fix your emacs functions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613106245 From lkorinth at openjdk.org Thu Jun 29 13:08:59 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 13:08:59 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com> References: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com> Message-ID: On Thu, 29 Jun 2023 12:11:40 GMT, David Holmes wrote: > Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end. My changes look like this in the diff output } - Removal of the last newline would look like this: -} +} \ No newline at end of file (both with `git diff` and `git diff --unified`) I have not tested if this is also true for the generated webrevs, but I think that is precisely how they are created. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613152641 From lkorinth at openjdk.org Thu Jun 29 14:12:55 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 14:12:55 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 12:40:34 GMT, Coleen Phillimore wrote: > You could fix your emacs functions. It is a *very nice* feature of global-whitespace-cleanup-mode ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613252347 From coleenp at openjdk.org Thu Jun 29 15:46:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 Jun 2023 15:46:57 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Per had an emacs feature to remove whitespaces at the end of the line, and gave me the vim version of that. That's a nice feature. I object to this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613437709 From lkorinth at openjdk.org Thu Jun 29 16:55:05 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 16:55:05 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change This was not liked, I will close it. I will possibly do it under another PR for the GC code. Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613526703 From lkorinth at openjdk.org Thu Jun 29 16:55:06 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 16:55:06 GMT Subject: Withdrawn: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14698 From valeriep at openjdk.org Thu Jun 29 18:39:25 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 29 Jun 2023 18:39:25 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v2] In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: <4Lw2xFrG5_EPnoF5oxXORg8ELEx566K79KYGzKNd_Vw=.fd93c479-26dc-4e86-ad18-e51ffbfac727@github.com> On Mon, 26 Jun 2023 22:52:18 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. >> >> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > update for review: changed test, removed commented out code in module, fixed switch statement, added --limit-modules src/java.base/share/classes/sun/security/jca/ProviderConfig.java line 235: > 233: provider = p; > 234: } > 235: return provider; Why changing it to return 'provider', is this change intentional? IIRC, the general pattern is to return the local reference instead of a volatile variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1246975681 From ascarpino at openjdk.org Thu Jun 29 19:58:56 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 29 Jun 2023 19:58:56 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v2] In-Reply-To: <4Lw2xFrG5_EPnoF5oxXORg8ELEx566K79KYGzKNd_Vw=.fd93c479-26dc-4e86-ad18-e51ffbfac727@github.com> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> <4Lw2xFrG5_EPnoF5oxXORg8ELEx566K79KYGzKNd_Vw=.fd93c479-26dc-4e86-ad18-e51ffbfac727@github.com> Message-ID: On Thu, 29 Jun 2023 18:36:55 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> update for review: changed test, removed commented out code in module, fixed switch statement, added --limit-modules > > src/java.base/share/classes/sun/security/jca/ProviderConfig.java line 235: > >> 233: provider = p; >> 234: } >> 235: return provider; > > Why changing it to return 'provider', is this change intentional? IIRC, the general pattern is to return the local reference instead of a volatile variable. Ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1247106719 From prappo at openjdk.org Thu Jun 29 21:25:05 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 29 Jun 2023 21:25:05 GMT Subject: RFR: 8311122: Fix typos in java.base Message-ID: Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. ------------- Commit messages: - Fix copyright years - Initial commit Changes: https://git.openjdk.org/jdk/pull/14718/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14718&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311122 Stats: 23 lines in 13 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/14718.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14718/head:pull/14718 PR: https://git.openjdk.org/jdk/pull/14718 From darcy at openjdk.org Thu Jun 29 21:31:53 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 29 Jun 2023 21:31:53 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. Looks fine, but please give some time for others reviewers before pushing. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506159651 From prappo at openjdk.org Thu Jun 29 21:38:53 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 29 Jun 2023 21:38:53 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:28:39 GMT, Joe Darcy wrote: > Looks fine, but please give some time for others reviewers before pushing. Absolutely! Also, this PR contains a code change (a typo in an error message), which, technically speaking, disqualifies the bug from being "noreg-doc" and requires an appropriate test run. I'll let the PR sit for at least a couple of days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14718#issuecomment-1613838292 From naoto at openjdk.org Thu Jun 29 21:57:51 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 29 Jun 2023 21:57:51 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506183994 From mchung at openjdk.org Thu Jun 29 21:57:52 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 29 Jun 2023 21:57:52 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. Marked as reviewed by mchung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506186255 From iris at openjdk.org Thu Jun 29 22:02:53 2023 From: iris at openjdk.org (Iris Clark) Date: Thu, 29 Jun 2023 22:02:53 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506190678 From prappo at openjdk.org Thu Jun 29 22:51:53 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 29 Jun 2023 22:51:53 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: <0jb07mulxVcJZ5t67l5gSkc44PcceBie-3FAjli-Xj4=.a88f9a10-f954-4770-aebe-6d9f8836563d@github.com> On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. Our CI tests are fine with this change. That said, I'll wait for security-dev to complete the review, and then wait for a few more days so that others could also inspect the change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14718#issuecomment-1613893129 From dholmes at openjdk.org Fri Jun 30 01:24:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jun 2023 01:24:05 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com> Message-ID: On Thu, 29 Jun 2023 13:05:58 GMT, Leo Korinth wrote: > My changes look like this in the diff output > ``` > } > - > ``` Thanks for showing this and other output. To me this looked like the final newline had been removed. I would have expected to see something that more obviously showed more than one blank line before hand and exactly one after. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613985636 From mli at openjdk.org Fri Jun 30 06:39:07 2023 From: mli at openjdk.org (Hamlin Li) Date: Fri, 30 Jun 2023 06:39:07 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. Marked as reviewed by mli (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506596503 From peter.firmstone at zeus.net.au Fri Jun 30 11:26:40 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 30 Jun 2023 21:26:40 +1000 Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: <2c1ddf91-4c0c-537d-90f9-160988ce2d27@zeus.net.au> On 17/06/2023 11:13 pm, Alan Bateman wrote: > On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino wrote: > >> This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. > The proposed changes look okay, meaning it should be okay to have the SunEC provider in java.base. However, the motivation isn't clear as there isn't an issue with JCE providers in java.base using native code. I know there were non-technical issues with libsunec in the past but that would haven't prevent the SunEC code form being compiled into java.base. > > I assume the main implications of the change is that 3rd party JCE providers signed with an EC certificate can now be deployed on the module path. Another way to solve that issue is that delay verification of signed JARs until the boot layer is created - if we did that, would you still want to move the SunEC provider into java.base? Curious, the provider mechanism provides a level of indirection, aka service, a boundary or separation.? How are module boundaries defined? Regards, Peter. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1595748679 From mbaesken at openjdk.org Fri Jun 30 12:36:01 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 30 Jun 2023 12:36:01 GMT Subject: [jdk21] RFR: 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns Message-ID: <5ji-LHKwHTkaSJkjD3ps6IBW2JqUvfmsmK4nWOfN1-U=.7dbfdd42-9e24-4260-b34f-ff631859a8b7@github.com> 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns ------------- Commit messages: - Backport 7da3f1999fc5d1b9162443d97dfae7fe7b04dfc5 Changes: https://git.openjdk.org/jdk21/pull/86/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=86&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310549 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk21/pull/86.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/86/head:pull/86 PR: https://git.openjdk.org/jdk21/pull/86 From dcubed at openjdk.org Fri Jun 30 15:21:10 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jun 2023 15:21:10 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: <1HPsLLkrre-aTNkUCrJ2Os1Ba20NZW-s3bYL1nJU17Q=.47ea0d5b-f382-48a5-ba1b-957a003277d6@github.com> On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Ending the file with a blank line? I would not have expected that at all. I expect a single EOL at the end of the file; from a visual POV, the last line of non-blank text ends with an EOL. No more, no less. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1614806396 From prappo at openjdk.org Fri Jun 30 16:22:57 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 30 Jun 2023 16:22:57 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area Message-ID: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in security area. I understand that security area is sensitive and a non-expert, such as myself, should tread carefully; so below are my notes to assist the review. * Unlike `hashCode`, non-secure `equals` implementations are typically short-circuit. But because of "timing attacks", we seem to have specialized implementations, such as `java.security.MessageDigest.isEqual(byte[], byte[])` and a more general `sun.security.util.ByteArrays.isEqual(byte[], int, int, byte[], int, int)`. So while reviewing this PR, take an opportunity to audit the affected `equals` implementations: perhaps some of them need to become secure, not modern. I have no domain knowledge to tell those cases apart, I only note that those cases exist. * This PR sacrifices compatibility for pragmatism: it changes some `hashCode` implementations to produce different values than before to allow more utilization of methods from `Objects` and `Arrays`. To my mind, those changes are **benign**. If you disagree, I'd be happy to discuss that and/or retract the concerning part of the change. * BitArray could be a topic of its own, but I'll do my best to be concise. * Truth to be told, BitArray's `equals` and `hashCode` are not used anywhere in source, and `equals` is only used in one test. For that reason, I refrained from reimplementing internals of `BitArray` using more general `java.util.BitSet`: too much effort and risk for almost nothing. * Speaking of `BitSet`-powered `BitArray`. Such an implementation is not for the faint of heart: there's too much impedance mismatch between data structures that those classes use to store bits. That said, for the sake of testing that it is possible and that I understand the `BitArray` correctly, I actually implemented it using `BitSet`. While that implementation is **NOT** part of this PR, you can have a look at it [here](https://cr.openjdk.org/~prappo/8311170/BitArray.java). * One suggestion to consider is to change this somewhat arcane piece in java.security.UnresolvedPermission.equals: // check certs if (this.certs == null && that.certs != null || this.certs != null && that.certs == null || this.certs != null && this.certs.length != that.certs.length) { return false; } int i,j; boolean match; for (i = 0; this.certs != null && i < this.certs.length; i++) { match = false; for (j = 0; j < that.certs.length; j++) { if (this.certs[i].equals(that.certs[j])) { match = true; break; } } if (!match) return false; } for (i = 0; that.certs != null && i < that.certs.length; i++) { match = false; for (j = 0; j < this.certs.length; j++) { if (that.certs[i].equals(this.certs[j])) { match = true; break; } } if (!match) return false; } return true; to this: // check certs if (this.certs == null && that.certs != null || this.certs != null && that.certs == null) return false; if (this.certs == null) { assert that.certs == null; return false; } return Set.of(this.certs).equals(Set.of(that.certs)); ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/14738/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311170 Stats: 127 lines in 6 files changed: 16 ins; 73 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/14738.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14738/head:pull/14738 PR: https://git.openjdk.org/jdk/pull/14738 From prappo at openjdk.org Fri Jun 30 18:12:08 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 30 Jun 2023 18:12:08 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v2] In-Reply-To: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: > Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in security area. > > I understand that security area is sensitive and a non-expert, such as myself, should tread carefully; so below are my notes to assist the review. > > * Unlike `hashCode`, non-secure `equals` implementations are typically short-circuit. But because of "timing attacks", we seem to have specialized implementations, such as `java.security.MessageDigest.isEqual(byte[], byte[])` and a more general `sun.security.util.ByteArrays.isEqual(byte[], int, int, byte[], int, int)`. So while reviewing this PR, take an opportunity to audit the affected `equals` implementations: perhaps some of them need to become secure, not modern. I have no domain knowledge to tell those cases apart, I only note that those cases exist. > > * This PR sacrifices compatibility for pragmatism: it changes some `hashCode` implementations to produce different values than before to allow more utilization of methods from `Objects` and `Arrays`. To my mind, those changes are **benign**. If you disagree, I'd be happy to discuss that and/or retract the concerning part of the change. > > * BitArray could be a topic of its own, but I'll do my best to be concise. > > * Truth to be told, BitArray's `equals` and `hashCode` are not used anywhere in source, and `equals` is only used in one test. For that reason, I refrained from reimplementing internals of `BitArray` using more general `java.util.BitSet`: too much effort and risk for almost nothing. > * Speaking of `BitSet`-powered `BitArray`. Such an implementation is not for the faint of heart: there's too much impedance mismatch between data structures that those classes use to store bits. That said, for the sake of testing that it is possible and that I understand the `BitArray` correctly, I actually implemented it using `BitSet`. While that implementation is **NOT** part of this PR, you can have a look at it [here](https://cr.openjdk.org/~prappo/8311170/BitArray.java). > > * One suggestion to consider is to change this somewhat arcane piece in java.security.UnresolvedPermission.equals: > > // check certs > if (this.certs == null && that.certs != null || > this.certs != null && that.certs == null || > this.certs != null && > this.certs.length != that.certs.length) { > return false; > } > > int i,j; > boolean match; > > for (i = 0; this.certs != nu... Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: More cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/36d8347e..0727c264 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=00-01 Stats: 93 lines in 6 files changed: 8 ins; 62 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/14738.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14738/head:pull/14738 PR: https://git.openjdk.org/jdk/pull/14738