From djelinski at openjdk.org Tue Aug 1 07:35:09 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 1 Aug 2023 07:35:09 GMT Subject: RFR: 8313507: Remove pkcs11/Cipher/TestKATForGCM.java from ProblemList Message-ID: The issue linked to ProblemList entry was closed as duplicate of [JDK-8307185](https://bugs.openjdk.org/browse/JDK-8307185), which was fixed. The ProblemList entry should be removed. No failures in 30 test runs. Output of `-Xcheck:jni` clean. ------------- Commit messages: - Remove test from problemlist Changes: https://git.openjdk.org/jdk/pull/15099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313507 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15099/head:pull/15099 PR: https://git.openjdk.org/jdk/pull/15099 From prappo at openjdk.org Tue Aug 1 08:57:56 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 1 Aug 2023 08:57:56 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] 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: Feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/821f617f..678b4dfb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=10-11 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 mullan at openjdk.org Tue Aug 1 11:46:39 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 1 Aug 2023 11:46:39 GMT Subject: RFR: 8313507: Remove pkcs11/Cipher/TestKATForGCM.java from ProblemList In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 07:22:47 GMT, Daniel Jeli?ski wrote: > The issue linked to ProblemList entry was closed as duplicate of [JDK-8307185](https://bugs.openjdk.org/browse/JDK-8307185), which was fixed. The ProblemList entry should be removed. > > No failures in 30 test runs. Output of `-Xcheck:jni` clean. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15099#pullrequestreview-1556798127 From jjiang at openjdk.org Tue Aug 1 13:51:57 2023 From: jjiang at openjdk.org (John Jiang) Date: Tue, 1 Aug 2023 13:51:57 GMT Subject: RFR: 8313226: Redundant condition test in X509CRLImpl In-Reply-To: <1TmXdiiXJPVCo6rNtzNj0-l_LqTYDZtoSQAj0ZEbmbQ=.50fe27bd-7cba-4bad-80a1-138a4c468061@github.com> References: <1TmXdiiXJPVCo6rNtzNj0-l_LqTYDZtoSQAj0ZEbmbQ=.50fe27bd-7cba-4bad-80a1-138a4c468061@github.com> Message-ID: On Thu, 27 Jul 2023 04:00:21 GMT, John Jiang wrote: > if ((nextByte == DerValue.tag_SequenceOf) > && (! ((nextByte & 0x0c0) == 0x080))) { > ... > ... > } > > If `nextByte` is `DerValue.tag_SequenceOf`, exactly `0x30`, then the test after `&&` should always be true. Could this patch be reviewed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15051#issuecomment-1660373553 From jnimeh at openjdk.org Tue Aug 1 15:25:53 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 1 Aug 2023 15:25:53 GMT Subject: RFR: 8313226: Redundant condition test in X509CRLImpl In-Reply-To: <1TmXdiiXJPVCo6rNtzNj0-l_LqTYDZtoSQAj0ZEbmbQ=.50fe27bd-7cba-4bad-80a1-138a4c468061@github.com> References: <1TmXdiiXJPVCo6rNtzNj0-l_LqTYDZtoSQAj0ZEbmbQ=.50fe27bd-7cba-4bad-80a1-138a4c468061@github.com> Message-ID: On Thu, 27 Jul 2023 04:00:21 GMT, John Jiang wrote: > if ((nextByte == DerValue.tag_SequenceOf) > && (! ((nextByte & 0x0c0) == 0x080))) { > ... > ... > } > > If `nextByte` is `DerValue.tag_SequenceOf`, exactly `0x30`, then the test after `&&` should always be true. The change itself looks fine to me since bits 8 and 7 will always be zero when `nextByte` is 0x30. It looks like the second check was to see if the tag was a context-specific tag, but I don't know why since RFC 5280 doesn't indicate that it can be context specific. I wonder if it is a remnant from an earlier version of the code. Regardless, the second clause isn't doing anything so the removal looks good to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15051#pullrequestreview-1557271462 From jjiang at openjdk.org Tue Aug 1 15:52:49 2023 From: jjiang at openjdk.org (John Jiang) Date: Tue, 1 Aug 2023 15:52:49 GMT Subject: RFR: 8313226: Redundant condition test in X509CRLImpl In-Reply-To: References: <1TmXdiiXJPVCo6rNtzNj0-l_LqTYDZtoSQAj0ZEbmbQ=.50fe27bd-7cba-4bad-80a1-138a4c468061@github.com> Message-ID: On Tue, 1 Aug 2023 15:22:48 GMT, Jamil Nimeh wrote: >> if ((nextByte == DerValue.tag_SequenceOf) >> && (! ((nextByte & 0x0c0) == 0x080))) { >> ... >> ... >> } >> >> If `nextByte` is `DerValue.tag_SequenceOf`, exactly `0x30`, then the test after `&&` should always be true. > > The change itself looks fine to me since bits 8 and 7 will always be zero when `nextByte` is 0x30. It looks like the second check was to see if the tag was a context-specific tag, but I don't know why since RFC 5280 doesn't indicate that it can be context specific. I wonder if it is a remnant from an earlier version of the code. > Regardless, the second clause isn't doing anything so the removal looks good to me. @jnimeh Thanks very much for your review! This code snippet has a looooong [history]. It is in the initial commit, and at least 15+ years old. [history]: ------------- PR Comment: https://git.openjdk.org/jdk/pull/15051#issuecomment-1660600286 From mpowers at openjdk.org Tue Aug 1 21:16:01 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 1 Aug 2023 21:16:01 GMT Subject: RFR: JDK-8312461 JNI warnings in SunMSCApi provider Message-ID: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> https://bugs.openjdk.org/browse/JDK-8312461 ------------- Commit messages: - Merge - first iteration Changes: https://git.openjdk.org/jdk/pull/15113/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15113&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312461 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15113/head:pull/15113 PR: https://git.openjdk.org/jdk/pull/15113 From mpowers at openjdk.org Tue Aug 1 21:20:50 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 1 Aug 2023 21:20:50 GMT Subject: RFR: JDK-8312461 JNI warnings in SunMSCApi provider In-Reply-To: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> References: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> Message-ID: On Tue, 1 Aug 2023 21:08:49 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8312461 I was able to reproduce the problem with mach5 and verify that the WARNING was gone after the fix. The hardest thing about this bug was figuring out how to set `-Xcheck:jni` on the mach5 command line. It's not something I do every day. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15113#issuecomment-1661113085 From jjiang at openjdk.org Tue Aug 1 22:38:53 2023 From: jjiang at openjdk.org (John Jiang) Date: Tue, 1 Aug 2023 22:38:53 GMT Subject: Integrated: 8313226: Redundant condition test in X509CRLImpl In-Reply-To: <1TmXdiiXJPVCo6rNtzNj0-l_LqTYDZtoSQAj0ZEbmbQ=.50fe27bd-7cba-4bad-80a1-138a4c468061@github.com> References: <1TmXdiiXJPVCo6rNtzNj0-l_LqTYDZtoSQAj0ZEbmbQ=.50fe27bd-7cba-4bad-80a1-138a4c468061@github.com> Message-ID: On Thu, 27 Jul 2023 04:00:21 GMT, John Jiang wrote: > if ((nextByte == DerValue.tag_SequenceOf) > && (! ((nextByte & 0x0c0) == 0x080))) { > ... > ... > } > > If `nextByte` is `DerValue.tag_SequenceOf`, exactly `0x30`, then the test after `&&` should always be true. This pull request has now been integrated. Changeset: 28be34c1 Author: John Jiang URL: https://git.openjdk.org/jdk/commit/28be34c1b9179e21c8ec5d2f9b05e3f842bb30a1 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8313226: Redundant condition test in X509CRLImpl Reviewed-by: jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/15051 From xuelei at openjdk.org Wed Aug 2 00:49:02 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 2 Aug 2023 00:49:02 GMT Subject: RFR: 8312259: StatusResponseManager unused code clean up [v3] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 18:03:22 GMT, Sean Mullan wrote: > I think @jnimeh should review this, as I think these methods were added when implementing OCSP Stapling, and it would be good for him to make sure they are no longer needed.. @jnimeh Did you have a chance to have a look at this update? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14924#issuecomment-1661296222 From djelinski at openjdk.org Wed Aug 2 05:48:55 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 2 Aug 2023 05:48:55 GMT Subject: Integrated: 8313507: Remove pkcs11/Cipher/TestKATForGCM.java from ProblemList In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 07:22:47 GMT, Daniel Jeli?ski wrote: > The issue linked to ProblemList entry was closed as duplicate of [JDK-8307185](https://bugs.openjdk.org/browse/JDK-8307185), which was fixed. The ProblemList entry should be removed. > > No failures in 30 test runs. Output of `-Xcheck:jni` clean. This pull request has now been integrated. Changeset: e8471f6b Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/e8471f6bbe692a0d1e293f9e09aaa4f32312eb6a Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8313507: Remove pkcs11/Cipher/TestKATForGCM.java from ProblemList Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/15099 From clanger at openjdk.org Wed Aug 2 06:50:19 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 2 Aug 2023 06:50:19 GMT Subject: [jdk21] RFR: 8309088: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails Message-ID: Hi all, This pull request contains a backport of [JDK-8309088](https://bugs.openjdk.org/browse/JDK-8309088), commit [4c2e54fb](https://github.com/openjdk/jdk/commit/4c2e54fb055bee0af5cd838fdd32a0f7902d51e3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Rajan Halade on 26 Jul 2023 and was reviewed by Sean Mullan. It is a test fix, so viable for inclusion in OpenJDK 21. Thanks! ------------- Commit messages: - Backport 4c2e54fb055bee0af5cd838fdd32a0f7902d51e3 Changes: https://git.openjdk.org/jdk21/pull/159/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309088 Stats: 491 lines in 1 file changed: 142 ins; 30 del; 319 mod Patch: https://git.openjdk.org/jdk21/pull/159.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/159/head:pull/159 PR: https://git.openjdk.org/jdk21/pull/159 From mbaesken at openjdk.org Wed Aug 2 07:20:52 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 07:20:52 GMT Subject: [jdk21] RFR: 8309088: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 06:42:29 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of [JDK-8309088](https://bugs.openjdk.org/browse/JDK-8309088), commit [4c2e54fb](https://github.com/openjdk/jdk/commit/4c2e54fb055bee0af5cd838fdd32a0f7902d51e3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 26 Jul 2023 and was reviewed by Sean Mullan. > > It is a test fix, so viable for inclusion in OpenJDK 21. > > Thanks! Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/159#pullrequestreview-1558357436 From yzheng at openjdk.org Wed Aug 2 11:05:12 2023 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 2 Aug 2023 11:05:12 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11] In-Reply-To: References: Message-ID: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com> On Wed, 21 Oct 2020 23:42:33 GMT, Fei Yang wrote: >> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com >> >> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. >> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 >> >> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. >> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. >> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. >> >> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. >> Patch passed jtreg tier1-3 tests with QEMU system emulator. >> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression. >> >> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java >> We measured the performance benefit with an aarch64 cycle-accurate simulator. >> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. >> >> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected. > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473: > 3471: __ bcax(v24, __ T16B, v24, v8, v31); > 3472: > 3473: __ ld1r(v31, __ T2D, __ post(rscratch1, 8)); is it intentional to load 16 bytes and post-increment by 8? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281749663 From duke at openjdk.org Wed Aug 2 12:37:13 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 2 Aug 2023 12:37:13 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11] In-Reply-To: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com> References: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com> Message-ID: On Wed, 2 Aug 2023 11:02:07 GMT, Yudi Zheng wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473: > >> 3471: __ bcax(v24, __ T16B, v24, v8, v31); >> 3472: >> 3473: __ ld1r(v31, __ T2D, __ post(rscratch1, 8)); > > is it intentional to load 16 bytes and post-increment by 8? Actually, with the ld1r instruction the post increment should be the same as the size of the memory accessed. So T2D requires 8 as it reads 8 bytes(and duplicates it into both halves of the SIMD register). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281840355 From yzheng at openjdk.org Wed Aug 2 14:10:13 2023 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 2 Aug 2023 14:10:13 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11] In-Reply-To: References: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com> Message-ID: On Wed, 2 Aug 2023 12:33:43 GMT, Ferenc Rakoczi wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473: >> >>> 3471: __ bcax(v24, __ T16B, v24, v8, v31); >>> 3472: >>> 3473: __ ld1r(v31, __ T2D, __ post(rscratch1, 8)); >> >> is it intentional to load 16 bytes and post-increment by 8? > > Actually, with the ld1r instruction the post increment should be the same as the size of the memory accessed. So T2D requires 8 as it reads 8 bytes(and duplicates it into both halves of the SIMD register). Thanks for the clarification! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281961206 From jnimeh at openjdk.org Wed Aug 2 16:52:57 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 2 Aug 2023 16:52:57 GMT Subject: RFR: 8312259: StatusResponseManager unused code clean up [v3] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 00:45:36 GMT, Xue-Lei Andrew Fan wrote: >> I think @jnimeh should review this, as I think these methods were added when implementing OCSP Stapling, and it would be good for him to make sure they are no longer needed.. > >> I think @jnimeh should review this, as I think these methods were added when implementing OCSP Stapling, and it would be good for him to make sure they are no longer needed.. > > @jnimeh Did you have a chance to have a look at this update? @XueleiFan I will have time to review this today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14924#issuecomment-1662578602 From rhalade at openjdk.org Wed Aug 2 17:57:48 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 2 Aug 2023 17:57:48 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution Message-ID: I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. ------------- Commit messages: - 8313206: mark skipped only when all three tests are skipped - Merge branch 'master' into 8313206-pkcs11skip - 8313206: add test trace messages - 8313206: PKCS11 tests silently skip execution Changes: https://git.openjdk.org/jdk/pull/15125/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313206 Stats: 340 lines in 8 files changed: 168 ins; 84 del; 88 mod Patch: https://git.openjdk.org/jdk/pull/15125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15125/head:pull/15125 PR: https://git.openjdk.org/jdk/pull/15125 From tprinzing at openjdk.org Wed Aug 2 18:22:53 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 2 Aug 2023 18:22:53 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 18:53:12 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 incrementally with one additional commit since the last revision: > > less exception filtering when fetching socket read timeout I believe this has all requested changes or has separate bug reports to address changes yet needing to be made. https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops This request has been patiently waiting for approval for a long time! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1662726848 From alanb at openjdk.org Wed Aug 2 20:12:51 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Aug 2023 20:12:51 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 18:19:27 GMT, Tim Prinzing wrote: > I believe this has all requested changes or has separate bug reports to address changes yet needing to be made. https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops > > This request has been patiently waiting for approval for a long time! I plan to come back to this soon, been busy with other things. It's good to have JBS issues created for the next steps. I assume you can start to prepare the changes for the next steps so that all the pieces can go into the same release. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1662903292 From egahlin at openjdk.org Wed Aug 2 21:12:44 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 2 Aug 2023 21:12:44 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 18:53:12 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 incrementally with one additional commit since the last revision: > > less exception filtering when fetching socket read timeout Looks good as far as I can tell. I would perhaps name the checkForCommit(...) method commitEvent(...) to make it more clear that it writes the event, but it's not a big thing. ------------- Marked as reviewed by egahlin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1559847776 From rhalade at openjdk.org Wed Aug 2 22:04:06 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 2 Aug 2023 22:04:06 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v2] In-Reply-To: References: Message-ID: > I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. > > Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: 8313206: update Secmod tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15125/files - new: https://git.openjdk.org/jdk/pull/15125/files/9a32e850..382a57f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=00-01 Stats: 46 lines in 9 files changed: 15 ins; 2 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/15125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15125/head:pull/15125 PR: https://git.openjdk.org/jdk/pull/15125 From rhalade at openjdk.org Wed Aug 2 22:27:05 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 2 Aug 2023 22:27:05 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v3] In-Reply-To: References: Message-ID: > I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. > > Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: 8313206: revert skipTest update to address with new bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15125/files - new: https://git.openjdk.org/jdk/pull/15125/files/382a57f2..a950638a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15125/head:pull/15125 PR: https://git.openjdk.org/jdk/pull/15125 From bpb at openjdk.org Wed Aug 2 22:51:36 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 2 Aug 2023 22:51:36 GMT Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v3] In-Reply-To: <5k4VFVI74A2cbypxW01WHS1-jRPs0LCCmnT8sfQEomM=.1f19c199-0531-46f4-9b44-3ddccb053d69@github.com> References: <5k4VFVI74A2cbypxW01WHS1-jRPs0LCCmnT8sfQEomM=.1f19c199-0531-46f4-9b44-3ddccb053d69@github.com> Message-ID: <6KOz3IGCWd19RLyu521tmQ-W7yf1i_ReEI6hpmCzCDw=.ff8b20e5-a602-44fc-bde3-713f41428556@github.com> On Sun, 30 Jul 2023 13:06:36 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy > > src/java.base/share/classes/java/io/FileOutputStream.java line 347: > >> 345: pos += n; >> 346: remaining -= n; >> 347: } while (remaining > 0); > > Long standing behavior is that write is a no-op with len is 0, meaning you can do while here (no need to change it to do-while). Same thing in RAF. So changed in cdb8455ccbd1db49d272e867b16a14eb72b41a7b. > src/java.base/share/native/libjava/io_util.c line 160: > >> 158: } >> 159: >> 160: if (outOfBounds(env, off, len, bytes)) { > > I assume the IS_NULL and outOfBounds checking in both readBytes and writeBytes are redundant now. Right. Removed in cdb8455ccbd1db49d272e867b16a14eb72b41a7b. > src/java.base/share/native/libjava/io_util.c line 183: > >> 181: if (fd == -1) { >> 182: JNU_ThrowIOException(env, "Stream Closed"); >> 183: nwritten = -1; > > nwritten is initialized to -1. Removed in cdb8455ccbd1db49d272e867b16a14eb72b41a7b. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1279618127 PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1279617787 PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1279618406 From ssahoo at openjdk.org Thu Aug 3 07:36:33 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 3 Aug 2023 07:36:33 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v3] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 22:27:05 GMT, Rajan Halade wrote: >> I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. >> >> Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > 8313206: revert skipTest update to address with new bug test/jdk/sun/security/pkcs11/KeyStore/SecretKeysBasic.java line 70: > 68: main(new SecretKeysBasic()); > 69: } catch (SkippedException se) { > 70: throw new SkipException("One or more tests are skipped"); SkipException is only thrown when all cases skipped in PKCS11Test.main() Line: 215-218. Individual test case skip process are handled with print and flag set in PKCS11Test.main() Line:191-213. So it is not thrown. If it is handled in base class PKCS11Test.main() then these changes in each Test not required. test/jdk/sun/security/pkcs11/PKCS11Test.java line 215: > 213: } > 214: > 215: if (skippedDefault && skippedNSS && skippedDeimos) { Should this be || instead of && and the exception message to be "one or more test case skipped" test/jdk/sun/security/pkcs11/PKCS11Test.java line 277: > 275: Provider[] providers = Security.getProviders(); > 276: for (Provider p : providers) { > 277: if (p.getName().startsWith("SunPKCS11-")) { Please correct me, if i am wrong. But as per my understanding there can be many PKCS11 provider instance exist in same time based on different token configuration and the order can be different too. In that case specifying the default PKCS11 provider could be better which is 'p.getName().equals("SunPKCS11")'. Here it is safe because testDefault() is the 1st method to execute. Also the loop should break immediately after finding the default provider. test/jdk/sun/security/pkcs11/Secmod/TrustAnchors.java line 49: > 47: > 48: public static void main(String[] args) throws Exception { > 49: if (!initSecmod()) { 'throw new SkippedException' could be defined in SecmodTest.initSecmod() method to avoid all these Tests to take care separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1282718003 PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1282719721 PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1282773066 PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1282706705 From clanger at openjdk.org Thu Aug 3 07:43:34 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 3 Aug 2023 07:43:34 GMT Subject: [jdk21] Integrated: 8309088: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 06:42:29 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of [JDK-8309088](https://bugs.openjdk.org/browse/JDK-8309088), commit [4c2e54fb](https://github.com/openjdk/jdk/commit/4c2e54fb055bee0af5cd838fdd32a0f7902d51e3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 26 Jul 2023 and was reviewed by Sean Mullan. > > It is a test fix, so viable for inclusion in OpenJDK 21. > > Thanks! This pull request has now been integrated. Changeset: f5320429 Author: Christoph Langer URL: https://git.openjdk.org/jdk21/commit/f532042919f3117dce32586cd69edebd075a5205 Stats: 491 lines in 1 file changed: 142 ins; 30 del; 319 mod 8309088: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails Reviewed-by: mbaesken Backport-of: 4c2e54fb055bee0af5cd838fdd32a0f7902d51e3 ------------- PR: https://git.openjdk.org/jdk21/pull/159 From ssahoo at openjdk.org Thu Aug 3 07:59:33 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 3 Aug 2023 07:59:33 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v3] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 22:27:05 GMT, Rajan Halade wrote: >> I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. >> >> Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > 8313206: revert skipTest update to address with new bug Mach5 result doesn't contain some of affected Tests. Ex: if i search with query string as "name:sun/security/pkcs11/KeyStore/Basic.java" there is no result but 'name:sun/security/pkcs11/SampleTest.java' gives result ------------- PR Comment: https://git.openjdk.org/jdk/pull/15125#issuecomment-1663472024 From ssahoo at openjdk.org Thu Aug 3 09:57:31 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 3 Aug 2023 09:57:31 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v3] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 22:27:05 GMT, Rajan Halade wrote: >> I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. >> >> Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. > > Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: > > 8313206: revert skipTest update to address with new bug test/jdk/sun/security/pkcs11/PKCS11Test.java line 973: > 971: return r; > 972: } > 973: I am not sure if 'NO_DEFAULT' expected to be true in setCommonSystemProps() Line:977 or it need to be explicitly reset by each Test where testDefault() expected to be executed, System.setProperty("NO_DEFAULT", "true"); If it is supposed to be true then the testDefault() will always get skipped with the following condition, Line:270-273 is will return before proceeding to test the default provider, if ("true".equals(System.getProperty("NO_DEFAULT"))) { System.out.println("Skip default provider as test configured with NO_DEFAULT"); return; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1282942139 From ssahoo at openjdk.org Thu Aug 3 10:07:32 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 3 Aug 2023 10:07:32 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v3] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 09:46:48 GMT, Sibabrata Sahoo wrote: >> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: >> >> 8313206: revert skipTest update to address with new bug > > test/jdk/sun/security/pkcs11/PKCS11Test.java line 973: > >> 971: return r; >> 972: } >> 973: > > I am not sure if 'NO_DEFAULT' expected to be true in setCommonSystemProps() Line:977 or it need to be explicitly reset by each Test where testDefault() expected to be executed, > System.setProperty("NO_DEFAULT", "true"); > > If it is supposed to be true then the testDefault() will always get skipped with the following condition, > Line:270-273 is will return before proceeding to test the default provider, > if ("true".equals(System.getProperty("NO_DEFAULT"))) { > System.out.println("Skip default provider as test configured with NO_DEFAULT"); > return; > } I see few Tests use "-DNO_DEIMOS=true -DNO_DEFAULT=true" in @run tag when they don't want the specific provider to be used. In that case Line:977 System.setProperty("NO_DEFAULT", "true"); is expected to be "false" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1282974501 From rhalade at openjdk.org Thu Aug 3 17:12:38 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 3 Aug 2023 17:12:38 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v3] In-Reply-To: References: Message-ID: <8M5vdK5IwLuDcaP2TfiUOhQ4nJB-MCillfgNtr1r65w=.6c9097ef-e4bd-41c3-9f5f-638fccedfc84@github.com> On Thu, 3 Aug 2023 06:40:27 GMT, Sibabrata Sahoo wrote: >> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: >> >> 8313206: revert skipTest update to address with new bug > > test/jdk/sun/security/pkcs11/KeyStore/SecretKeysBasic.java line 70: > >> 68: main(new SecretKeysBasic()); >> 69: } catch (SkippedException se) { >> 70: throw new SkipException("One or more tests are skipped"); > > SkipException is only thrown when all cases skipped in PKCS11Test.main() Line: 215-218. > Individual test case skip process are handled with print and flag set in PKCS11Test.main() Line:191-213. So it is not thrown. > If it is handled in base class PKCS11Test.main() then these changes in each Test not required. These changes are needed to individual tests as they are TestNG tests. If test doesn't mask SkippedException to TestNG SkipException then test will be marked as failed than skipped by TestNG. > test/jdk/sun/security/pkcs11/PKCS11Test.java line 277: > >> 275: Provider[] providers = Security.getProviders(); >> 276: for (Provider p : providers) { >> 277: if (p.getName().startsWith("SunPKCS11-")) { > > Please correct me, if i am wrong. But as per my understanding there can be many PKCS11 provider instance exist in same time based on different token configuration and the order can be different too. They all have name similarity which starts with "SunPKCS11-" followed by a vendor specific name. In that case specifying the default PKCS11 provider name could be better which is 'p.getName().equals("SunPKCS11")'. Also the loop should break immediately after finding the default provider. As is currently, test is run for all found providers. I am avoiding to update existing test logic with this change. I will consider this update while working on [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575). More TBD ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1283491635 PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1283491422 From rhalade at openjdk.org Thu Aug 3 17:12:40 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 3 Aug 2023 17:12:40 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v3] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 10:04:17 GMT, Sibabrata Sahoo wrote: >> test/jdk/sun/security/pkcs11/PKCS11Test.java line 973: >> >>> 971: return r; >>> 972: } >>> 973: >> >> I am not sure if 'NO_DEFAULT' expected to be true in setCommonSystemProps() Line:977 or it need to be explicitly reset by each Test where testDefault() expected to be executed, >> System.setProperty("NO_DEFAULT", "true"); >> >> If it is supposed to be true then the testDefault() will always get skipped with the following condition, >> Line:270-273 is will return before proceeding to test the default provider, >> if ("true".equals(System.getProperty("NO_DEFAULT"))) { >> System.out.println("Skip default provider as test configured with NO_DEFAULT"); >> return; >> } > > I see few Tests use "-DNO_DEIMOS=true -DNO_DEFAULT=true" in @run tag when they don't want the specific provider to be used. In that case Line:977 System.setProperty("NO_DEFAULT", "true"); is expected to be "false"? There is no change to this logic. Yes, some tests are configured to Skip Deimos and Default run. It is inconsistent as few tests call setCommonSystemProps() and others are setting System property. But, this update has no change to this code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1283491277 From rhalade at openjdk.org Thu Aug 3 17:20:00 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 3 Aug 2023 17:20:00 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v4] In-Reply-To: References: Message-ID: <4Gj1E6B2P0w6mtx-86Zp_LN9R0xYpT686WtdLNrcl8U=.b82b533b-65d0-497a-87ba-3ab4d6ee5e86@github.com> > I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. > > Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. Rajan Halade has updated the pull request incrementally with two additional commits since the last revision: - Address review comments - 1 - Address review comments - 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15125/files - new: https://git.openjdk.org/jdk/pull/15125/files/a950638a..124f9a5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=02-03 Stats: 53 lines in 9 files changed: 5 ins; 18 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/15125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15125/head:pull/15125 PR: https://git.openjdk.org/jdk/pull/15125 From ssahoo at openjdk.org Thu Aug 3 18:43:30 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 3 Aug 2023 18:43:30 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v3] In-Reply-To: <8M5vdK5IwLuDcaP2TfiUOhQ4nJB-MCillfgNtr1r65w=.6c9097ef-e4bd-41c3-9f5f-638fccedfc84@github.com> References: <8M5vdK5IwLuDcaP2TfiUOhQ4nJB-MCillfgNtr1r65w=.6c9097ef-e4bd-41c3-9f5f-638fccedfc84@github.com> Message-ID: <-EIuAc6wkzbrV51kX5a-CGGVhfm8M0ArAf6CFlMApKU=.39680d38-2191-4c78-b2a6-0f0e924d0b2d@github.com> On Thu, 3 Aug 2023 17:09:33 GMT, Rajan Halade wrote: >> test/jdk/sun/security/pkcs11/PKCS11Test.java line 277: >> >>> 275: Provider[] providers = Security.getProviders(); >>> 276: for (Provider p : providers) { >>> 277: if (p.getName().startsWith("SunPKCS11-")) { >> >> Please correct me, if i am wrong. But as per my understanding there can be many PKCS11 provider instance exist in same time based on different token configuration and the order can be different too. They all have name similarity which starts with "SunPKCS11-" followed by a vendor specific name. In that case specifying the default PKCS11 provider name could be better which is 'p.getName().equals("SunPKCS11")'. Also the loop should break immediately after finding the default provider. > > As is currently, test is run for all found providers. I am avoiding to update existing test logic with this change. I will consider this update while working on [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575). More TBD "SunPKCS11-" is wrong as default provider name itself. Because the default provider name is "SunPKCS11". Here 'default' as i understand the provider comes from JDK implementation. Someone may correct me here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15125#discussion_r1283582326 From valeriep at openjdk.org Thu Aug 3 20:58:49 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 3 Aug 2023 20:58:49 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 Message-ID: This change addresses the scenario where a certificate is first stored as part of a certificate chain and then stored again as a certificate corresponding to a PrivateKey entry. Newer version of NSS errors out with CKR_GENERAL_ERROR with the 2nd store, i.e. C_CreateObject() call. Proposed fix is to check for match before calling C_CreateObject(), if a match is found, set its alias instead. ------------- Commit messages: - 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 Changes: https://git.openjdk.org/jdk/pull/15146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309214 Stats: 53 lines in 2 files changed: 39 ins; 12 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15146/head:pull/15146 PR: https://git.openjdk.org/jdk/pull/15146 From valeriep at openjdk.org Thu Aug 3 21:46:35 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 3 Aug 2023 21:46:35 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: <9ypMLa_ZY5cFzuFNODsDdqGbHpBd_UZ2dZkABesROZM=.10a3fc11-9374-4d6d-aabe-da89f852e48a@github.com> On Tue, 1 Aug 2023 08:57:56 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback src/java.base/share/classes/sun/security/x509/PolicyInformation.java line 140: > 138: @Override > 139: public int hashCode() { > 140: return Objects.hash(policyIdentifier, policyQualifiers); What is the criteria for changing the hashCode() impl? It seems that you change some and not others. With the many hashCode() impls (e.g. Objects.hash(), Arrays.hashCode()), I wonder why this and not that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1283749411 From valeriep at openjdk.org Thu Aug 3 22:52:37 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 3 Aug 2023 22:52:37 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Tue, 1 Aug 2023 08:57:56 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 272: > 270: } > 271: > 272: if (!(that.getAlgorithm().equalsIgnoreCase(getAlgorithm()))){ why removing the space before the "{"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1283791490 From valeriep at openjdk.org Fri Aug 4 00:06:34 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 4 Aug 2023 00:06:34 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Tue, 1 Aug 2023 08:57:56 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback src/java.base/share/classes/sun/security/provider/certpath/CertId.java line 182: > 180: myhash += Arrays.hashCode(issuerNameHash); > 181: myhash += Arrays.hashCode(issuerKeyHash); > 182: myhash += certSerialNumber.getNumber().hashCode(); It seems that for some other classes, you may just use Objects.hash(hashAlgId, issuerNameHash, issuerKeyHash, certSerialNumber.getNumber())? Is there a rule on what to use? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1283830903 From djelinski at openjdk.org Fri Aug 4 08:39:46 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 4 Aug 2023 08:39:46 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters Message-ID: Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. Tier1-3 tests pass. ------------- Commit messages: - Add test, send alert Changes: https://git.openjdk.org/jdk/pull/15148/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293176 Stats: 99 lines in 2 files changed: 98 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15148/head:pull/15148 PR: https://git.openjdk.org/jdk/pull/15148 From prappo at openjdk.org Fri Aug 4 09:38:38 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 4 Aug 2023 09:38:38 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Thu, 3 Aug 2023 22:49:46 GMT, Valerie Peng wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback > > src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 272: > >> 270: } >> 271: >> 272: if (!(that.getAlgorithm().equalsIgnoreCase(getAlgorithm()))){ > > why removing the space before the "{"? It surprises me as much as it probably surprises you. Looks like a sloppy merge (821f617ffae) on my part. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284208096 From mbaesken at openjdk.org Fri Aug 4 10:50:30 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Aug 2023 10:50:30 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote: > This change addresses the scenario where a certificate is first stored as part of a certificate chain and then stored again as a certificate corresponding to a PrivateKey entry. Newer version of NSS errors out with CKR_GENERAL_ERROR with the 2nd store, i.e. C_CreateObject() call. > > Proposed fix is to check for match before calling C_CreateObject(), if a match is found, set its alias instead. Hi Valerie, we put the PR into our build/test queue to check if it solves some errors we currently notice in CertChainRemoval.java . ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1665411026 From prappo at openjdk.org Fri Aug 4 11:04:45 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 4 Aug 2023 11:04:45 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Fri, 4 Aug 2023 09:35:54 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 272: >> >>> 270: } >>> 271: >>> 272: if (!(that.getAlgorithm().equalsIgnoreCase(getAlgorithm()))){ >> >> why removing the space before the "{"? > > It surprises me as much as it probably surprises you. Looks like a sloppy merge (821f617ffae) on my part. I retraced my steps to see how the merge introduced that artefact. This might be useful to others too. The original merge was done via an IDE, which has this (usually) helpful 1-click feature called "Resolve Simple Conflicts". It's that feature that ate that whitespace character. To its credit, the rest of the resolution seems to have been done correctly. When I examined the original merge before pushing it to the PR, I didn't spot that whitespace; my bad. I'll reintroduce it. Thanks for your careful review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284285619 From prappo at openjdk.org Fri Aug 4 15:05:36 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 4 Aug 2023 15:05:36 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: <9ypMLa_ZY5cFzuFNODsDdqGbHpBd_UZ2dZkABesROZM=.10a3fc11-9374-4d6d-aabe-da89f852e48a@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <9ypMLa_ZY5cFzuFNODsDdqGbHpBd_UZ2dZkABesROZM=.10a3fc11-9374-4d6d-aabe-da89f852e48a@github.com> Message-ID: On Thu, 3 Aug 2023 21:43:44 GMT, Valerie Peng wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback > > src/java.base/share/classes/sun/security/x509/PolicyInformation.java line 140: > >> 138: @Override >> 139: public int hashCode() { >> 140: return Objects.hash(policyIdentifier, policyQualifiers); > > What is the criteria for changing the hashCode() impl? It seems that you change some and not others. With the many hashCode() impls (e.g. Objects.hash(), Arrays.hashCode()), I wonder why this and not that. Whether I suggest changing hashCode or not depends on multiple criteria, of which these two are the most important: * Is the value specified or relied upon? * Does it need to be performant? If the answer to both of these is "NO", I might refactor hashCode. One unintended side effect, is that sometimes such a refactoring improves hashCode quality (think: perfect hashing) almost for free. If you have concerns on particular refactorings, I'd be happy to discuss them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284535886 From prappo at openjdk.org Fri Aug 4 15:14:38 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 4 Aug 2023 15:14:38 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Fri, 4 Aug 2023 00:04:03 GMT, Valerie Peng wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback > > src/java.base/share/classes/sun/security/provider/certpath/CertId.java line 182: > >> 180: myhash += Arrays.hashCode(issuerNameHash); >> 181: myhash += Arrays.hashCode(issuerKeyHash); >> 182: myhash += certSerialNumber.getNumber().hashCode(); > > It seems that for some other classes, you may just use Objects.hash(hashAlgId, issuerNameHash, issuerKeyHash, certSerialNumber.getNumber())? Is there a rule on what to use? We can be more aggressive in some refactorings, but I note that if any of the hashCode components are arrays, the proper, albeit slightly inconvenient way to combine all the components would be `Arrays.deepHashCode(Object[])`, not `Objects.hash(Object... values)` or `Arrays.hashCode(Object[])`. The latter two don't recurse into arrays, but use their "shallow" hashCode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284546168 From hchao at openjdk.org Fri Aug 4 17:37:40 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 4 Aug 2023 17:37:40 GMT Subject: RFR: 8311596: Add separate system properties for TLS server and client for maximum chain length Message-ID: Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you. ------------- Commit messages: - 8311596: Add separate system properties for TLS server and client for maximum chain length Changes: https://git.openjdk.org/jdk/pull/15163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311596 Stats: 39 lines in 2 files changed: 33 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15163/head:pull/15163 PR: https://git.openjdk.org/jdk/pull/15163 From mullan at openjdk.org Fri Aug 4 19:48:37 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Aug 2023 19:48:37 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Tue, 1 Aug 2023 08:57:56 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback src/java.base/share/classes/com/sun/crypto/provider/DESKey.java line 113: > 111: public int hashCode() { > 112: int retval = 0; > 113: for (int i = 1; i < this.key.length; i++) { I don't really know why the hashCode impl skipped the first byte of the array. Source code history doesn't give any insight. I thought maybe this had something to do with the parity bits (8 bits of a DES key are used for parity) but those are every 8th bit, and not all in the first byte. Best I can guess is that this is just an oversight and it should have included all bytes in the hash code calculation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284794273 From mullan at openjdk.org Fri Aug 4 19:57:39 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Aug 2023 19:57:39 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <9ypMLa_ZY5cFzuFNODsDdqGbHpBd_UZ2dZkABesROZM=.10a3fc11-9374-4d6d-aabe-da89f852e48a@github.com> Message-ID: On Fri, 4 Aug 2023 15:01:51 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/sun/security/x509/PolicyInformation.java line 140: >> >>> 138: @Override >>> 139: public int hashCode() { >>> 140: return Objects.hash(policyIdentifier, policyQualifiers); >> >> What is the criteria for changing the hashCode() impl? It seems that you change some and not others. With the many hashCode() impls (e.g. Objects.hash(), Arrays.hashCode()), I wonder why this and not that. > > Whether I suggest changing hashCode or not depends on multiple criteria, of which these two are the most important: > > * Is the value specified or relied upon? > * Does it need to be performant? > > If the answer to both of these is "NO", I might refactor hashCode. One unintended side effect, is that sometimes such a refactoring improves hashCode quality (think: perfect hashing) almost for free. > > If you have concerns on particular refactorings, I'd be happy to discuss them. I would add to that list that I think it is really important any change to the `hashCode` impl doesn't break the equals/hashCode contract, so it's important to look at the `equals` implementation in conjunction with any changes to `hashCode`, mostly to ensure 2 equal objects continue to have the same hash code. It is also important to question any oddity about the `hashCode` impl, like I did for DESKey and try to understand why it may have been implemented that way, such as skipping the first byte. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284801790 From prappo at openjdk.org Fri Aug 4 20:55:39 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 4 Aug 2023 20:55:39 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Fri, 4 Aug 2023 19:45:34 GMT, Sean Mullan wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback > > src/java.base/share/classes/com/sun/crypto/provider/DESKey.java line 113: > >> 111: public int hashCode() { >> 112: int retval = 0; >> 113: for (int i = 1; i < this.key.length; i++) { > > I don't really know why the hashCode impl skipped the first byte of the array. Source code history doesn't give any insight. I thought maybe this had something to do with the parity bits (8 bits of a DES key are used for parity) but those are every 8th bit, and not all in the first byte. Best I can guess is that this is just an oversight and it should have included all bytes in the hash code calculation. Thanks for checking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284838423 From prappo at openjdk.org Fri Aug 4 20:55:40 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 4 Aug 2023 20:55:40 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <9ypMLa_ZY5cFzuFNODsDdqGbHpBd_UZ2dZkABesROZM=.10a3fc11-9374-4d6d-aabe-da89f852e48a@github.com> Message-ID: On Fri, 4 Aug 2023 19:54:58 GMT, Sean Mullan wrote: > I would add to that list that I think it is really important any change to the `hashCode` impl doesn't break the equals/hashCode contract, so it's important to look at the `equals` implementation in conjunction with any changes to `hashCode`, mostly to ensure 2 equal objects continue to have the same hash code. True. I skipped that criteria, as I thought it should go without saying. > It is also important to question any oddity about the `hashCode` impl, like I did for DESKey and try to understand why it may have been implemented that way, such as skipping the first byte. True again. If you have any other examples where the changes to hashCode look suspicious, please tell me so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284837771 From valeriep at openjdk.org Fri Aug 4 21:34:41 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 4 Aug 2023 21:34:41 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: <-h9k8EM8BeTYVOtt5OklxaG8Ul1r8ay5H9xU9vy1HUY=.9f6e9cc0-f21c-497f-bc20-a397cbda693a@github.com> On Tue, 1 Aug 2023 08:57:56 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java line 105: > 103: return false; > 104: if (address != null && h.address != null) { > 105: return Arrays.equals(address, h.address); Can't this block be combined into: return` addrType == h.addrType && Arrays.equals(address, h.address); `? src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddresses.java line 156: > 154: return false; > 155: if (addresses != null && addrs.addresses != null) { > 156: return Arrays.equals(addresses, addrs.addresses); Same comment as above, i.e. combined into one return condition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284861469 PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284862108 From valeriep at openjdk.org Fri Aug 4 21:43:39 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 4 Aug 2023 21:43:39 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Tue, 1 Aug 2023 08:57:56 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java line 523: > 521: if (crealm != null) result = 37 * result + crealm.hashCode(); > 522: if (cname != null) result = 37 * result + cname.hashCode(); > 523: if (sname != null) result = 37 * result + sname.hashCode(); Why changing the ordering? I was wondering if you'd change this to Objects.hash(...) with all the fields as arguments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284866640 From prappo at openjdk.org Fri Aug 4 22:03:37 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 4 Aug 2023 22:03:37 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Fri, 4 Aug 2023 21:40:37 GMT, Valerie Peng wrote: > Why changing the ordering? The order was changed to be parallel with that of `equals`. > I was wondering if you'd change this to Objects.hash(...) with all the fields as arguments. Sure, we could use a convenience method, but because `eData` is an array, it should be `Arrays.deepHashCode(..., eData, ...)` or this construct: Objects.hash(..., Arrays.hashCode(eData), ...) Bottom line: as long as we include all eData elements in the computation, we should be fine. If we fail to do that, we'll violate the equals-hashCode contract. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284876142 From ssahoo at openjdk.org Sat Aug 5 19:11:29 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Sat, 5 Aug 2023 19:11:29 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v4] In-Reply-To: <4Gj1E6B2P0w6mtx-86Zp_LN9R0xYpT686WtdLNrcl8U=.b82b533b-65d0-497a-87ba-3ab4d6ee5e86@github.com> References: <4Gj1E6B2P0w6mtx-86Zp_LN9R0xYpT686WtdLNrcl8U=.b82b533b-65d0-497a-87ba-3ab4d6ee5e86@github.com> Message-ID: On Thu, 3 Aug 2023 17:20:00 GMT, Rajan Halade wrote: >> I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. >> >> Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. > > Rajan Halade has updated the pull request incrementally with two additional commits since the last revision: > > - Address review comments - 1 > - Address review comments - 1 Marked as reviewed by ssahoo (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15125#pullrequestreview-1563998900 From jwaters at openjdk.org Mon Aug 7 06:42:41 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 06:42:41 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code Julian Waters 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 22 additional commits since the last revision: - Mismatched declaration in D3DGlyphCache.cpp - Fields in awt_TextComponent.cpp - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp - Qualifiers in awt_PrintDialog.h should be removed - Likewise for awt_DnDDT.cpp - awt_ole.h include order issue in awt_DnDDS.cpp - Revert awt_ole.h - Earlier fix in awt_ole.h was not complete - Merge branch 'openjdk:master' into patch-10 - Likewise for awt_Frame.cpp - ... and 12 more: https://git.openjdk.org/jdk/compare/6432a4e7...51230f3d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/8d8cb5aa..51230f3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=00-01 Stats: 5173 lines in 265 files changed: 2892 ins; 846 del; 1435 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Mon Aug 7 06:42:42 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 06:42:42 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 1 Aug 2023 01:52:24 GMT, Julian Waters wrote: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code That broken mismatched exception specifier in allocation.cpp has been annoying the absolute **** out of me for a long time now, feels good to see it go Ready for initial rounds of review ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1659458669 PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1667269318 From dholmes at openjdk.org Mon Aug 7 06:42:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 06:42:44 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:37:21 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters 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 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/6432a4e7...51230f3d src/hotspot/os/windows/symbolengine.cpp line 114: > 112: _capacity = (int)(sizeof(_fallback_buffer) / sizeof(T)); > 113: } > 114: _p[0] = (T) '\0'; I find this use of `'\0'` quite suspicious in itself, but it is consistent with the use of `'X'` in `imprint_sentinel()`. I'm unclear what types are possible for `T` in this code. src/hotspot/share/memory/allocation.cpp line 114: > 112: // > 113: > 114: void* AnyObj::operator new(size_t size, Arena *arena) { Please remind us what the issue is with `throw()` as this is a change to shared code and it looks very inconsistent to remove it only for this one definition of `operator new`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1280259660 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1280260492 From jwaters at openjdk.org Mon Aug 7 06:42:44 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 06:42:44 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 1 Aug 2023 08:10:10 GMT, David Holmes wrote: >> Julian Waters 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 22 additional commits since the last revision: >> >> - Mismatched declaration in D3DGlyphCache.cpp >> - Fields in awt_TextComponent.cpp >> - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp >> - Qualifiers in awt_PrintDialog.h should be removed >> - Likewise for awt_DnDDT.cpp >> - awt_ole.h include order issue in awt_DnDDS.cpp >> - Revert awt_ole.h >> - Earlier fix in awt_ole.h was not complete >> - Merge branch 'openjdk:master' into patch-10 >> - Likewise for awt_Frame.cpp >> - ... and 12 more: https://git.openjdk.org/jdk/compare/6432a4e7...51230f3d > > src/hotspot/os/windows/symbolengine.cpp line 114: > >> 112: _capacity = (int)(sizeof(_fallback_buffer) / sizeof(T)); >> 113: } >> 114: _p[0] = (T) '\0'; > > I find this use of `'\0'` quite suspicious in itself, but it is consistent with the use of `'X'` in `imprint_sentinel()`. I'm unclear what types are possible for `T` in this code. There are currently only 2 possible types of HMODULE and char/uint8_t for T at the moment. Weirdly enough only line 126 errors out without the cast while line 114, despite having the same problem, doesn't, but I added the cast to both lines for consistency. If someone else knows why I could probably deal with this code in a better way besides just casting it to T (which I also am reluctant to do) > src/hotspot/share/memory/allocation.cpp line 114: > >> 112: // >> 113: >> 114: void* AnyObj::operator new(size_t size, Arena *arena) { > > Please remind us what the issue is with `throw()` as this is a change to shared code and it looks very inconsistent to remove it only for this one definition of `operator new`. Hi David, this throw was removed for this method's declaration in the corresponding hpp file in an earlier commit [8305590: Remove nothrow exception specifications from operator new](https://github.com/openjdk/jdk/commit/0f51e6326373ff7d4a4d9a0e3a2788401f73405d), but the Author forgot to remove the throw() from the definition as well (the error can be viewed in the GHA for the earlier versions of this PR). I believe gcc only errors on this in C++17 mode (for some weird reason) and not our current C++14 mode, which is why it gets a pass on other platforms ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1280269818 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1280267058 From dholmes at openjdk.org Mon Aug 7 08:04:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 08:04:32 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters 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 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/8eae6324...51230f3d Hotspot and build changes seem okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15096#pullrequestreview-1564771081 From dholmes at openjdk.org Mon Aug 7 08:04:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 08:04:34 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 1 Aug 2023 08:16:41 GMT, Julian Waters wrote: >> src/hotspot/share/memory/allocation.cpp line 114: >> >>> 112: // >>> 113: >>> 114: void* AnyObj::operator new(size_t size, Arena *arena) { >> >> Please remind us what the issue is with `throw()` as this is a change to shared code and it looks very inconsistent to remove it only for this one definition of `operator new`. > > Hi David, this throw was removed for this method's declaration in the corresponding hpp file in an earlier commit [8305590: Remove nothrow exception specifications from operator new](https://github.com/openjdk/jdk/commit/0f51e6326373ff7d4a4d9a0e3a2788401f73405d), but the Author forgot to remove the throw() from the definition as well (the error can be viewed in the GHA for the earlier versions of this PR). I believe gcc only errors on this in C++17 mode (for some weird reason) and not our current C++14 mode, which is why it gets a pass on other platforms Thanks for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1285518812 From jwaters at openjdk.org Mon Aug 7 08:08:35 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 08:08:35 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <1RputHpTgH5gDU5TObp5N87AyeOiyCQ6WLM1PTfCyk4=.3004faa1-36e0-4f6c-9909-519d598ea823@github.com> On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters 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 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/27f60d75...51230f3d Setting reviewers required to 4 for each subcomponent ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1667390881 From jwaters at openjdk.org Mon Aug 7 08:17:35 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 08:17:35 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 1 Aug 2023 08:19:06 GMT, Julian Waters wrote: >> src/hotspot/os/windows/symbolengine.cpp line 114: >> >>> 112: _capacity = (int)(sizeof(_fallback_buffer) / sizeof(T)); >>> 113: } >>> 114: _p[0] = (T) '\0'; >> >> I find this use of `'\0'` quite suspicious in itself, but it is consistent with the use of `'X'` in `imprint_sentinel()`. I'm unclear what types are possible for `T` in this code. > > There are currently only 2 possible types of HMODULE and char/uint8_t for T at the moment. Weirdly enough only line 126 errors out without the cast while line 114, despite having the same problem, doesn't, but I added the cast to both lines for consistency. If someone else knows why I could probably deal with this code in a better way besides just casting it to T (which I also am reluctant to do) I just checked and the value of the sentinel is ultimately the prvalue 88. I don't know if we'd want to replace all the weird char usages here with explicit values of 0 (and 88 for the sentinel). Maybe future reviews can help with that ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1285533375 From kbarrett at openjdk.org Mon Aug 7 09:23:32 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 7 Aug 2023 09:23:32 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 08:00:12 GMT, David Holmes wrote: >> Hi David, this throw was removed for this method's declaration in the corresponding hpp file in an earlier commit [8305590: Remove nothrow exception specifications from operator new](https://github.com/openjdk/jdk/commit/0f51e6326373ff7d4a4d9a0e3a2788401f73405d), but the Author forgot to remove the throw() from the definition as well (the error can be viewed in the GHA for the earlier versions of this PR). I believe gcc only errors on this in C++17 mode (for some weird reason) and not our current C++14 mode, which is why it gets a pass on other platforms > > Thanks for that. C++17 makes exception specifications part of the type system: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html Hence a mismatch between a declaration and it's definition is an error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1285607278 From jnimeh at openjdk.org Mon Aug 7 15:38:30 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 7 Aug 2023 15:38:30 GMT Subject: RFR: 8312259: StatusResponseManager unused code clean up [v4] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 19:09:53 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have the code cleanup update reviewed? With this update, the unused code in StatusResponseManager.java will be removed. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > remove unintended blank line The removal of these methods is fine. Many of these were in there to support a different planned approach to populating the SRM's cache, but we went with a simpler approach when it was implemented in JDK 9. If we ever decide to implement a scheduler-based refresh we can always add the methods that we need back. ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14924#pullrequestreview-1565627903 From mpowers at openjdk.org Mon Aug 7 15:51:35 2023 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 7 Aug 2023 15:51:35 GMT Subject: RFR: 8311596: Add separate system properties for TLS server and client for maximum chain length In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:30:06 GMT, Hai-May Chao wrote: > Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you. All of the other changes look fine to me. Does this need a test? src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 115: > 113: "jdk.tls.maxCertificateChainLength", 10); > 114: > 115: // Limit the maximum certificate chain length accepted from clients Should these be moved to after line 89? src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 150: > 148: */ > 149: static { > 150: Integer clientLen = GetIntegerAction.privilegedGetProperty( I think you could call `privilegedGetProperty` with the default value as second argument. ------------- PR Review: https://git.openjdk.org/jdk/pull/15163#pullrequestreview-1565630479 PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1286053347 PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1286074504 From jnimeh at openjdk.org Mon Aug 7 17:25:31 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 7 Aug 2023 17:25:31 GMT Subject: RFR: 8311596: Add separate system properties for TLS server and client for maximum chain length In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:30:06 GMT, Hai-May Chao wrote: > Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you. src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 159: > 157: maxServerCertificateChainLength = (serverLen != null) ? > 158: serverLen : maxCertificateChainLength; > 159: } I wonder if we should take the opportunity here with these new properties as well as `jdk.tls.maxCertificateChainLength` to also equate negative numbers (and maybe zero) to be the default. Right now only property values that fail the internal parseInt conversion will evaluate to `null` and would be assigned the default I think. But a negative value I think would be taken as-is from the property. Should a negative max cert chain length get set to the default? If so, it might also make sense to give a warning about the offending value and note that it is being set to the default (similar to what `GetPropertyAction.privilegedGetTimeoutProp()` does). If you think this is worthwhile, the CSR should probably be updated to reflect that also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15163#discussion_r1286185634 From valeriep at openjdk.org Mon Aug 7 21:06:39 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 7 Aug 2023 21:06:39 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Fri, 4 Aug 2023 15:11:47 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/sun/security/provider/certpath/CertId.java line 182: >> >>> 180: myhash += Arrays.hashCode(issuerNameHash); >>> 181: myhash += Arrays.hashCode(issuerKeyHash); >>> 182: myhash += certSerialNumber.getNumber().hashCode(); >> >> It seems that for some other classes, you may just use Objects.hash(hashAlgId, issuerNameHash, issuerKeyHash, certSerialNumber.getNumber())? Is there a rule on what to use? > > We can be more aggressive in some refactorings, but I note that if any of the hashCode components are arrays, the proper, albeit slightly inconvenient way to combine all the components would be `Arrays.deepHashCode(Object[])`, not `Objects.hash(Object... values)` or `Arrays.hashCode(Object[])`. The latter two don't recurse into arrays, but use their "shallow" hashCode. Hmm, I see. Thanks for the clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1286381949 From valeriep at openjdk.org Mon Aug 7 21:42:36 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 7 Aug 2023 21:42:36 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Fri, 4 Aug 2023 22:00:41 GMT, Pavel Rappo wrote: >> src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java line 523: >> >>> 521: if (crealm != null) result = 37 * result + crealm.hashCode(); >>> 522: if (cname != null) result = 37 * result + cname.hashCode(); >>> 523: if (sname != null) result = 37 * result + sname.hashCode(); >> >> Why changing the ordering? I was wondering if you'd change this to Objects.hash(...) with all the fields as arguments. > >> Why changing the ordering? > > The order was changed to be parallel with that of `equals`. > >> I was wondering if you'd change this to Objects.hash(...) with all the fields as arguments. > > Sure, we could use a convenience method, but because `eData` is an array, it should be `Arrays.deepHashCode(..., eData, ...)` or this construct: > > Objects.hash(..., Arrays.hashCode(eData), ...) > > Bottom line: as long as we include all eData elements in the computation, we should be fine. If we fail to do that, we'll violate the equals-hashCode contract. Ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1286406005 From prappo at openjdk.org Tue Aug 8 11:59:00 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 8 Aug 2023 11:59:00 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v13] 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 with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Feedback (part 2) - Feedback (part 1) - Feedback Recovers sloppy merge. - Merge branch 'master' into 8311170 - Feedback - Merge branch 'master' into 8311170 # Conflicts: # src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java - Feedback - Feedback - Feedback: avoid intermediate assignments - More previously missed cases - ... and 15 more: https://git.openjdk.org/jdk/compare/41bdcded...d9316270 ------------- Changes: https://git.openjdk.org/jdk/pull/14738/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=12 Stats: 1121 lines in 96 files changed: 170 ins; 552 del; 399 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 Tue Aug 8 11:59:00 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 8 Aug 2023 11:59:00 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: <-h9k8EM8BeTYVOtt5OklxaG8Ul1r8ay5H9xU9vy1HUY=.9f6e9cc0-f21c-497f-bc20-a397cbda693a@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <-h9k8EM8BeTYVOtt5OklxaG8Ul1r8ay5H9xU9vy1HUY=.9f6e9cc0-f21c-497f-bc20-a397cbda693a@github.com> Message-ID: On Fri, 4 Aug 2023 21:30:00 GMT, Valerie Peng wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback > > src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java line 105: > >> 103: return false; >> 104: if (address != null && h.address != null) { >> 105: return Arrays.equals(address, h.address); > > Can't this block be combined into: > return` addrType == h.addrType && Arrays.equals(address, h.address); `? Have a look at the end result (commits e71fc42a173 and d9316270976), is it better? > src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddresses.java line 156: > >> 154: return false; >> 155: if (addresses != null && addrs.addresses != null) { >> 156: return Arrays.equals(addresses, addrs.addresses); > > Same comment as above, i.e. combined into one return condition. Same comment as above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1287009881 PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1287009965 From prappo at openjdk.org Tue Aug 8 16:17:44 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 8 Aug 2023 16:17:44 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v14] 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: Feedback (part 3) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/d9316270..608258ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=12-13 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 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 Tue Aug 8 16:17:46 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 8 Aug 2023 16:17:46 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <-h9k8EM8BeTYVOtt5OklxaG8Ul1r8ay5H9xU9vy1HUY=.9f6e9cc0-f21c-497f-bc20-a397cbda693a@github.com> Message-ID: <5fpSLZutIQVRzNBVZ-sVbMQPWroqHYXKTp5Lbx2nIXg=.9247a264-2eed-44d4-b9ab-2ca69a7666c4@github.com> On Tue, 8 Aug 2023 11:54:42 GMT, Pavel Rappo wrote: >> src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java line 105: >> >>> 103: return false; >>> 104: if (address != null && h.address != null) { >>> 105: return Arrays.equals(address, h.address); >> >> Can't this block be combined into: >> return` addrType == h.addrType && Arrays.equals(address, h.address); `? > > Have a look at the end result (commits e71fc42a173 and d9316270976), is it better? Oops: forgot to commit and push 608258e. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1287356149 From rriggs at openjdk.org Tue Aug 8 17:46:42 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 8 Aug 2023 17:46:42 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v14] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Tue, 8 Aug 2023 16:17:44 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback (part 3) Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14738#pullrequestreview-1567834164 From rhalade at openjdk.org Tue Aug 8 17:48:21 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 8 Aug 2023 17:48:21 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v5] In-Reply-To: References: Message-ID: > I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. > > Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. Rajan Halade 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 ten additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8313206-pkcs11skip - Address review comments - 1 - Address review comments - 1 - 8313206: revert skipTest update to address with new bug - 8313206: update Secmod tests - 8313206: mark skipped only when all three tests are skipped - Merge branch 'master' into 8313206-pkcs11skip - 8313206: add test trace messages - 8313206: PKCS11 tests silently skip execution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15125/files - new: https://git.openjdk.org/jdk/pull/15125/files/124f9a5d..5b596524 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=03-04 Stats: 9768 lines in 466 files changed: 4082 ins; 2437 del; 3249 mod Patch: https://git.openjdk.org/jdk/pull/15125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15125/head:pull/15125 PR: https://git.openjdk.org/jdk/pull/15125 From erikj at openjdk.org Tue Aug 8 19:00:36 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 8 Aug 2023 19:00:36 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters 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 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/6d476cbe...51230f3d Build change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15096#pullrequestreview-1567944297 From mullan at openjdk.org Tue Aug 8 19:31:37 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 8 Aug 2023 19:31:37 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v5] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 17:48:21 GMT, Rajan Halade wrote: >> I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. >> >> Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. > > Rajan Halade 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 ten additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8313206-pkcs11skip > - Address review comments - 1 > - Address review comments - 1 > - 8313206: revert skipTest update to address with new bug > - 8313206: update Secmod tests > - 8313206: mark skipped only when all three tests are skipped > - Merge branch 'master' into 8313206-pkcs11skip > - 8313206: add test trace messages > - 8313206: PKCS11 tests silently skip execution Copyrights need to be updated. Otherwise, looks fine. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15125#pullrequestreview-1568007748 From rhalade at openjdk.org Tue Aug 8 19:43:38 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 8 Aug 2023 19:43:38 GMT Subject: RFR: 8313206: PKCS11 tests silently skip execution [v6] In-Reply-To: References: Message-ID: > I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. > > Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15125/files - new: https://git.openjdk.org/jdk/pull/15125/files/5b596524..6b7f1604 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15125&range=04-05 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15125/head:pull/15125 PR: https://git.openjdk.org/jdk/pull/15125 From stuefe at openjdk.org Tue Aug 8 19:54:36 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 19:54:36 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 08:14:41 GMT, Julian Waters wrote: >> There are currently only 2 possible types of HMODULE and char/uint8_t for T at the moment. Weirdly enough only line 126 errors out without the cast while line 114, despite having the same problem, doesn't, but I added the cast to both lines for consistency. If someone else knows why I could probably deal with this code in a better way besides just casting it to T (which I also am reluctant to do) > > I just checked and the value of the sentinel is ultimately the prvalue 88. I don't know if we'd want to replace all the weird char usages here with explicit values of 0 (and 88 for the sentinel). Maybe future reviews can help with that I wrote this code ages ago. I'm not sure what's weird or suspicious about it, though. The comment at the file's beginning explains this code's motivation. The buffer was never thought to be used for something different than HANDLEs or characters, where the assignment of integer literals work. I often use char constants for sentinels as debugging aid. As for `'\0'`, that indicates to the casual code reader that this is a termination of a string, better than had I used a plain 0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287626062 From stuefe at openjdk.org Tue Aug 8 20:22:42 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 20:22:42 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters 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 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/c9dcbf20...51230f3d Hi Julian, Cursory review. I stopped halfway in when I noticed that I had no idea why many of the changes were done. They did not seem to have an obvious connection to the title of the JBS, and I did not find an explanation. I also find the usage of "monstrosities" unnecessary. It is very much a matter of taste - to me, nothing in the code you changed looks monstrous. Cheers, Thomas src/hotspot/os/windows/os_windows.cpp line 2888: > 2886: LONG WINAPI topLevelUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo) { > 2887: if (!InterceptOSException) { > 2888: DWORD exception_code = exceptionInfo->ExceptionRecord->ExceptionCode; I find this less clearer than the original code, that didn't use negation - it was clear that InterceptOSException leads to immediate bailout. What is the problem, the goto? Is that just your personal taste, or is the compiler complaining? If the latter, I would vote for duplicating the return statement here (and this would count as an example where discarding out-of-fashion statements like goto actually makes the code worse). src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 216: > 214: { > 215: PDATA pData; > 216: JNI_CHECK_PEER_GOTO(canvas, ret); Here, and other places: why this scope? src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp line 48: > 46: > 47: #include "jlong.h" > 48: #include "awt.h" Why the reordering of includes? src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp line 34: > 32: #include "sun_awt_windows_WDropTargetContextPeer.h" > 33: #include "awt_Container.h" > 34: #include "awt_ole.h" Why? ------------- PR Review: https://git.openjdk.org/jdk/pull/15096#pullrequestreview-1568088318 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287629714 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287630358 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287631591 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287632623 From rhalade at openjdk.org Tue Aug 8 20:24:43 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 8 Aug 2023 20:24:43 GMT Subject: Integrated: 8313206: PKCS11 tests silently skip execution In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 17:51:31 GMT, Rajan Halade wrote: > I have updated PKCS11Test.java to mark test as skipped only when all testDefault, testNSS, and testDeimos tests are skipped. This file also includes new trace messages, code cleanup and format change. Some other test files are updated to mark as skipped as they use TestNG framework to execute. > > Enhancement [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) is filed to consider refractor of tests to split these for us to better track the coverage. This pull request has now been integrated. Changeset: 515add88 Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/515add88ed6c290ee90f3d6f522a22971e37a62c Stats: 355 lines in 10 files changed: 171 ins; 87 del; 97 mod 8313206: PKCS11 tests silently skip execution Reviewed-by: ssahoo, mullan ------------- PR: https://git.openjdk.org/jdk/pull/15125 From stuefe at openjdk.org Tue Aug 8 20:56:37 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 20:56:37 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters 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 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/59027534...51230f3d I think I see now that the added scopes were to prevent variable life scopes from intersecting goto's? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1670293563 From valeriep at openjdk.org Tue Aug 8 22:46:39 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 8 Aug 2023 22:46:39 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v14] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Tue, 8 Aug 2023 16:17:44 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback (part 3) Looks good. Thanks ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14738#pullrequestreview-1568406750 From valeriep at openjdk.org Tue Aug 8 23:05:30 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 8 Aug 2023 23:05:30 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: <_JLMOkMI3dcALCt8DWbNi6t185-zadP9FU9XvQcJZqE=.e0b9cf5b-ac29-4b2c-a9a5-d5f9bf9d8eaa@github.com> On Fri, 4 Aug 2023 10:48:13 GMT, Matthias Baesken wrote: > Hi Valerie, we put the PR into our build/test queue to check if it solves some errors we currently notice in CertChainRemoval.java . Sure, thanks! What is the errors that you observed? Are you running against NSS and which version? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1670425773 From jwaters at openjdk.org Wed Aug 9 04:02:43 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 9 Aug 2023 04:02:43 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com> On Tue, 8 Aug 2023 19:56:24 GMT, Thomas Stuefe wrote: >> Julian Waters 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 22 additional commits since the last revision: >> >> - Mismatched declaration in D3DGlyphCache.cpp >> - Fields in awt_TextComponent.cpp >> - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp >> - Qualifiers in awt_PrintDialog.h should be removed >> - Likewise for awt_DnDDT.cpp >> - awt_ole.h include order issue in awt_DnDDS.cpp >> - Revert awt_ole.h >> - Earlier fix in awt_ole.h was not complete >> - Merge branch 'openjdk:master' into patch-10 >> - Likewise for awt_Frame.cpp >> - ... and 12 more: https://git.openjdk.org/jdk/compare/9da8c164...51230f3d > > src/hotspot/os/windows/os_windows.cpp line 2888: > >> 2886: LONG WINAPI topLevelUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo) { >> 2887: if (!InterceptOSException) { >> 2888: DWORD exception_code = exceptionInfo->ExceptionRecord->ExceptionCode; > > I find this less clearer than the original code, that didn't use negation - it was clear that InterceptOSException leads to immediate bailout. > > What is the problem, the goto? is the compiler complaining? If so, I would vote for duplicating the return statement here (and this would count as an example where discarding out-of-fashion statements like goto actually makes the code worse). Hi Thomas, the goto jumps over a lot of variable initializations, which permissive- doesn't particularly like (the failing compilation can actually be seen in the earlier GHA logs) > src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp line 48: > >> 46: >> 47: #include "jlong.h" >> 48: #include "awt.h" > > Why the reordering of includes? This is a weird one, but in awt we #define malloc Do_Not_Use_Malloc... And so on. Without this reordering awt_ole.h (which includes comdef.h) also uses the redefined malloc somewhere (I could not find where in comip.h that it's used) which breaks compilation. I do find it strange that without permissive- it doesn't break though. Same applies to the other reordering of includes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287904601 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287903377 From jwaters at openjdk.org Wed Aug 9 04:05:34 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 9 Aug 2023 04:05:34 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 8 Aug 2023 20:53:19 GMT, Thomas Stuefe wrote: > I think I see now that the added scopes were to prevent variable life scopes from intersecting goto's? Yes, that's why ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1670618830 From matthias.perktold at asahotel.com Thu Aug 3 08:56:32 2023 From: matthias.perktold at asahotel.com (Matthias Perktold - ASA) Date: Thu, 3 Aug 2023 08:56:32 +0000 Subject: =?iso-8859-1?Q?JDK-8170813=A0TLS_session_cache_access?= Message-ID: I would like to put some attention on JDK-8170813?"TLS session cache access". It has been open for almost seven years now, and there is still no good solution. On the contrary, the workarounds provided in the linked issue from Apache Commons NET are becoming more difficult with newer Java versions, as reflective access is restricted more and more. For the concrete workaround, see https://issues.apache.org/jira/browse/NET-408?focusedCommentId=17316422&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17316422 First, the workarounds basically required "only" some reflection magic. With JDK 8u161 or higher, the System property "jdk.tls.useExtendedMasterSecret" must be set to false. With JDK 11, you get a warning regarding illegal reflective access. With JDK 14, the System "property jdk.tls.client.enableSessionTicketExtension" must be set to false. With JDK 17, that warning regarding illegal reflective access turns into an error, unless is explicitely enabled via the --add-opens command line parameter. I am not sure how the situation looks on newer JDK versions, but if anything, it will only become more difficult. And by itself, making illegal access more difficult is a good thing. But then we need to have a way to implement TLS session resumption in a clean way without resorting to reflection hacks. Otherwise, at some point the only workaround left will be to not require TLS session resumption on the FTP server. And that is worse for security, and often not even under our control. Regards, Matthias Perktold From stuefe at openjdk.org Wed Aug 9 06:32:35 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Aug 2023 06:32:35 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com> Message-ID: On Wed, 9 Aug 2023 04:00:03 GMT, Julian Waters wrote: >> src/hotspot/os/windows/os_windows.cpp line 2888: >> >>> 2886: LONG WINAPI topLevelUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo) { >>> 2887: if (!InterceptOSException) { >>> 2888: DWORD exception_code = exceptionInfo->ExceptionRecord->ExceptionCode; >> >> I find this less clearer than the original code, that didn't use negation - it was clear that InterceptOSException leads to immediate bailout. >> >> What is the problem, the goto? is the compiler complaining? If so, I would vote for duplicating the return statement here (and this would count as an example where discarding out-of-fashion statements like goto actually makes the code worse). > > Hi Thomas, the goto jumps over a lot of variable initializations, which permissive- doesn't particularly like (the failing compilation can actually be seen in the earlier GHA logs) Ah, okay. Thanks for clarifying. >> src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp line 48: >> >>> 46: >>> 47: #include "jlong.h" >>> 48: #include "awt.h" >> >> Why the reordering of includes? > > This is a weird one, but in awt we #define malloc Do_Not_Use_Malloc... And so on. Without this reordering awt_ole.h (which includes comdef.h) also uses the redefined malloc somewhere (I could not find where in comip.h that it's used) which breaks compilation. I do find it strange that without permissive- it doesn't break though. Same applies to the other reordering of includes Oh. That's not good. Having such an undocumented reliance on order of include just begs to bitrot at some point. Any chance you could unravel that mystery, maybe in a later RFE? For now, can you please add a comment at those places where you changed include order for that reason? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288007914 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288009545 From stuefe at openjdk.org Wed Aug 9 06:41:40 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Aug 2023 06:41:40 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters 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 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/15f348cb...51230f3d src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1641: > 1639: } > 1640: } > 1641: A possible improvement later (and for a future RFE) would be to use RAII for deletion and then get rid of the labels. awt is one of the few places that uses C++ for native code, so why not. src/java.desktop/windows/native/libawt/windows/awt_TextComponent.cpp line 59: > 57: AwtTextComponent::OleCallback AwtTextComponent::sm_oleCallback; > 58: WNDPROC AwtTextComponent::sm_pDefWindowProc = NULL; > 59: Did the compiler complain here? I'm fine with the change, just wanted to know the reason. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288013587 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288015274 From dholmes at openjdk.org Wed Aug 9 06:56:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 9 Aug 2023 06:56:35 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 8 Aug 2023 19:52:08 GMT, Thomas Stuefe wrote: >> I just checked and the value of the sentinel is ultimately the prvalue 88. I don't know if we'd want to replace all the weird char usages here with explicit values of 0 (and 88 for the sentinel). Maybe future reviews can help with that > > I wrote this code ages ago. I'm not sure what's weird or suspicious about it, though. The comment at the file's beginning explains this code's motivation. > > The buffer was never thought to be used for something different than HANDLEs or characters, where the assignment of integer literals work. I often use char constants for sentinels as debugging aid. As for `'\0'`, that indicates to the casual code reader that this is a termination of a string, better than had I used a plain 0. Because there is nothing to state what T may be, I found assigning character literals to be odd. If T is char and the buffer is meant to be a C string then it makes more sense. But for non-char T it just raised questions for me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288029698 From mbaesken at openjdk.org Wed Aug 9 07:20:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 9 Aug 2023 07:20:02 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: <_JLMOkMI3dcALCt8DWbNi6t185-zadP9FU9XvQcJZqE=.e0b9cf5b-ac29-4b2c-a9a5-d5f9bf9d8eaa@github.com> References: <_JLMOkMI3dcALCt8DWbNi6t185-zadP9FU9XvQcJZqE=.e0b9cf5b-ac29-4b2c-a9a5-d5f9bf9d8eaa@github.com> Message-ID: On Tue, 8 Aug 2023 23:03:02 GMT, Valerie Peng wrote: > > Hi Valerie, we put the PR into our build/test queue to check if it solves some errors we currently notice in CertChainRemoval.java . > > Sure, thanks! What is the errors that you observed? Are you running against NSS and which version? Looks like the errors are gone with your patch added. Regarding NSS version, this is what rpm shows, I think this should be the version (on an RHEL 8.5 machine) nss-3.67.0-7.el8_5.ppc64le ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1670782798 From djelinski1 at gmail.com Wed Aug 9 07:51:50 2023 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 9 Aug 2023 09:51:50 +0200 Subject: JDK-8170813 TLS session cache access In-Reply-To: References: Message-ID: Hi Matthias, As I understand it, the problem is that you need to open a new connection to the same host on a different port, and reuse the TLS session that was established on the original port. Is that correct? Normally I'd recommend creating a layered socket using SSLSocketFactory.html#createSocket(Socket,String,int,boolean) [1], but it's broken - the port parameter is unused, and the session is retrieved from cache using the port of the underlying socket. Still, it's much easier to fix this than to expose the TLS session cache. Regards, Daniel [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLSocketFactory.html#createSocket(java.net.Socket,java.lang.String,int,boolean) ?r., 9 sie 2023 o 08:10 Matthias Perktold - ASA napisa?(a): > > I would like to put some attention on JDK-8170813 "TLS session cache access". > > It has been open for almost seven years now, and there is still no good solution. > > On the contrary, the workarounds provided in the linked issue from Apache Commons NET are becoming more difficult with newer Java versions, as reflective access is restricted more and more. > For the concrete workaround, see https://issues.apache.org/jira/browse/NET-408?focusedCommentId=17316422&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17316422 > > First, the workarounds basically required "only" some reflection magic. > With JDK 8u161 or higher, the System property "jdk.tls.useExtendedMasterSecret" must be set to false. > With JDK 11, you get a warning regarding illegal reflective access. > With JDK 14, the System "property jdk.tls.client.enableSessionTicketExtension" must be set to false. > With JDK 17, that warning regarding illegal reflective access turns into an error, unless is explicitely enabled via the --add-opens command line parameter. > > I am not sure how the situation looks on newer JDK versions, but if anything, it will only become more difficult. > > And by itself, making illegal access more difficult is a good thing. > But then we need to have a way to implement TLS session resumption in a clean way without resorting to reflection hacks. > > Otherwise, at some point the only workaround left will be to not require TLS session resumption on the FTP server. > And that is worse for security, and often not even under our control. > > Regards, > Matthias Perktold From stuefe at openjdk.org Wed Aug 9 08:08:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Aug 2023 08:08:28 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Wed, 9 Aug 2023 06:53:49 GMT, David Holmes wrote: >> I wrote this code ages ago. I'm not sure what's weird or suspicious about it, though. The comment at the file's beginning explains this code's motivation. >> >> The buffer was never thought to be used for something different than HANDLEs or characters, where the assignment of integer literals work. I often use char constants for sentinels as debugging aid. As for `'\0'`, that indicates to the casual code reader that this is a termination of a string, better than had I used a plain 0. > > Because there is nothing to state what T may be, I found assigning character literals to be odd. If T is char and the buffer is meant to be a C string then it makes more sense. But for non-char T it just raised questions for me. I see that. We can remove the sentinel stuff, which leaves us with the zero termination. Arguably, this could be done by sub classes that derive from the char instantiation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288083649 From jwaters at openjdk.org Wed Aug 9 11:31:29 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 9 Aug 2023 11:31:29 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <3SFn8vguk4vb9YM46_-a4xNY-95z3gGBxOUwyXtzUGI=.a57a1663-6b34-4db9-bbae-3d9e4733dd02@github.com> On Wed, 9 Aug 2023 06:37:10 GMT, Thomas Stuefe wrote: >> Julian Waters 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 22 additional commits since the last revision: >> >> - Mismatched declaration in D3DGlyphCache.cpp >> - Fields in awt_TextComponent.cpp >> - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp >> - Qualifiers in awt_PrintDialog.h should be removed >> - Likewise for awt_DnDDT.cpp >> - awt_ole.h include order issue in awt_DnDDS.cpp >> - Revert awt_ole.h >> - Earlier fix in awt_ole.h was not complete >> - Merge branch 'openjdk:master' into patch-10 >> - Likewise for awt_Frame.cpp >> - ... and 12 more: https://git.openjdk.org/jdk/compare/7b4bc18a...51230f3d > > src/java.desktop/windows/native/libawt/windows/awt_TextComponent.cpp line 59: > >> 57: AwtTextComponent::OleCallback AwtTextComponent::sm_oleCallback; >> 58: WNDPROC AwtTextComponent::sm_pDefWindowProc = NULL; >> 59: > > Did the compiler complain here? I'm fine with the change, just wanted to know the reason. the latter two are inside an extern "C" block, meaning their initial C++ linkage (by virtue of them being static class members) conflicts with the now C linkage, also the comment there states the AwtComponent fields are supposed to be set here, and I have no idea why this was not done, so I moved them all to be under that comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288325155 From prappo at openjdk.org Wed Aug 9 12:18:29 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 9 Aug 2023 12:18:29 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v14] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Tue, 8 Aug 2023 16:17:44 GMT, Pavel Rappo wrote: >> 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; >> boolea... > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Feedback (part 3) Thanks to my patient reviewers. I'm running our CI tests one more time and, if all goes well, I'll integrate this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14738#issuecomment-1671191447 From prappo at openjdk.org Wed Aug 9 12:51:35 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 9 Aug 2023 12:51:35 GMT Subject: Integrated: 8311170: Simplify and modernize equals and hashCode in security area 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: On Fri, 30 Jun 2023 16:16:38 GMT, Pavel Rappo wrote: > 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... This pull request has now been integrated. Changeset: 19ae62ae Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/19ae62ae2cd2bbb436924b296151021864a3fcd9 Stats: 1121 lines in 96 files changed: 170 ins; 554 del; 397 mod 8311170: Simplify and modernize equals and hashCode in security area Reviewed-by: djelinski, rriggs, valeriep ------------- PR: https://git.openjdk.org/jdk/pull/14738 From valeriep at openjdk.org Wed Aug 9 17:22:34 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 9 Aug 2023 17:22:34 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: <_JLMOkMI3dcALCt8DWbNi6t185-zadP9FU9XvQcJZqE=.e0b9cf5b-ac29-4b2c-a9a5-d5f9bf9d8eaa@github.com> Message-ID: On Wed, 9 Aug 2023 07:03:00 GMT, Matthias Baesken wrote: > > > Hi Valerie, we put the PR into our build/test queue to check if it solves some errors we currently notice in CertChainRemoval.java . > > > > > > Sure, thanks! What is the errors that you observed? Are you running against NSS and which version? > > Looks like the errors are gone with your patch added. Regarding NSS version, this is what rpm shows, I think this should be the version (on an RHEL 8.5 machine) > > nss-3.67.0-7.el8_5.ppc64le Thanks for the confirmation! The next step is to find a reviewer for this PR then. ;) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1671825804 From valeriep at openjdk.org Wed Aug 9 18:06:29 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 9 Aug 2023 18:06:29 GMT Subject: RFR: JDK-8312461 JNI warnings in SunMSCApi provider In-Reply-To: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> References: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> Message-ID: On Tue, 1 Aug 2023 21:08:49 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8312461 Changes look good. BTW, need to add noreg-xxx label to the bug. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15113#pullrequestreview-1570252071 From cushon at openjdk.org Wed Aug 9 18:25:29 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 9 Aug 2023 18:25:29 GMT Subject: RFR: 8314045: ArithmeticException in GaloisCounterMode Message-ID: <9v7Pb-V5aRBRkVuM7nmxMO6HAab6j1SDmchGHKmAQoQ=.a83ba417-0bba-48e6-9317-3ef9410e5c46@github.com> Please consider this fix for [JDK-8314045](https://bugs.openjdk.org/browse/JDK-8314045), which adds a missing size check to avoid an `ArithmeticException` in `GaloisCounterMode`. ------------- Commit messages: - 8314045: ArithmeticException in GaloisCounterMode Changes: https://git.openjdk.org/jdk/pull/15212/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15212&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314045 Stats: 65 lines in 2 files changed: 65 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15212/head:pull/15212 PR: https://git.openjdk.org/jdk/pull/15212 From cushon at openjdk.org Wed Aug 9 23:41:29 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 9 Aug 2023 23:41:29 GMT Subject: RFR: 8314045: ArithmeticException in GaloisCounterMode [v2] In-Reply-To: <9v7Pb-V5aRBRkVuM7nmxMO6HAab6j1SDmchGHKmAQoQ=.a83ba417-0bba-48e6-9317-3ef9410e5c46@github.com> References: <9v7Pb-V5aRBRkVuM7nmxMO6HAab6j1SDmchGHKmAQoQ=.a83ba417-0bba-48e6-9317-3ef9410e5c46@github.com> Message-ID: > Please consider this fix for [JDK-8314045](https://bugs.openjdk.org/browse/JDK-8314045), which adds a missing size check to avoid an `ArithmeticException` in `GaloisCounterMode`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Check for AEADBadTagException specifically ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15212/files - new: https://git.openjdk.org/jdk/pull/15212/files/4eec1c75..68412f52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15212&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15212&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15212/head:pull/15212 PR: https://git.openjdk.org/jdk/pull/15212 From ascarpino at openjdk.org Wed Aug 9 23:44:28 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 9 Aug 2023 23:44:28 GMT Subject: RFR: 8314045: ArithmeticException in GaloisCounterMode [v2] In-Reply-To: References: <9v7Pb-V5aRBRkVuM7nmxMO6HAab6j1SDmchGHKmAQoQ=.a83ba417-0bba-48e6-9317-3ef9410e5c46@github.com> Message-ID: On Wed, 9 Aug 2023 23:15:59 GMT, Liam Miller-Cushon wrote: >> Please consider this fix for [JDK-8314045](https://bugs.openjdk.org/browse/JDK-8314045), which adds a missing size check to avoid an `ArithmeticException` in `GaloisCounterMode`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Check for AEADBadTagException specifically test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortInput.java line 54: > 52: cipher.doFinal(ByteBuffer.allocate(0), ByteBuffer.allocate(0)); > 53: throw new AssertionError("GeneralSecurityException expected"); > 54: } catch (GeneralSecurityException e) { The test should be verifying the exception is AEADBadTagException, not GeneralSecurityException, since that is the issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15212#discussion_r1289342514 From cushon at openjdk.org Wed Aug 9 23:45:28 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 9 Aug 2023 23:45:28 GMT Subject: RFR: 8314045: ArithmeticException in GaloisCounterMode [v2] In-Reply-To: References: <9v7Pb-V5aRBRkVuM7nmxMO6HAab6j1SDmchGHKmAQoQ=.a83ba417-0bba-48e6-9317-3ef9410e5c46@github.com> Message-ID: <2sOfP8n3zaGkH-8meqsbR3q2j1tUP-bz0S4A2CQ3cn8=.ce15fb2f-ae1f-4c05-989e-866cdbc4e8cb@github.com> On Wed, 9 Aug 2023 23:09:37 GMT, Anthony Scarpino wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Check for AEADBadTagException specifically > > test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortInput.java line 54: > >> 52: cipher.doFinal(ByteBuffer.allocate(0), ByteBuffer.allocate(0)); >> 53: throw new AssertionError("GeneralSecurityException expected"); >> 54: } catch (GeneralSecurityException e) { > > The test should be verifying the exception is AEADBadTagException, not GeneralSecurityException, since that is the issue. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15212#discussion_r1289345612 From valeriep at openjdk.org Thu Aug 10 01:20:01 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Aug 2023 01:20:01 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 Message-ID: Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). Thanks in advance for review~ ------------- Commit messages: - 8312428: PKCS11 tests fail with NSS 3.91 Changes: https://git.openjdk.org/jdk/pull/15217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312428 Stats: 231 lines in 4 files changed: 128 ins; 56 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/15217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15217/head:pull/15217 PR: https://git.openjdk.org/jdk/pull/15217 From mpowers at openjdk.org Thu Aug 10 03:11:28 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 10 Aug 2023 03:11:28 GMT Subject: RFR: JDK-8312461 JNI warnings in SunMSCApi provider In-Reply-To: References: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> Message-ID: On Wed, 9 Aug 2023 17:56:02 GMT, Valerie Peng wrote: >> https://bugs.openjdk.org/browse/JDK-8312461 > > Changes look good. > BTW, need to add noreg-xxx label to the bug. @valeriepeng Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15113#issuecomment-1672476179 From jwaters at openjdk.org Thu Aug 10 04:04:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Aug 2023 04:04:58 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Remove negation in os_windows.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/51230f3d..4e3329b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From djelinski at openjdk.org Thu Aug 10 06:17:28 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 10 Aug 2023 06:17:28 GMT Subject: RFR: JDK-8312461 JNI warnings in SunMSCApi provider In-Reply-To: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> References: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> Message-ID: On Tue, 1 Aug 2023 21:08:49 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8312461 Marked as reviewed by djelinski (Reviewer). Please update the copyright year. ------------- PR Review: https://git.openjdk.org/jdk/pull/15113#pullrequestreview-1571072631 PR Comment: https://git.openjdk.org/jdk/pull/15113#issuecomment-1672603447 From ssahoo at openjdk.org Thu Aug 10 06:16:31 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Thu, 10 Aug 2023 06:16:31 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 00:56:56 GMT, Valerie Peng wrote: > Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. > > This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. > > The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). > > Thanks in advance for review~ Marked as reviewed by ssahoo (Committer). test/jdk/sun/security/pkcs11/PSSUtil.java line 45: > 43: public static boolean isSignatureSupported(Provider p) { > 44: try { > 45: Signature.getInstance("RSASSA-PSS", p); It can use the SIGALG constant name. ------------- PR Review: https://git.openjdk.org/jdk/pull/15217#pullrequestreview-1571040058 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1289565434 From mpowers at openjdk.org Thu Aug 10 15:10:58 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 10 Aug 2023 15:10:58 GMT Subject: RFR: JDK-8312461 JNI warnings in SunMSCApi provider [v2] In-Reply-To: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> References: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> Message-ID: <-POVsemJ6zt-PjiE6yLAbhwiC5oop7hvIQsYQ_aBVoM=.014c20b5-2959-4540-aed9-30a6bb78b66e@github.com> > https://bugs.openjdk.org/browse/JDK-8312461 Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - fix copyright - Merge - Merge - first iteration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15113/files - new: https://git.openjdk.org/jdk/pull/15113/files/50f1d16a..a5de49c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15113&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15113&range=00-01 Stats: 14494 lines in 728 files changed: 6144 ins; 4130 del; 4220 mod Patch: https://git.openjdk.org/jdk/pull/15113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15113/head:pull/15113 PR: https://git.openjdk.org/jdk/pull/15113 From djelinski at openjdk.org Thu Aug 10 15:10:59 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 10 Aug 2023 15:10:59 GMT Subject: RFR: JDK-8312461 JNI warnings in SunMSCApi provider [v2] In-Reply-To: <-POVsemJ6zt-PjiE6yLAbhwiC5oop7hvIQsYQ_aBVoM=.014c20b5-2959-4540-aed9-30a6bb78b66e@github.com> References: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> <-POVsemJ6zt-PjiE6yLAbhwiC5oop7hvIQsYQ_aBVoM=.014c20b5-2959-4540-aed9-30a6bb78b66e@github.com> Message-ID: On Thu, 10 Aug 2023 14:48:54 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8312461 > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - fix copyright > - Merge > - Merge > - first iteration Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15113#pullrequestreview-1572109247 From mpowers at openjdk.org Thu Aug 10 15:20:39 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 10 Aug 2023 15:20:39 GMT Subject: RFR: JDK-8312461 JNI warnings in SunMSCApi provider In-Reply-To: References: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> Message-ID: <-B6C9A2uDzairiCoq0dgWlzXruRddOAnMGLsHEYQZIo=.3b800ae4-9589-45e6-8834-0cb68c8c0404@github.com> On Thu, 10 Aug 2023 05:59:50 GMT, Daniel Jeli?ski wrote: >> https://bugs.openjdk.org/browse/JDK-8312461 > > Please update the copyright year. @djelinski Thanks for noticing the copyright. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15113#issuecomment-1673395179 From duke at openjdk.org Thu Aug 10 15:55:29 2023 From: duke at openjdk.org (Swati Sharma) Date: Thu, 10 Aug 2023 15:55:29 GMT Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests having shared state Message-ID: In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems. org/openjdk/bench/java/io/DataInputStreamTest.java org/openjdk/bench/java/lang/ArrayClone.java org/openjdk/bench/java/lang/StringCompareToDifferentLength.java org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java org/openjdk/bench/java/lang/StringComparisons.java org/openjdk/bench/java/lang/StringEquals.java org/openjdk/bench/java/lang/StringFormat.java org/openjdk/bench/java/lang/StringReplace.java org/openjdk/bench/java/lang/StringSubstring.java org/openjdk/bench/java/lang/StringTemplateFMT.java org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java org/openjdk/bench/java/security/CipherSuiteBench.java org/openjdk/bench/java/time/GetYearBench.java org/openjdk/bench/java/time/InstantBench.java org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java org/openjdk/bench/java/util/ListArgs.java org/openjdk/bench/java/util/LocaleDefaults.java org/openjdk/bench/java/util/TestAdler32.java org/openjdk/bench/java/util/TestCRC32.java org/openjdk/bench/java/util/TestCRC32C.java org/openjdk/bench/java/util/regex/Exponential.java org/openjdk/bench/java/util/regex/Primality.java org/openjdk/bench/java/util/regex/Trim.java org/openjdk/bench/javax/crypto/AESReinit.java org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java org/openjdk/bench/vm/compiler/Rotation.java org/openjdk/bench/vm/compiler/x86/ConvertF2I.java org/openjdk/bench/vm/compiler/x86/BasicRules.java Please review and provide your feedback. Thanks, Swati ------------- Commit messages: - 8314085: Fixing scope from benchmark to thread for JMH tests having shared state Changes: https://git.openjdk.org/jdk/pull/15230/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314085 Stats: 46 lines in 38 files changed: 0 ins; 0 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/15230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15230/head:pull/15230 PR: https://git.openjdk.org/jdk/pull/15230 From xuelei at openjdk.org Thu Aug 10 17:38:58 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 10 Aug 2023 17:38:58 GMT Subject: Integrated: 8312259: StatusResponseManager unused code clean up In-Reply-To: References: Message-ID: <_cQh9JNP-zWacVTfvA9xy2G7NIttJ7q0EXhQzIcf8lI=.58d69175-e583-48f3-9877-04011d990246@github.com> On Tue, 18 Jul 2023 17:43:42 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the code cleanup update reviewed? With this update, the unused code in StatusResponseManager.java will be removed. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: 79be8d93 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/79be8d9383c31be64e57ce1825a79dbbc2aefdd8 Stats: 173 lines in 2 files changed: 17 ins; 142 del; 14 mod 8312259: StatusResponseManager unused code clean up Reviewed-by: mpowers, jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/14924 From valeriep at openjdk.org Thu Aug 10 17:50:58 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Aug 2023 17:50:58 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 05:23:38 GMT, Sibabrata Sahoo wrote: >> Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. >> >> This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. >> >> The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). >> >> Thanks in advance for review~ > > test/jdk/sun/security/pkcs11/PSSUtil.java line 45: > >> 43: public static boolean isSignatureSupported(Provider p) { >> 44: try { >> 45: Signature.getInstance("RSASSA-PSS", p); > > It can use the SIGALG constant name. Sure ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290461034 From serb at openjdk.org Thu Aug 10 18:06:31 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 10 Aug 2023 18:06:31 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: <_JLMOkMI3dcALCt8DWbNi6t185-zadP9FU9XvQcJZqE=.e0b9cf5b-ac29-4b2c-a9a5-d5f9bf9d8eaa@github.com> Message-ID: On Wed, 9 Aug 2023 17:07:41 GMT, Valerie Peng wrote: >>> > Hi Valerie, we put the PR into our build/test queue to check if it solves some errors we currently notice in CertChainRemoval.java . >>> >>> Sure, thanks! What is the errors that you observed? Are you running against NSS and which version? >> >> Looks like the errors are gone with your patch added. >> Regarding NSS version, this is what rpm shows, I think this should be the version (on an RHEL 8.5 machine) >> >> nss-3.67.0-7.el8_5.ppc64le > >> > > Hi Valerie, we put the PR into our build/test queue to check if it solves some errors we currently notice in CertChainRemoval.java . >> > >> > >> > Sure, thanks! What is the errors that you observed? Are you running against NSS and which version? >> >> Looks like the errors are gone with your patch added. Regarding NSS version, this is what rpm shows, I think this should be the version (on an RHEL 8.5 machine) >> >> nss-3.67.0-7.el8_5.ppc64le > > Thanks for the confirmation! The next step is to find a reviewer for this PR then. ;) Hi, @valeriepeng On my system this test fails because the next exception, do you think it is related to this bug or the new one should be filed?: Initial PKCS11 KeyStore: ======== Add pk1, ca1 and root, then delete pk1 test CertChainRemoval.test(): failure java.security.KeyStoreException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_READ_ONLY at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetEntry(P11KeyStore.java:1121) at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetKeyEntry(P11KeyStore.java:462) at java.base/java.security.KeyStore.setKeyEntry(KeyStore.java:1192) at CertChainRemoval.main(CertChainRemoval.java:141) at PKCS11Test.premain(PKCS11Test.java:178) at PKCS11Test.testNSS(PKCS11Test.java:554) at PKCS11Test.main(PKCS11Test.java:214) at PKCS11Test.main(PKCS11Test.java:190) at CertChainRemoval.test(CertChainRemoval.java:77) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1673659583 From rhalade at openjdk.org Thu Aug 10 18:25:28 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 10 Aug 2023 18:25:28 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 00:56:56 GMT, Valerie Peng wrote: > Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. > > This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. > > The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). > > Thanks in advance for review~ test/jdk/sun/security/pkcs11/MessageDigest/TestCloning.java line 26: > 24: /* > 25: * @test > 26: * @bug 6414899 8242332 8312428 No need to add bug id for test only updates. test/jdk/sun/security/pkcs11/MessageDigest/TestCloning.java line 67: > 65: } catch (CloneNotSupportedException cnse) { > 66: // skip test if clone isn't supported > 67: System.out.println("=> Clone not supported; skip!"); Can you please update the test to throw SkippedException if no digest algorithms are found to not support clone? This would help us with coverage analysis. test/jdk/sun/security/pkcs11/PSSUtil.java line 24: > 22: */ > 23: import java.security.*; > 24: import java.security.interfaces.*; Please remove unused imports test/jdk/sun/security/pkcs11/PSSUtil.java line 34: > 32: private static final String KEYALG = "RSA"; > 33: private static final String SIGALG = "RSASSA-PSS"; > 34: private static final String[] DIGESTS = { is this constant used anywhere or supposed to be used? test/jdk/sun/security/pkcs11/PSSUtil.java line 59: > 57: for (String h : hashAlgs) { > 58: String sigAlg = (h.startsWith("SHA3-")? > 59: h : h.replace("-","")) + "withRSASSA-PSS"; Suggestion: String sigAlg = (h.startsWith("SHA3-") ? h : h.replace("-", "")) + "withRSASSA-PSS"; test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 51: > 49: public void main(Provider p) throws Exception { > 50: if (!PSSUtil.isSignatureSupported(p)) { > 51: System.out.println("Skip testing RSASSA-PSS" + Update to throw SkippedException. test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 75: > 73: runTest(p, 1040, "SHA3-512", "SHA3-256"); > 74: runTest(p, 1040, "SHA3-512", "SHA3-384"); > 75: runTest(p, 1040, "SHA3-512", "SHA3-512"); Similar check can be added here to throw SkippedException if all runTest call skip testing. test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 129: > 127: sig.setParameter(paramsGood); > 128: sig.initVerify(pub); > 129: System.out.println("test#2: good params pass"); Either add a `test#1` message after `initSign` test or update this to remove `#2` test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 66: > 64: public void main(Provider p) throws Exception { > 65: if (!PSSUtil.isSignatureSupported(p)) { > 66: System.out.println("Skip testing RSASSA-PSS" + throw SkippedException here. test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 83: > 81: PSSUtil.isHashSupported(p, hash, mgfHash); > 82: if (s == PSSUtil.AlgoSupport.NO) { > 83: System.out.println(" => Skip; no support"); Similar request here to mark test as skipped if all algorithms are not supported. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290485564 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290488107 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290509833 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290510886 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290513331 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290490575 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290492472 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290494138 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290496752 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290497611 From valeriep at openjdk.org Thu Aug 10 18:41:34 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Aug 2023 18:41:34 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v2] In-Reply-To: References: Message-ID: <_8maAgdE11L5qGaV0B_unrWKFPQvIHKzsvseEKaES1U=.ca6f5887-e699-461d-bdc3-3b7dafbcb502@github.com> > Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. > > This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. > > The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). > > Thanks in advance for review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: address review feedbacks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15217/files - new: https://git.openjdk.org/jdk/pull/15217/files/ca1a3b92..4306fa1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15217&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15217&range=00-01 Stats: 11 lines in 3 files changed: 0 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15217/head:pull/15217 PR: https://git.openjdk.org/jdk/pull/15217 From rhalade at openjdk.org Thu Aug 10 18:41:34 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 10 Aug 2023 18:41:34 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 00:56:56 GMT, Valerie Peng wrote: > Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. > > This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. > > The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). > > Thanks in advance for review~ Can you please also update https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/pkcs11/PKCS11Test.java#L1002 to use 3.91? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15217#issuecomment-1673690234 From valeriep at openjdk.org Thu Aug 10 18:51:28 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Aug 2023 18:51:28 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 17:51:41 GMT, Rajan Halade wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> address review feedbacks > > test/jdk/sun/security/pkcs11/MessageDigest/TestCloning.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 6414899 8242332 8312428 > > No need to add bug id for test only updates. Ok. > test/jdk/sun/security/pkcs11/MessageDigest/TestCloning.java line 67: > >> 65: } catch (CloneNotSupportedException cnse) { >> 66: // skip test if clone isn't supported >> 67: System.out.println("=> Clone not supported; skip!"); > > Can you please update the test to throw SkippedException if no digest algorithms are found to not support clone? This would help us with coverage analysis. Do you mean throw SkippedException if no digest algorithms are actually tested with Clone functionality testing? Existing NSS impl seems to support clone for non-SHA-3 digest impls. > test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 51: > >> 49: public void main(Provider p) throws Exception { >> 50: if (!PSSUtil.isSignatureSupported(p)) { >> 51: System.out.println("Skip testing RSASSA-PSS" + > > Update to throw SkippedException. Ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290542665 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290546013 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290546289 From valeriep at openjdk.org Thu Aug 10 19:05:31 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Aug 2023 19:05:31 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 17:56:56 GMT, Rajan Halade wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> address review feedbacks > > test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 75: > >> 73: runTest(p, 1040, "SHA3-512", "SHA3-256"); >> 74: runTest(p, 1040, "SHA3-512", "SHA3-384"); >> 75: runTest(p, 1040, "SHA3-512", "SHA3-512"); > > Similar check can be added here to throw SkippedException if all runTest call skip testing. Ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290555774 From rhalade at openjdk.org Thu Aug 10 20:02:58 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 10 Aug 2023 20:02:58 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v2] In-Reply-To: <_8maAgdE11L5qGaV0B_unrWKFPQvIHKzsvseEKaES1U=.ca6f5887-e699-461d-bdc3-3b7dafbcb502@github.com> References: <_8maAgdE11L5qGaV0B_unrWKFPQvIHKzsvseEKaES1U=.ca6f5887-e699-461d-bdc3-3b7dafbcb502@github.com> Message-ID: On Thu, 10 Aug 2023 18:41:34 GMT, Valerie Peng wrote: >> Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. >> >> This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. >> >> The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). >> >> Thanks in advance for review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > address review feedbacks Changes requested by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15217#pullrequestreview-1572621403 From rhalade at openjdk.org Thu Aug 10 20:06:28 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 10 Aug 2023 20:06:28 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v2] In-Reply-To: References: Message-ID: <41Uo_jj10HpKlqKPUvE55ePnE_9PaAHEj1i4Hi-Fl20=.869abb9c-6578-4857-99bd-355cdaa42e84@github.com> On Thu, 10 Aug 2023 18:42:58 GMT, Valerie Peng wrote: >> test/jdk/sun/security/pkcs11/MessageDigest/TestCloning.java line 67: >> >>> 65: } catch (CloneNotSupportedException cnse) { >>> 66: // skip test if clone isn't supported >>> 67: System.out.println("=> Clone not supported; skip!"); >> >> Can you please update the test to throw SkippedException if no digest algorithms are found to not support clone? This would help us with coverage analysis. > > Do you mean throw SkippedException if no digest algorithms are actually tested with Clone functionality testing? Existing NSS impl seems to support clone for non-SHA-3 digest impls. Yes, test should throw SkippedException when nothing is tested. >> test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 66: >> >>> 64: public void main(Provider p) throws Exception { >>> 65: if (!PSSUtil.isSignatureSupported(p)) { >>> 66: System.out.println("Skip testing RSASSA-PSS" + >> >> throw SkippedException here. > > Ok. I initially thought that the SkippedException only applies to library not found and/or un-configured OS. With this extension of the meaning of SkippedException, many of the existing tests have to be updated to match. Yes, I did #1 update with [JDK-8313206](https://bugs.openjdk.org/browse/JDK-8313206) and plan to do update more scenarios with [JDK-8313575](https://bugs.openjdk.org/browse/JDK-8313575) >> test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 83: >> >>> 81: PSSUtil.isHashSupported(p, hash, mgfHash); >>> 82: if (s == PSSUtil.AlgoSupport.NO) { >>> 83: System.out.println(" => Skip; no support"); >> >> Similar request here to mark test as skipped if all algorithms are not supported. > > This is just one digest algorithm. To mark the test skipped if none of the algorithms are supported will require different handling. Yes est should only throw `SkippedEXception` when all algos are skipped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290597857 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290609160 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290613005 From valeriep at openjdk.org Thu Aug 10 20:08:58 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Aug 2023 20:08:58 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 18:12:59 GMT, Rajan Halade wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> address review feedbacks > > test/jdk/sun/security/pkcs11/PSSUtil.java line 24: > >> 22: */ >> 23: import java.security.*; >> 24: import java.security.interfaces.*; > > Please remove unused imports Sure > test/jdk/sun/security/pkcs11/PSSUtil.java line 34: > >> 32: private static final String KEYALG = "RSA"; >> 33: private static final String SIGALG = "RSASSA-PSS"; >> 34: private static final String[] DIGESTS = { > > is this constant used anywhere or supposed to be used? Removed. > test/jdk/sun/security/pkcs11/PSSUtil.java line 59: > >> 57: for (String h : hashAlgs) { >> 58: String sigAlg = (h.startsWith("SHA3-")? >> 59: h : h.replace("-","")) + "withRSASSA-PSS"; > > Suggestion: > > String sigAlg = (h.startsWith("SHA3-") ? > h : h.replace("-", "")) + "withRSASSA-PSS"; Ok. > test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 129: > >> 127: sig.setParameter(paramsGood); >> 128: sig.initVerify(pub); >> 129: System.out.println("test#2: good params pass"); > > Either add a `test#1` message after `initSign` test or update this to remove `#2` test#1 message matches with test#2 ones. Anyway, I removed the test output messages with your comments. > test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 66: > >> 64: public void main(Provider p) throws Exception { >> 65: if (!PSSUtil.isSignatureSupported(p)) { >> 66: System.out.println("Skip testing RSASSA-PSS" + > > throw SkippedException here. Ok. I initially thought that the SkippedException only applies to library not found and/or un-configured OS. With this extension of the meaning of SkippedException, many of the existing tests have to be updated to match. > test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 83: > >> 81: PSSUtil.isHashSupported(p, hash, mgfHash); >> 82: if (s == PSSUtil.AlgoSupport.NO) { >> 83: System.out.println(" => Skip; no support"); > > Similar request here to mark test as skipped if all algorithms are not supported. This is just one digest algorithm. To mark the test skipped if none of the algorithms are supported will require different handling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290608992 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290607168 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290614205 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290598689 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290601153 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1290602675 From valeriep at openjdk.org Thu Aug 10 20:29:29 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Aug 2023 20:29:29 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v3] In-Reply-To: References: Message-ID: > Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. > > This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. > > The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). > > Thanks in advance for review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: More review feedbacks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15217/files - new: https://git.openjdk.org/jdk/pull/15217/files/4306fa1c..499e9636 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15217&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15217&range=01-02 Stats: 46 lines in 3 files changed: 30 ins; 5 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/15217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15217/head:pull/15217 PR: https://git.openjdk.org/jdk/pull/15217 From valeriep at openjdk.org Thu Aug 10 20:29:58 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Aug 2023 20:29:58 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 18:16:57 GMT, Rajan Halade wrote: > Can you please also update https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/pkcs11/PKCS11Test.java#L1002 to use 3.91? Are you suggesting to use 3.91 for all the OS configurations? Based on my experiment, many of the mach5 linux x64 machines miss the required library for the NSS v3.91. I ended up using an older version of sqlite3 and test the changes locally. Thus, I have not changed the NSS version in the PKCS11Test.java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15217#issuecomment-1673834422 From rhalade at openjdk.org Thu Aug 10 20:33:28 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 10 Aug 2023 20:33:28 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v2] In-Reply-To: <_8maAgdE11L5qGaV0B_unrWKFPQvIHKzsvseEKaES1U=.ca6f5887-e699-461d-bdc3-3b7dafbcb502@github.com> References: <_8maAgdE11L5qGaV0B_unrWKFPQvIHKzsvseEKaES1U=.ca6f5887-e699-461d-bdc3-3b7dafbcb502@github.com> Message-ID: On Thu, 10 Aug 2023 18:41:34 GMT, Valerie Peng wrote: >> Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. >> >> This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. >> >> The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). >> >> Thanks in advance for review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > address review feedbacks > Ok, lets address this update in a separate bug after validating all platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15217#issuecomment-1673838135 From valeriep at openjdk.org Fri Aug 11 00:02:28 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 11 Aug 2023 00:02:28 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote: > This change addresses the scenario where a certificate is first stored as part of a certificate chain and then stored again as a certificate corresponding to a PrivateKey entry. Newer version of NSS errors out with CKR_GENERAL_ERROR with the 2nd store, i.e. C_CreateObject() call. > > Proposed fix is to check for match before calling C_CreateObject(), if a match is found, set its alias instead. > Hmm, does the test fail with the changes in this PR or without? Are you also using NSS and which version? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1674060172 From mpowers at openjdk.org Fri Aug 11 00:04:28 2023 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 11 Aug 2023 00:04:28 GMT Subject: Integrated: JDK-8312461 JNI warnings in SunMSCApi provider In-Reply-To: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> References: <9Cq62JPjMtD9BCNB1NTD9XXtrUCz9r8QYVgepeQJ4IE=.0619c1de-db3c-4b60-9b52-7a3882093330@github.com> Message-ID: On Tue, 1 Aug 2023 21:08:49 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8312461 This pull request has now been integrated. Changeset: 9abb2a55 Author: Mark Powers Committer: Valerie Peng URL: https://git.openjdk.org/jdk/commit/9abb2a559e4f809f07db1b747660f68b9d943e3b Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8312461: JNI warnings in SunMSCApi provider Reviewed-by: valeriep, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/15113 From duke at openjdk.org Fri Aug 11 03:44:35 2023 From: duke at openjdk.org (duke) Date: Fri, 11 Aug 2023 03:44:35 GMT Subject: Withdrawn: 8308592: Framework for CA interoperability testing 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: <7iu316XbxHOeKcDvx1UMMoLGXt1TePi2St8liKCheGU=.b75d15e4-cce2-4043-b804-aaee4c1afcbd@github.com> On Wed, 31 May 2023 18:03:57 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14252 From jpai at openjdk.org Fri Aug 11 06:05:59 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 11 Aug 2023 06:05:59 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v2] In-Reply-To: References: Message-ID: <6XMnLvTTYneeEV8MUoRwbBfwITkMjJj9UHVgQhaO-yA=.d9082e44-35f4-4616-a86e-938d1dd69807@github.com> On Wed, 26 Apr 2023 11:51:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? >> >> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. >> >> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. >> >> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. >> >> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review comment - use SSLContextTemplate for SSLContext creation in test Please keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/13669#issuecomment-1674242187 From jwaters at openjdk.org Fri Aug 11 08:02:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 11 Aug 2023 08:02:58 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com> Message-ID: On Wed, 9 Aug 2023 06:30:08 GMT, Thomas Stuefe wrote: >> This is a weird one, but in awt we #define malloc Do_Not_Use_Malloc... And so on. Without this reordering awt_ole.h (which includes comdef.h) also uses the redefined malloc somewhere (I could not find where in comip.h that it's used) which breaks compilation. I do find it strange that without permissive- it doesn't break though. Same applies to the other reordering of includes > > Oh. That's not good. Having such an undocumented reliance on order of include just begs to bitrot at some point. Any chance you could unravel that mystery, maybe in a later RFE? For now, can you please add a comment at those places where you changed include order for that reason? I can try doing that, yes. There was actually a commit before this one that addressed the same issue in awt, but it missed this one since without -permissive- this error isn't caught, see [8241087](https://bugs.openjdk.org/browse/JDK-8241087) Looking at the error logs, I believe this may be due to an issue this causes with templates in the comip.h header, but I don't think that's the main problem to be worried about, rather it's that malloc (and calloc and realloc and the JDK's ExceptionOccured method too by the way) is redefined like this in the first place. I don't have any ideas for how to deal with that at the moment unfortunately ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1291004217 From djelinski at openjdk.org Fri Aug 11 09:19:29 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Aug 2023 09:19:29 GMT Subject: RFR: 8314148: Fix variable scope in SunMSCAPI Message-ID: Please review this patch that fixes the scope of 2 local variables to make sure they are in scope when they are used. The patch additionally fixes one `c++11-narrowing` Clang warning by explicitly casting string size (`size_t`) to `DWORD`. ------------- Commit messages: - Fix variable scope Changes: https://git.openjdk.org/jdk/pull/15242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314148 Stats: 9 lines in 3 files changed: 2 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15242/head:pull/15242 PR: https://git.openjdk.org/jdk/pull/15242 From mbaesken at openjdk.org Fri Aug 11 12:11:30 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 11 Aug 2023 12:11:30 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote: > This change addresses the scenario where a certificate is first stored as part of a certificate chain and then stored again as a certificate corresponding to a PrivateKey entry. Newer version of NSS errors out with CKR_GENERAL_ERROR with the 2nd store, i.e. C_CreateObject() call. > > Proposed fix is to check for match before calling C_CreateObject(), if a match is found, set its alias instead. Marked as reviewed by mbaesken (Reviewer). Looks okay to me and seems to fix the issues we faced in our test infrastructure; seems to need backport to jdk21. Would be great to have a second reviewer who is working more actively in this area of the JDK codebase. ------------- PR Review: https://git.openjdk.org/jdk/pull/15146#pullrequestreview-1573515639 PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1674622671 From mdonovan at openjdk.org Fri Aug 11 16:23:58 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 11 Aug 2023 16:23:58 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 08:17:39 GMT, Daniel Jeli?ski wrote: > Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. > > All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. > > SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. > > Tier1-3 tests pass. test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineDecodeBadPoint.java line 40: > 38: public class SSLEngineDecodeBadPoint { > 39: static final byte[] clientHello = HexFormat.of().parseHex( > 40: "160303013a0100013603031570" + This may be the github display but this line is indented differently than the others. test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineDecodeBadPoint.java line 76: > 74: eng.wrap(emptyBuf, alert); > 75: throw new RuntimeException("Expected wrap to throw"); > 76: } catch (Exception e) { Catching `Exception` here will consume the RuntimeException being thrown. test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineDecodeBadPoint.java line 77: > 75: throw new RuntimeException("Expected wrap to throw"); > 76: } catch (Exception e) { > 77: System.err.println("Received expected exception:"); I find it useful when looking at logs to have the message explicitly say what exception is expected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1291554810 PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1291553638 PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1291554198 From mpowers at openjdk.org Fri Aug 11 17:03:33 2023 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 11 Aug 2023 17:03:33 GMT Subject: RFR: 8314148: Fix variable scope in SunMSCAPI In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 06:36:42 GMT, Daniel Jeli?ski wrote: > Please review this patch that fixes the scope of 2 local variables to make sure they are in scope when they are used. > > The patch additionally fixes one `c++11-narrowing` Clang warning by explicitly casting string size (`size_t`) to `DWORD`. src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 946: > 944: break; > 945: case 1: > 946: BCRYPT_PKCS1_PADDING_INFO pkcs1Info; Don't lines 1181 and 1196 have the same problem? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15242#discussion_r1291587437 From duke at openjdk.org Fri Aug 11 17:31:58 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 11 Aug 2023 17:31:58 GMT Subject: RFR: 8175874: Security.insertProviderAt should throw IllegalArgumentException when index is illegal [v2] In-Reply-To: References: Message-ID: <3wq26XmXLaE0XwAHdppho_wT8rzIboBzx1wa4Z0y_n4=.6bbb5174-c2ca-481d-a615-6cfe601a80f9@github.com> > Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have left an `@implNote` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Removed implnote and added to function specification instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14925/files - new: https://git.openjdk.org/jdk/pull/14925/files/274ef511..b8c4bf7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=00-01 Stats: 8 lines in 1 file changed: 3 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14925/head:pull/14925 PR: https://git.openjdk.org/jdk/pull/14925 From duke at openjdk.org Fri Aug 11 17:39:59 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 11 Aug 2023 17:39:59 GMT Subject: RFR: 8314059: Remove PKCS7.verify() Message-ID: Removed PKCS7.verify() since no other code in JDK calls it. ------------- Commit messages: - removed verify method that takes no arguments Changes: https://git.openjdk.org/jdk/pull/15251/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314059 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15251/head:pull/15251 PR: https://git.openjdk.org/jdk/pull/15251 From duke at openjdk.org Fri Aug 11 18:41:35 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 11 Aug 2023 18:41:35 GMT Subject: RFR: 8175874: Define algorithm names for keys derived from KeyAgreement [v3] In-Reply-To: References: Message-ID: > Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have left an `@implNote` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Changed wording in spec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14925/files - new: https://git.openjdk.org/jdk/pull/14925/files/b8c4bf7c..77655b5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14925/head:pull/14925 PR: https://git.openjdk.org/jdk/pull/14925 From mullan at openjdk.org Fri Aug 11 18:51:31 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 11 Aug 2023 18:51:31 GMT Subject: RFR: 8314059: Remove PKCS7.verify() In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 17:23:52 GMT, Ben Perez wrote: > Removed PKCS7.verify() since no other code in JDK calls it. Update the copyright to include 2023. ------------- Changes requested by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15251#pullrequestreview-1574196255 From djelinski at openjdk.org Fri Aug 11 19:36:28 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Aug 2023 19:36:28 GMT Subject: RFR: 8314148: Fix variable scope in SunMSCAPI In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 16:53:41 GMT, Mark Powers wrote: >> Please review this patch that fixes the scope of 2 local variables to make sure they are in scope when they are used. >> >> The patch additionally fixes one `c++11-narrowing` Clang warning by explicitly casting string size (`size_t`) to `DWORD`. > > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 946: > >> 944: break; >> 945: case 1: >> 946: BCRYPT_PKCS1_PADDING_INFO pkcs1Info; > > Don't lines 1181 and 1196 have the same problem? Good catch! Interestingly, that code appears to compile correctly. I'll fix it anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15242#discussion_r1291701470 From djelinski at openjdk.org Fri Aug 11 20:15:59 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Aug 2023 20:15:59 GMT Subject: RFR: 8314148: Fix variable scope in SunMSCAPI [v2] In-Reply-To: References: Message-ID: > Please review this patch that fixes the scope of 2 local variables to make sure they are in scope when they are used. > > The patch additionally fixes one `c++11-narrowing` Clang warning by explicitly casting string size (`size_t`) to `DWORD`. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: fix verify method, reduce variable scope ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15242/files - new: https://git.openjdk.org/jdk/pull/15242/files/ea9b8caa..e66639c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15242&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15242&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15242/head:pull/15242 PR: https://git.openjdk.org/jdk/pull/15242 From mpowers at openjdk.org Fri Aug 11 20:49:58 2023 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 11 Aug 2023 20:49:58 GMT Subject: RFR: 8314148: Fix variable scope in SunMSCAPI [v2] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 20:15:59 GMT, Daniel Jeli?ski wrote: >> Please review this patch that fixes the scope of 2 local variables to make sure they are in scope when they are used. >> >> The patch additionally fixes one `c++11-narrowing` Clang warning by explicitly casting string size (`size_t`) to `DWORD`. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > fix verify method, reduce variable scope Looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15242#issuecomment-1675366834 From djelinski at openjdk.org Fri Aug 11 21:38:04 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Aug 2023 21:38:04 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: > Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. > > All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. > > SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. > > Tier1-3 tests pass. Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: - Fix exception handling - Fix indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15148/files - new: https://git.openjdk.org/jdk/pull/15148/files/4e2d43de..33fee1fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15148&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15148&range=00-01 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15148/head:pull/15148 PR: https://git.openjdk.org/jdk/pull/15148 From djelinski at openjdk.org Fri Aug 11 21:38:30 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Aug 2023 21:38:30 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 16:17:23 GMT, Matthew Donovan wrote: >> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix exception handling >> - Fix indentation > > test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineDecodeBadPoint.java line 40: > >> 38: public class SSLEngineDecodeBadPoint { >> 39: static final byte[] clientHello = HexFormat.of().parseHex( >> 40: "160303013a0100013603031570" + > > This may be the github display but this line is indented differently than the others. Thanks for pointing it out, fixed. Apparently my IntelliJ prefers this style of formatting multiline strings. I wonder if that's configurable. > test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineDecodeBadPoint.java line 76: > >> 74: eng.wrap(emptyBuf, alert); >> 75: throw new RuntimeException("Expected wrap to throw"); >> 76: } catch (Exception e) { > > Catching `Exception` here will consume the RuntimeException being thrown. oops, right. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1291782404 PR Review Comment: https://git.openjdk.org/jdk/pull/15148#discussion_r1291782566 From abakhtin at openjdk.org Fri Aug 11 23:34:59 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Fri, 11 Aug 2023 23:34:59 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method Message-ID: JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS. This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior ------------- Commit messages: - 8311532: Option to disable Krb5LoginModule::login method Changes: https://git.openjdk.org/jdk/pull/15254/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15254&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311532 Stats: 38 lines in 1 file changed: 38 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15254/head:pull/15254 PR: https://git.openjdk.org/jdk/pull/15254 From serb at openjdk.org Sat Aug 12 00:00:28 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 12 Aug 2023 00:00:28 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 23:46:25 GMT, Valerie Peng wrote: > > > > Hmm, does the test fail with the changes in this PR or without? Are you also using NSS and which version? It fails with and w/o this patch, looks like related to the https://bugs.openjdk.org/browse/JDK-8232153 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1675532968 From jwaters at openjdk.org Mon Aug 14 03:48:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Aug 2023 03:48:58 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove negation in os_windows.cpp Bumping, anything from security and awt folk? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1676618114 From mbaesken at openjdk.org Mon Aug 14 08:10:59 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 14 Aug 2023 08:10:59 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase Message-ID: Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. Some examples : Events::log_dll_message for hs-err files reporting JFR event NativeLibraryLoad There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information Offer an interface (e.g. jvm.cpp) to support this. ------------- Commit messages: - JDK-8313764 Changes: https://git.openjdk.org/jdk/pull/15264/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313764 Stats: 150 lines in 7 files changed: 150 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264 PR: https://git.openjdk.org/jdk/pull/15264 From alanb at openjdk.org Mon Aug 14 09:06:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 14 Aug 2023 09:06:33 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Having dlopen usages in non-core native libraries such as such as libsctp, libawt_xawt, ... have their dlopen usages compiled to use dlopen_ext in libjvm introduces questionable coupling that I think requires broader discussion. For the JFR NativeLibraryLoad event then I suppose there is a discussion on whether events for statically or dynamically loaded libs is interesting or not as there isn't a corresponding System.loadLibrary or SymbolLookup.libraryLookup. JDK-8314152 seems to very AIX specific with shared lib caching that I would hope complicate interfaces for other ports. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1676938047 From mbaesken at openjdk.org Mon Aug 14 10:21:00 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 14 Aug 2023 10:21:00 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Hi Alan, > JDK-8314152 seems to very AIX specific with shared lib caching that I would hope complicate interfaces for other ports. yes this is of course AIX specific. However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1677045118 From ascarpino at openjdk.org Mon Aug 14 16:11:06 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 14 Aug 2023 16:11:06 GMT Subject: RFR: 8314045: ArithmeticException in GaloisCounterMode [v2] In-Reply-To: References: <9v7Pb-V5aRBRkVuM7nmxMO6HAab6j1SDmchGHKmAQoQ=.a83ba417-0bba-48e6-9317-3ef9410e5c46@github.com> Message-ID: <4gqKv9A7iQeF8yz5_223ljKlwtumvYVhe7BVjJS4KBY=.9200c821-1bdc-4cb2-ada8-57fae04e4a37@github.com> On Wed, 9 Aug 2023 23:41:29 GMT, Liam Miller-Cushon wrote: >> Please consider this fix for [JDK-8314045](https://bugs.openjdk.org/browse/JDK-8314045), which adds a missing size check to avoid an `ArithmeticException` in `GaloisCounterMode`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Check for AEADBadTagException specifically Changes look good ------------- Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15212#pullrequestreview-1577136079 From cushon at openjdk.org Mon Aug 14 16:11:28 2023 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 14 Aug 2023 16:11:28 GMT Subject: Integrated: 8314045: ArithmeticException in GaloisCounterMode In-Reply-To: <9v7Pb-V5aRBRkVuM7nmxMO6HAab6j1SDmchGHKmAQoQ=.a83ba417-0bba-48e6-9317-3ef9410e5c46@github.com> References: <9v7Pb-V5aRBRkVuM7nmxMO6HAab6j1SDmchGHKmAQoQ=.a83ba417-0bba-48e6-9317-3ef9410e5c46@github.com> Message-ID: On Wed, 9 Aug 2023 17:57:30 GMT, Liam Miller-Cushon wrote: > Please consider this fix for [JDK-8314045](https://bugs.openjdk.org/browse/JDK-8314045), which adds a missing size check to avoid an `ArithmeticException` in `GaloisCounterMode`. This pull request has now been integrated. Changeset: f41c267f Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/f41c267f859c305a2d01c629dbc56692322f81e2 Stats: 65 lines in 2 files changed: 65 ins; 0 del; 0 mod 8314045: ArithmeticException in GaloisCounterMode Co-authored-by: Ioana Nedelcu Reviewed-by: ascarpino ------------- PR: https://git.openjdk.org/jdk/pull/15212 From duke at openjdk.org Mon Aug 14 16:50:58 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 14 Aug 2023 16:50:58 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method In-Reply-To: References: Message-ID: <3h-LW3lIYVIa3v69KBv_I2X11n1sR9d8hq2ZkgS54x4=.22c8922a-4895-4555-ba78-506053bdd226@github.com> On Fri, 11 Aug 2023 23:08:56 GMT, Alexey Bakhtin wrote: > JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS. > > This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior Any particular reason why the configuration option is not called `skipLogin`? Seems to me that setting "doNot" to `true` requires a bit of unnecessary metal boolean algebra and is easier to get wrong. Or is this for consistency with `doNotPrompt`? My general preference is to avoid using "negative" options such that when something is disabled or skipped, the value can be set to `false` instead of `true`. So I would prefer `doLogin=false` over `skipLogin=true`. But I guess this is a matter of preference and since all other configuration options seem to default to `false`, consistency might be an issue also in this regard. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1677662703 From duke at openjdk.org Mon Aug 14 17:00:58 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 14 Aug 2023 17:00:58 GMT Subject: RFR: 8314059: Remove PKCS7.verify() [v2] In-Reply-To: References: Message-ID: <9Enj5tIZgVfgfy0UZCzQoKV-gkD1DbhC81_29tozPTA=.5f203ca8-36d5-407b-a177-a109dfc2ef0a@github.com> > Removed PKCS7.verify() since no other code in JDK calls it. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Updated copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15251/files - new: https://git.openjdk.org/jdk/pull/15251/files/4ca757e1..4e34e6a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15251&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15251&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15251/head:pull/15251 PR: https://git.openjdk.org/jdk/pull/15251 From mullan at openjdk.org Mon Aug 14 17:22:05 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Aug 2023 17:22:05 GMT Subject: RFR: 8314059: Remove PKCS7.verify() [v2] In-Reply-To: <9Enj5tIZgVfgfy0UZCzQoKV-gkD1DbhC81_29tozPTA=.5f203ca8-36d5-407b-a177-a109dfc2ef0a@github.com> References: <9Enj5tIZgVfgfy0UZCzQoKV-gkD1DbhC81_29tozPTA=.5f203ca8-36d5-407b-a177-a109dfc2ef0a@github.com> Message-ID: On Mon, 14 Aug 2023 17:00:58 GMT, Ben Perez wrote: >> Removed PKCS7.verify() since no other code in JDK calls it. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15251#pullrequestreview-1577282453 From duke at openjdk.org Mon Aug 14 18:42:00 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 14 Aug 2023 18:42:00 GMT Subject: Integrated: 8314059: Remove PKCS7.verify() In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 17:23:52 GMT, Ben Perez wrote: > Removed PKCS7.verify() since no other code in JDK calls it. This pull request has now been integrated. Changeset: 595fdd36 Author: Ben Perez Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/595fdd36c5f735b53ed2950c539be46382f9bcdd Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod 8314059: Remove PKCS7.verify() Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/15251 From abakhtin at openjdk.org Mon Aug 14 19:39:05 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Mon, 14 Aug 2023 19:39:05 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method In-Reply-To: <3h-LW3lIYVIa3v69KBv_I2X11n1sR9d8hq2ZkgS54x4=.22c8922a-4895-4555-ba78-506053bdd226@github.com> References: <3h-LW3lIYVIa3v69KBv_I2X11n1sR9d8hq2ZkgS54x4=.22c8922a-4895-4555-ba78-506053bdd226@github.com> Message-ID: <9oPwmhJAbpZowM9Y8Z-nzD6w8scvYOfnXG2wELA3z9I=.6dab12f7-667f-4df7-882b-3f98e6d7f6aa@github.com> On Mon, 14 Aug 2023 16:28:24 GMT, Eirik Bjorsnos wrote: >> JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS. >> >> This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior > > Any particular reason why the configuration option is not called `skipLogin` as well? Seems to me that setting `doNot*` to `true` requires a bit of unnecessary metal boolean algebra and is easier to get wrong? Or is this for consistency with `doNotPrompt`? > > My general preference is to avoid using "negative" options such that when something is disabled or skipped, the value can be set to `false` instead of `true`. So I would prefer `doLogin=false` over `skipLogin=true`. But I guess this is a matter of preference and since all other configuration options seem to default to `false`, consistency might be an issue also in this regard. Hello @eirbjo Thank you for the review! Naming, of course, can be discussed and changed. I am mostly concerned about the general idea of disabling the login method. I've tried to make different naming for the System property and configuration option, so they are not messed up. I propose `doNotLogin` option name for consistency with `doNotPrompt` and compatibility with current behavior. You just need to add `doNotLogin=true` to change the behavior. The default value, if neither is set, is the old behavior. Using system and configuration options would definitely not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the behavior as they need it ? i.e. they could set the option in JAAS to not skip the login if they need the private keys to be added to the Subject, and leave it to the system property if they only care for JGSS to work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1677947247 From duke at openjdk.org Mon Aug 14 19:57:06 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 14 Aug 2023 19:57:06 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method In-Reply-To: <9oPwmhJAbpZowM9Y8Z-nzD6w8scvYOfnXG2wELA3z9I=.6dab12f7-667f-4df7-882b-3f98e6d7f6aa@github.com> References: <3h-LW3lIYVIa3v69KBv_I2X11n1sR9d8hq2ZkgS54x4=.22c8922a-4895-4555-ba78-506053bdd226@github.com> <9oPwmhJAbpZowM9Y8Z-nzD6w8scvYOfnXG2wELA3z9I=.6dab12f7-667f-4df7-882b-3f98e6d7f6aa@github.com> Message-ID: On Mon, 14 Aug 2023 19:36:41 GMT, Alexey Bakhtin wrote: > Naming, of course, can be discussed and changed. Yes, naming is hard :-) > I've tried to make different naming for the System property and configuration option, so they are not messed up. I would think having two different names for essentially the same think (just different scopes) would make it easier to mess things up? If consistency with `doNotPrompt` is important, would it not be better to have: `doNotLogin` for the configuration option and `sun.security.auth.doNotLogin` for the system property? I'm not sure using different names here would reduce the risk of mistakes. But my guess is as good as yours. Is there precedence for doing it this way? One could claim that this is non-important details, but I think getting it right here can help prevent misconfigurations. My opinions here are weakly held. Perhaps some other reviewers could chime in? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1677969931 From abakhtin at openjdk.org Mon Aug 14 20:06:18 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Mon, 14 Aug 2023 20:06:18 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 23:08:56 GMT, Alexey Bakhtin wrote: > JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS. > > This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior OK. You convinced me. I will rename the system property to `sun.security.auth.doNotLogin` if no other suggestions. Thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1677981347 From duke at openjdk.org Mon Aug 14 20:41:06 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 14 Aug 2023 20:41:06 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 23:08:56 GMT, Alexey Bakhtin wrote: > JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS. > > This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior `sun.security.auth.doNotLogin` does not indicate at all that this property is related to Kerberos. Would it be worth adding `krb5` somewhere in the name, something like: `sun.security.auth.krb5.doNotLogin` ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1678024245 From prr at openjdk.org Mon Aug 14 20:42:07 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Aug 2023 20:42:07 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. I don't see why we need this .. The desktop module has a LOT of calls to dlopen() .. I wasn't sure why you were only interested in two of them. I suspect because there's #ifdef AIX blocks in both of these files that do AIX-specific things for the dlopen .. but I'm still not sure I understand .. why is what you are doing only wanted for the AIX cases ? And I'd prefer that if anything is done that whatever you need to do be entirely within that #ifdef AIX block and so not affect anything else. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678026889 From prr at openjdk.org Mon Aug 14 21:00:14 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Aug 2023 21:00:14 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove negation in os_windows.cpp I have no time to look at the client changes for quite some time so do not push it. No matter how many other people approve it. And in the meantime you can (1) explain how many client tests you ran - and it had better be all of them :-) (2) add a comment in the PR to explain each client change you made - at the site of the change. Comments like "Fields in awt_TextComponent.cpp" are not an explanation (3) On the broader front, I note that you just start off with "We should set the -permissive- flag for the Microsoft Visual C compiler" without explaining WHY and what it does. In fact from what I've read about -it seems like we would not want it .. it downgrades errors to warnings .. and surely that's a bad thing ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1678049894 From mullan at openjdk.org Mon Aug 14 21:09:08 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Aug 2023 21:09:08 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v3] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 18:41:35 GMT, Ben Perez wrote: >> Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have left an `@implNote` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed wording in spec Minor comment - before integrating, update the PR description to reflect the latest change (it still says we will add an `@implNote`.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14925#issuecomment-1678061810 From mullan at openjdk.org Mon Aug 14 21:21:09 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Aug 2023 21:21:09 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v3] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 18:41:35 GMT, Ben Perez wrote: >> Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have left an `@implNote` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed wording in spec I looked around, and I don't think there is an existing test that actually tests this behavior. So, I think we should add one. I think you can probably extend the existing `test/jdk/java/security/Provider/ChangeProviders.java` regression test and add more tests that try to insert the provider at various positions outside of the normal range (ex: -1, 0, n +1, n + 10) , and then checks that the provider was inserted at the end of the list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14925#issuecomment-1678078457 From dlong at openjdk.org Mon Aug 14 21:23:10 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 21:23:10 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove negation in os_windows.cpp I had the same confusion, reading "-permissive-" the same as /permissive, but the trailing "-" means disable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1678081977 From mullan at openjdk.org Mon Aug 14 21:29:11 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Aug 2023 21:29:11 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 23:08:56 GMT, Alexey Bakhtin wrote: > JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS. > > This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior You will need to also file a CSR as you are adding a new system property and configuration option. I would also like to review this but may need a few days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1678091600 From prr at openjdk.org Mon Aug 14 21:29:18 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Aug 2023 21:29:18 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: <2PJWcAd4gIs8qK6NWqgLgYhEOmPS6iBvkQnhCCfp3pw=.2b11ffcb-17c8-45ad-b794-fbfd12f47fdb@github.com> On Mon, 14 Aug 2023 21:20:42 GMT, Dean Long wrote: > I had the same confusion, reading "-permissive-" the same as /permissive, but the trailing "-" means disable. Ah, my brain just saw that trailing - as somebody's idea of hyphenation. That's questionable syntax by the compiler IMO. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1678091565 From valeriep at openjdk.org Mon Aug 14 21:45:07 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 14 Aug 2023 21:45:07 GMT Subject: RFR: 8314148: Fix variable scope in SunMSCAPI [v2] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 20:15:59 GMT, Daniel Jeli?ski wrote: >> Please review this patch that fixes the scope of 2 local variables to make sure they are in scope when they are used. >> >> The patch additionally fixes one `c++11-narrowing` Clang warning by explicitly casting string size (`size_t`) to `DWORD`. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > fix verify method, reduce variable scope Looks good. Thanks! ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15242#pullrequestreview-1577695160 From valeriep at openjdk.org Mon Aug 14 23:07:08 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 14 Aug 2023 23:07:08 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v3] In-Reply-To: References: Message-ID: <_cjCzxasHWQIom7xaxsFtiQ3r3wZ6aKDJfzMQ9shcVQ=.9c829aaf-b569-45de-a419-2ca207b0b1da@github.com> On Fri, 11 Aug 2023 18:41:35 GMT, Ben Perez wrote: >> Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have left an `@implNote` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed wording in spec src/java.base/share/classes/java/security/Security.java line 300: > 298: * requested algorithms. The position is 1-based, that is, > 299: * 1 is most preferred, followed by 2, and so on. If the position > 300: * is less than 1 or greater than n, where n is the number of providers, nit: where n is the number of _installed_ providers ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1294045900 From valeriep at openjdk.org Mon Aug 14 23:16:06 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 14 Aug 2023 23:16:06 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v3] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 21:18:14 GMT, Sean Mullan wrote: > I looked around, and I don't think there is an existing test that actually tests this behavior. So, I think we should add one. I think you can probably extend the existing `test/jdk/java/security/Provider/ChangeProviders.java` regression test and add more tests that try to insert the provider at various positions outside of the normal range (ex: -1, 0, n +1, n + 10) , and then checks that the provider was inserted at the end of the list. Is a CSR needed? Now that we are enhancing existing javadoc for covering corner case scenarios? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14925#issuecomment-1678208809 From valeriep at openjdk.org Tue Aug 15 00:16:07 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 15 Aug 2023 00:16:07 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v2] In-Reply-To: References: <_8maAgdE11L5qGaV0B_unrWKFPQvIHKzsvseEKaES1U=.ca6f5887-e699-461d-bdc3-3b7dafbcb502@github.com> Message-ID: On Thu, 10 Aug 2023 20:05:21 GMT, Rajan Halade wrote: > > > > Ok, lets address this update in a separate bug after validating all platforms. Sounds good to me. Do you have any comment that I have yet address? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15217#issuecomment-1678255738 From valeriep at openjdk.org Tue Aug 15 01:08:11 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 15 Aug 2023 01:08:11 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v3] In-Reply-To: <41Uo_jj10HpKlqKPUvE55ePnE_9PaAHEj1i4Hi-Fl20=.869abb9c-6578-4857-99bd-355cdaa42e84@github.com> References: <41Uo_jj10HpKlqKPUvE55ePnE_9PaAHEj1i4Hi-Fl20=.869abb9c-6578-4857-99bd-355cdaa42e84@github.com> Message-ID: On Thu, 10 Aug 2023 19:36:28 GMT, Rajan Halade wrote: >> Do you mean throw SkippedException if no digest algorithms are actually tested with Clone functionality testing? Existing NSS impl seems to support clone for non-SHA-3 digest impls. > > Yes, test should throw SkippedException when nothing is tested. I re-factored the test to throw SkippedException when no digest algorithm supports clone functionality. >> This is just one digest algorithm. To mark the test skipped if none of the algorithms are supported will require different handling. > > Yes est should only throw `SkippedEXception` when all algos are skipped. Re-factored test to throw SkippedException if all algos are skipped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1294095810 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1294096304 From jwaters at openjdk.org Tue Aug 15 02:34:10 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 15 Aug 2023 02:34:10 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Mon, 14 Aug 2023 20:57:24 GMT, Phil Race wrote: > I have no time to look at the client changes for quite some time so do not push it. No matter how many other people approve it. And in the meantime you can (1) explain how many client tests you ran - and it had better be all of them :-) (2) add a comment in the PR to explain each client change you made - at the site of the change. Comments like "Fields in awt_TextComponent.cpp" are not an explanation (3) On the broader front, I note that you just start off with "We should set the -permissive- flag for the Microsoft Visual C compiler" without explaining WHY and what it does. In fact from what I've read about -it seems like we would not want it .. it downgrades errors to warnings .. and surely that's a bad thing ? No worries, I was not planning on committing without approval from each group, this was why I set the required reviewers to 5, 2 for HotSpot, one for build, and so on. I'll add the comments later on, but right now I can explain the changes directly since it's slightly easier to do so: The changes to awt involve enclosing several areas which make heavy use of goto in scopes to avoid them jumping over the initialization of locals, reordering the order of includes to avoid Microsoft specific headers from using our redefined malloc, moving the definition of C++ static fields outside of extern "C" blocks, and removing the class qualifiers from field declarations in several classes. The last one is fairly obvious - It isn't legal C++ grammar to do so. For the fields that were moved, they have C++ linkage initially by virtue of being static members of a class, but their definitions are inside extern "C" blocks, which causes their linkage to conflict between C++ and C. For the reordering of includes, see my conversation with Thomas - With permissive- enabled C++ templates are properly conforming, and the header comip.h (which is included by comdef.h) uses a templated malloc somewhere, which due to our #define malloc in alloc.h fails since the identifier is obviously not d efined. This is actually a major problem that is potentially causing an invisible bug in awt.dll somewhere, aside from it not compiling with permissive-, the redefining of malloc and all other allocators like this is something @tstuefe has expressed some concern over, but I don't really know how to deal with the bigger underlying problem outside of reordering the includes to not let comdef.h use our #define'd malloc. For the enclosing of gotos in scopes Thomas has suggested using RAII instead of labels in awt, which is something that could be done outside of this change, but I'm still figuring out if doing so for the sites that this is a problem for in this change would be neater Noted, I'll also improve the explaination on what permissive- does and why we want it in just a moment ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1678344486 From mbaesken at openjdk.org Tue Aug 15 07:43:23 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 15 Aug 2023 07:43:23 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Hi Phil, yes there are of course more call sites of dlopen in the JDK C codebase. I could cover them too, if this is wished. > . but I'm still not sure I understand .. why is what you are doing only wanted for the AIX cases ? The lib cache update ` LoadedLibraries::reload();` is AIX specific; the UL and JFR events are cross platform. ( Btw. in our proprietary JVM we have this approach for many years ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678538226 From alanb at openjdk.org Tue Aug 15 08:06:08 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Aug 2023 08:06:08 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com> References: <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com> Message-ID: On Wed, 12 Jul 2023 15:06:36 GMT, Glavo wrote: >> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. > > Glavo has updated the pull request incrementally with one additional commit since the last revision: > > Revert StreamTokenizer.java Now that the incompatible change to StreamTokenizer is dropped from this change then I assume the rest can be reviewed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1678560892 From duke at openjdk.org Tue Aug 15 10:48:29 2023 From: duke at openjdk.org (Glavo) Date: Tue, 15 Aug 2023 10:48:29 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v3] In-Reply-To: References: Message-ID: > Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge remote-tracking branch 'origin/master' into case-conversion-java-base - Revert StreamTokenizer.java - Update DateTimeFormatterBuilder - Avoid locale-sensitive case conversions in java.base ------------- Changes: https://git.openjdk.org/jdk/pull/14763/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14763&range=02 Stats: 44 lines in 11 files changed: 6 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/14763.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14763/head:pull/14763 PR: https://git.openjdk.org/jdk/pull/14763 From duke at openjdk.org Tue Aug 15 10:52:12 2023 From: duke at openjdk.org (Glavo) Date: Tue, 15 Aug 2023 10:52:12 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v3] In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 10:48:29 GMT, Glavo wrote: >> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. > > Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge remote-tracking branch 'origin/master' into case-conversion-java-base > - Revert StreamTokenizer.java > - Update DateTimeFormatterBuilder > - Avoid locale-sensitive case conversions in java.base I updated this PR to resolve the merge conflict. Now it is waiting to be reviewed again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1678743922 From mullan at openjdk.org Tue Aug 15 11:25:07 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 15 Aug 2023 11:25:07 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v3] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 23:13:25 GMT, Valerie Peng wrote: > Is a CSR needed? Now that we are enhancing existing javadoc for covering corner case scenarios? Yes, since the proposed wording will become part of the specification, a CSR is required. CSR has already been filed and approved: https://bugs.openjdk.org/browse/JDK-8314168 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14925#issuecomment-1678775782 From mdonovan at openjdk.org Tue Aug 15 13:52:08 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 15 Aug 2023 13:52:08 GMT Subject: RFR: 8293176: SSLEngine handshaker does not send an alert after a bad parameters [v2] In-Reply-To: References: Message-ID: <--zpP9ZK8P8AMlXEYVxMbS_yuJnNDnM12KFGVqr8PH4=.dbbd84cf-3645-4dfb-be91-68f7a5322284@github.com> On Fri, 11 Aug 2023 21:38:04 GMT, Daniel Jeli?ski wrote: >> Please review this patch that ensures that all exceptions thrown by SSLEngine delegated tasks are translated to alerts. >> >> All exceptions should already be translated to SSLExceptions and alerts by the time we exit from context.dispatch; these exceptions are rethrown by `conContext.fatal` without modification. With this patch the remaining exceptions are translated to `internal_error` alerts. >> >> SSLSocket implements similar handling in SSLSocketImpl#startHandshake. SSLSocket rethrows `SocketException`s without modification, and translates other `IOException`s to `handshake_failure` alerts. SSLEngine does not need to handle `SocketException`s, and IMO `internal_error` is a better choice here. >> >> Tier1-3 tests pass. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Fix exception handling > - Fix indentation LGTM ------------- Marked as reviewed by mdonovan (Committer). PR Review: https://git.openjdk.org/jdk/pull/15148#pullrequestreview-1578599664 From valeriep at openjdk.org Tue Aug 15 17:51:07 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 15 Aug 2023 17:51:07 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: <3u9CIk56rLnQp03uudIReS9Cj2A3G3L_gDvSb02ulno=.e1008689-937b-409a-ab96-a4d59e5b4c52@github.com> On Fri, 11 Aug 2023 11:53:49 GMT, Matthias Baesken wrote: > Looks okay to me and seems to fix the issues we faced in our test infrastructure; seems to need backport to jdk21. Would be great to have a second reviewer who is working more actively in this area of the JDK codebase. Thanks for the review, I will ping my peers and see if any of them can get to this... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1679354035 From valeriep at openjdk.org Tue Aug 15 18:03:07 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 15 Aug 2023 18:03:07 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote: > This change addresses the scenario where a certificate is first stored as part of a certificate chain and then stored again as a certificate corresponding to a PrivateKey entry. Newer version of NSS errors out with CKR_GENERAL_ERROR with the 2nd store, i.e. C_CreateObject() call. > > Proposed fix is to check for match before calling C_CreateObject(), if a match is found, set its alias instead. > > > > > > > > > Hmm, does the test fail with the changes in this PR or without? Are you also using NSS and which version? > > It fails with and w/o this patch, looks like related to the https://bugs.openjdk.org/browse/JDK-8232153 > > > > > > > > > Hmm, does the test fail with the changes in this PR or without? Are you also using NSS and which version? > > It fails with and w/o this patch, looks like related to the https://bugs.openjdk.org/browse/JDK-8232153 Yes, looks very likely to be related to that. I will check w/ Rajan also. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1679367989 From duke at openjdk.org Tue Aug 15 19:49:32 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 15 Aug 2023 19:49:32 GMT Subject: RFR: 8314240: test/jdk/sun/security/pkcs/pkcs7/SignerOrder.java fails to compile Message-ID: Included `null` as an argument to `pkcs71.verify` in SignerOrder.java ------------- Commit messages: - updated copyright - Fixed SignerOrder test and removed from ProblemList Changes: https://git.openjdk.org/jdk/pull/15296/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15296&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314240 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15296/head:pull/15296 PR: https://git.openjdk.org/jdk/pull/15296 From duke at openjdk.org Wed Aug 16 16:37:11 2023 From: duke at openjdk.org (Glavo) Date: Wed, 16 Aug 2023 16:37:11 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v3] In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 10:48:29 GMT, Glavo wrote: >> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. > > Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge remote-tracking branch 'origin/master' into case-conversion-java-base > - Revert StreamTokenizer.java > - Update DateTimeFormatterBuilder > - Avoid locale-sensitive case conversions in java.base Can someone review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1680928752 From naoto at openjdk.org Wed Aug 16 17:20:11 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 16 Aug 2023 17:20:11 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v3] In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 10:48:29 GMT, Glavo wrote: >> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. > > Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge remote-tracking branch 'origin/master' into case-conversion-java-base > - Revert StreamTokenizer.java > - Update DateTimeFormatterBuilder > - Avoid locale-sensitive case conversions in java.base LGTM. Thanks for the changes. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14763#pullrequestreview-1581093609 From duke at openjdk.org Wed Aug 16 17:40:15 2023 From: duke at openjdk.org (Glavo) Date: Wed, 16 Aug 2023 17:40:15 GMT Subject: Integrated: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 20:53:34 GMT, Glavo wrote: > Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. This pull request has now been integrated. Changeset: b32d6411 Author: Glavo Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/b32d6411c406608ba5f7d60bfb8d935adb876564 Stats: 44 lines in 11 files changed: 6 ins; 0 del; 38 mod 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/14763 From mullan at openjdk.org Wed Aug 16 19:17:09 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 16 Aug 2023 19:17:09 GMT Subject: RFR: 8314240: test/jdk/sun/security/pkcs/pkcs7/SignerOrder.java fails to compile In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 19:42:44 GMT, Ben Perez wrote: > Included `null` as an argument to `pkcs71.verify` in SignerOrder.java Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15296#pullrequestreview-1581265860 From serb at openjdk.org Wed Aug 16 19:25:12 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 16 Aug 2023 19:25:12 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove negation in os_windows.cpp Why initial patch was reverter using this comment: "unfortunately, did not prove to be as useful as expected"? What was the problem? What about the "pedantic" option which was added last time? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1681152431 From duke at openjdk.org Wed Aug 16 19:59:15 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 16 Aug 2023 19:59:15 GMT Subject: Integrated: 8314240: test/jdk/sun/security/pkcs/pkcs7/SignerOrder.java fails to compile In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 19:42:44 GMT, Ben Perez wrote: > Included `null` as an argument to `pkcs71.verify` in SignerOrder.java This pull request has now been integrated. Changeset: f143380d Author: Ben Perez Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/f143380d013b8c0e5ab7ca0026c34e27e7946f69 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod 8314240: test/jdk/sun/security/pkcs/pkcs7/SignerOrder.java fails to compile Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/15296 From jwaters at openjdk.org Thu Aug 17 04:34:34 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 04:34:34 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Wed, 16 Aug 2023 19:22:01 GMT, Sergey Bylokhov wrote: > Why initial patch was reverter using this comment: "unfortunately, did not prove to be as useful as expected"? What was the problem? What about the "pedantic" option which was added last time? Hi, the problem was that gcc and clang are by default extremely strict with regards to conforming to C++, and the -pedantic flag simply made them so strict that it was impossible to compile the JDK with them. In an ideal world we'd be able to compile with -pedantic enabled, but that seems to be a lot of work required before that can be achieved, so it was reverted. In contrast, Visual C compiler is much too lax with what it allows you to get away with by default, so the permissive- flag is needed to make it match clang and gcc's default strictness. Additionally, permissive- is going to become the default on Visual C in the future, so we should add this as a flag to allow the JDK to be prepared when that time arrives ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1681596804 From jwaters at openjdk.org Thu Aug 17 08:38:01 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 08:38:01 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Document changes in awt_DnDDS.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/4e3329b8..2f8997e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Thu Aug 17 08:40:33 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 08:40:33 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Document changes in awt_DnDDS.cpp Adding extra reviewer for jdk.accessibility ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1681871378 From duke at openjdk.org Thu Aug 17 18:33:09 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 17 Aug 2023 18:33:09 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v4] In-Reply-To: References: Message-ID: > Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Changed function spec wording, updated test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14925/files - new: https://git.openjdk.org/jdk/pull/14925/files/77655b5a..80b37367 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=02-03 Stats: 20 lines in 2 files changed: 16 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14925/head:pull/14925 PR: https://git.openjdk.org/jdk/pull/14925 From mullan at openjdk.org Thu Aug 17 21:41:30 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 17 Aug 2023 21:41:30 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v4] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 18:33:09 GMT, Ben Perez wrote: >> Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed function spec wording, updated test Changes requested by mullan (Reviewer). src/java.base/share/classes/java/security/Security.java line 302: > 300: * is less than 1 or greater than n, where n is the number of installed > 301: * providers, the provider (if not already installed) is inserted at > 302: * the end ofthe list, or at the n + 1 position. Missing space between "of" and "the". test/jdk/java/security/Provider/ChangeProviders.java line 1: > 1: /* Add bugid to the `@bug` line. test/jdk/java/security/Provider/ChangeProviders.java line 85: > 83: > 84: //Ensure that providers inserted at position 0 or > n are placed > 85: //at the n+1st position Nit: typically there is a space after `//`. test/jdk/java/security/Provider/ChangeProviders.java line 90: > 88: } > 89: Provider r = new NextProvider(); > 90: Security.insertProviderAt(r,0); Nit: add space after `,`. test/jdk/java/security/Provider/ChangeProviders.java line 91: > 89: Provider r = new NextProvider(); > 90: Security.insertProviderAt(r,0); > 91: if (plen() != n+2 || Security.getProviders()[n+1] != r) { Nit: add space before/after `+`. ------------- PR Review: https://git.openjdk.org/jdk/pull/14925#pullrequestreview-1583524000 PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1297771334 PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1297771869 PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1297772324 PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1297772916 PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1297773312 From mullan at openjdk.org Thu Aug 17 21:48:29 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 17 Aug 2023 21:48:29 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v4] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 18:33:09 GMT, Ben Perez wrote: >> Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed function spec wording, updated test test/jdk/java/security/Provider/ChangeProviders.java line 85: > 83: > 84: //Ensure that providers inserted at position 0 or > n are placed > 85: //at the n+1st position It's probably clearer to reset n after this and then test for n+1 instead of n+2, ex - add a line: // reset n to number of installed providers n = plen(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1297781990 From valeriep at openjdk.org Fri Aug 18 01:52:27 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 18 Aug 2023 01:52:27 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v4] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 18:33:09 GMT, Ben Perez wrote: >> Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Changed function spec wording, updated test test/jdk/java/security/Provider/ChangeProviders.java line 84: > 82: } > 83: > 84: //Ensure that providers inserted at position 0 or > n are placed nit: this sentence is a bit hard to parse, maybe it's easier to just state that positions out of the [1...n] range is placed at the position n+1? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1297904164 From valeriep at openjdk.org Fri Aug 18 01:59:28 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 18 Aug 2023 01:59:28 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v4] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 01:49:20 GMT, Valerie Peng wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed function spec wording, updated test > > test/jdk/java/security/Provider/ChangeProviders.java line 84: > >> 82: } >> 83: >> 84: //Ensure that providers inserted at position 0 or > n are placed > > nit: this sentence is a bit hard to parse, maybe it's easier to just state that positions out of the [1...n] range is placed at the position n+1? Actually, you don't need another provider impl, you could have just removed Foo and then proceed with the Foo provider with your insertProviderAt(...) testing. With the current test, when you start testing, the provider count is n+1, which can be confusing mixed with your comment of using n as the current provider count... Thus, I'd suggest you just remove the Foo provider and re-use it. This way, there is less code and all is consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1297907238 From duke at openjdk.org Fri Aug 18 14:27:55 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 18 Aug 2023 14:27:55 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v5] In-Reply-To: References: Message-ID: > Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Simplified test in ChangeProviders ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14925/files - new: https://git.openjdk.org/jdk/pull/14925/files/80b37367..71bb6a6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=03-04 Stats: 12 lines in 2 files changed: 0 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14925/head:pull/14925 PR: https://git.openjdk.org/jdk/pull/14925 From valeriep at openjdk.org Fri Aug 18 18:46:27 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 18 Aug 2023 18:46:27 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v4] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 21:30:17 GMT, Sean Mullan wrote: >> Ben Perez has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed function spec wording, updated test > > test/jdk/java/security/Provider/ChangeProviders.java line 1: > >> 1: /* > > Add bugid to the `@bug` line. +1, append 8175874 to line 26. Have no further comments, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14925#discussion_r1298757879 From jwaters at openjdk.org Sat Aug 19 06:56:43 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 19 Aug 2023 06:56:43 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Document changes in awt_DnDDS.cpp Bumping, anyone from security? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1684866389 From jwaters at openjdk.org Mon Aug 21 08:16:32 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 21 Aug 2023 08:16:32 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <4HxoycfhUj3rvj-IBGIIkfQFqgJ0i15UiwmVX5MbVo0=.94d41007-b52d-41c3-bd76-8f6ea6a30321@github.com> On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Document changes in awt_DnDDS.cpp Bumping ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1685862875 From albertattard at gmail.com Mon Aug 21 12:43:00 2023 From: albertattard at gmail.com (Albert Attard) Date: Mon, 21 Aug 2023 14:43:00 +0200 Subject: Possible typos in JEP 339 Message-ID: Hello. I believe there are two small typos in the JEP 339 page ( https://openjdk.org/jeps/339). // example: use KeyFactory to contruct a public key KeyFactory kf = KeyFactory.getInstance("EdDSA"); boolean xOdd = ... BigInteger y = ... NamedParameterSpec paramSpec = new NamedParameterSpec("Ed25519"); EdECPublicKeySpec pubSpec = new EdECPublicKeySpec(paramSpec, new EdPoint(xOdd, y)); PublicKey pubKey = kf.generatePublic(pubSpec); - In the commend, I believe "*contruct*" should be "*construct*", and - Should the class name EdPoint be EdECPoint? Thank you With kind regards, Albert Attard -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Aug 21 14:08:30 2023 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Aug 2023 10:08:30 -0400 Subject: Possible typos in JEP 339 In-Reply-To: References: Message-ID: On 8/21/23 8:43 AM, Albert Attard wrote: > Hello. > > I believe there are two small typos in the JEP 339 page > (https://openjdk.org/jeps/339 ). > > // example: use KeyFactory to contruct a public key > KeyFactory kf = KeyFactory.getInstance("EdDSA"); > boolean xOdd = ... > BigInteger y = ... > NamedParameterSpec paramSpec = new NamedParameterSpec("Ed25519"); > EdECPublicKeySpec pubSpec = new EdECPublicKeySpec(paramSpec, new > EdPoint(xOdd, y)); > PublicKey pubKey = kf.generatePublic(pubSpec); > > * In the commend, I believe "/contruct/" should be "/construct/", and > * Should the class name EdPoint be EdECPoint? Yes, good catches! I'll make sure we fix this. --Sean From duke at openjdk.org Mon Aug 21 16:23:18 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 21 Aug 2023 16:23:18 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v6] In-Reply-To: References: Message-ID: <5MfNoyyRyLXMicRqWX9zCWRjIuOX7p0SaVQPcAndrzQ=.59e74716-e64c-442c-86a7-96e48e7cd512@github.com> > Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. Ben Perez 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 JDK-8175874 - Simplified test in ChangeProviders - Changed function spec wording, updated test - Changed wording in spec - Removed implnote and added to function specification instead - removed unnecessary newlines - added impl note to insertProviderAt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14925/files - new: https://git.openjdk.org/jdk/pull/14925/files/71bb6a6a..1addeebf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=04-05 Stats: 86076 lines in 2329 files changed: 46676 ins; 26440 del; 12960 mod Patch: https://git.openjdk.org/jdk/pull/14925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14925/head:pull/14925 PR: https://git.openjdk.org/jdk/pull/14925 From alanb at openjdk.org Tue Aug 22 07:34:28 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Aug 2023 07:34:28 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 20:09:39 GMT, Alan Bateman wrote: > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687630491 From alanb at openjdk.org Tue Aug 22 07:41:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Aug 2023 07:41:32 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 18:53:12 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 incrementally with one additional commit since the last revision: > > less exception filtering when fetching socket read timeout Overall, it's good to move away from the "faraway instrumentation". Looks forward to the next steps to get to a more complete solution. src/java.base/share/classes/java/net/Socket.java line 44: > 42: import java.util.Collections; > 43: > 44: Minor nit, I assume this additional blank line is left over from a previous iteration. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 465: > 463: public long read(ByteBuffer[] dsts, int offset, int length) > 464: throws IOException > 465: { The supporting methods for read (beginRead, endRead, throwConnectionReset, ...) are declared before the read methods. It's probably best to put the implRead before the read too so that all the supporting methods are together. Same thing with the write methods. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1588627786 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301134829 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301144638 From alanb at openjdk.org Tue Aug 22 07:41:34 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Aug 2023 07:41:34 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: > 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. Good, I think the exception cases are probably the most interesting for this area when it comes to troubleshooting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687636801 From alanb at openjdk.org Tue Aug 22 07:41:38 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Aug 2023 07:41:38 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3] In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 06:09:14 GMT, Alan Bateman wrote: >> 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. Were you able to find out what the timeout is used for? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301136108 From alanb at openjdk.org Tue Aug 22 07:41:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Aug 2023 07:41:40 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com> Message-ID: On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing wrote: >> 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 Thanks, it's a reminder that the existing SocketXXX events are incomplete and/or not much I/O done with the socket adaptors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301143720 From egahlin at openjdk.org Tue Aug 22 08:49:32 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 22 Aug 2023 08:49:32 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 18:53:12 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 incrementally with one additional commit since the last revision: > > less exception filtering when fetching socket read timeout The stack trace will start in the incorrect method, i.e checkForCommit, when a utility method is used. This is probably something we will have to fix anyway. I filed an issue for that: https://bugs.openjdk.org/browse/JDK-8314745 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687749717 From alanb at openjdk.org Tue Aug 22 08:59:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Aug 2023 08:59:33 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 18:53:12 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 incrementally with one additional commit since the last revision: > > less exception filtering when fetching socket read timeout One other thing is that the comments in Socket.SocketInputStream and Socket.SocketOutputStream where it has "This class is instrumented by Java Flight Recorder (JFR) to get socket I/O events" can be removed now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687765868 From duke at openjdk.org Tue Aug 22 17:24:24 2023 From: duke at openjdk.org (Swati Sharma) Date: Tue, 22 Aug 2023 17:24:24 GMT Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests having shared state In-Reply-To: References: Message-ID: <5K5iYGm0ryQwxnOj-e0NlMsCPYMpzZtAiVXYubl7pLM=.65ae1221-e573-4666-911a-ef4e3a271927@github.com> On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma wrote: > In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems. > > org/openjdk/bench/java/io/DataInputStreamTest.java > org/openjdk/bench/java/lang/ArrayClone.java > org/openjdk/bench/java/lang/StringCompareToDifferentLength.java > org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java > org/openjdk/bench/java/lang/StringComparisons.java > org/openjdk/bench/java/lang/StringEquals.java > org/openjdk/bench/java/lang/StringFormat.java > org/openjdk/bench/java/lang/StringReplace.java > org/openjdk/bench/java/lang/StringSubstring.java > org/openjdk/bench/java/lang/StringTemplateFMT.java > org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java > org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java > org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java > org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java > org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java > org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java > org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java > org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java > org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java > org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java > org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java > org/openjdk/bench/java/security/CipherSuiteBench.java > org/openjdk/bench/java/time/GetYearBench.java > org/openjdk/bench/java/time/InstantBench.java > org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java > org/openjdk/bench/java/util/ListArgs.java > org/openjdk/bench/java/util/LocaleDefaults.java > org/openjdk/bench/java/util/TestAdler32.java > org/openjdk/bench/java/util/TestCRC32.java > org/openjdk/bench/java/util/TestCRC32C.java > org/openjdk/bench/java/util/regex/Exponential.java > org/openjdk/bench/java/util/regex/Primality.java > org/openjdk/bench/java/util/regex/Trim.java > org/openjdk/bench/javax/crypto/AESReinit.java > org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java > org/openjdk/bench/vm/compiler/Rotation.java > org/openjdk/bench/vm/compiler/x86/ConvertF2I.java > org/openjdk/bench/vm/compiler/x86/BasicRules.java > > Please review and provide your feedback. > > Thanks, > Swati Could you please review this ? @ericcaspole ------------- PR Comment: https://git.openjdk.org/jdk/pull/15230#issuecomment-1688597226 From jnimeh at openjdk.org Tue Aug 22 17:25:17 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 22 Aug 2023 17:25:17 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote: > This change addresses the scenario where a certificate is first stored as part of a certificate chain and then stored again as a certificate corresponding to a PrivateKey entry. Newer version of NSS errors out with CKR_GENERAL_ERROR with the 2nd store, i.e. C_CreateObject() call. > > Proposed fix is to check for match before calling C_CreateObject(), if a match is found, set its alias instead. This looks good. Does the bug need a noreg label since this is addressing an existing test failure? ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15146#pullrequestreview-1589954528 From valeriep at openjdk.org Tue Aug 22 18:29:47 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 22 Aug 2023 18:29:47 GMT Subject: RFR: 8312306: Add more Reference.reachabilityFence() calls to the security classes using Cleaner Message-ID: This PR updates the various security classes using Cleaner with the try/finally pattern. Also noticed that SunJCE's PBEKey impl class overrides the destroy() method but not the isDestroyed() method, fixed this inconsistency as well. Thanks in advance for the review! ------------- Commit messages: - minor comments update - 8312306: Add more Reference.reachabilityFence() calls to the security classes using Cleaner Changes: https://git.openjdk.org/jdk/pull/15390/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15390&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312306 Stats: 238 lines in 6 files changed: 149 ins; 4 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/15390.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15390/head:pull/15390 PR: https://git.openjdk.org/jdk/pull/15390 From valeriep at openjdk.org Tue Aug 22 23:57:47 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 22 Aug 2023 23:57:47 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 17:14:27 GMT, Jamil Nimeh wrote: > This looks good. Does the bug need a noreg label since this is addressing an existing test failure? There is a test update with this bug id and no need to add noreg label. Rajan confirmed this as well. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1689063030 From valeriep at openjdk.org Tue Aug 22 23:58:17 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 22 Aug 2023 23:58:17 GMT Subject: RFR: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote: > This change addresses the scenario where a certificate is first stored as part of a certificate chain and then stored again as a certificate corresponding to a PrivateKey entry. Newer version of NSS errors out with CKR_GENERAL_ERROR with the 2nd store, i.e. C_CreateObject() call. > > Proposed fix is to check for match before calling C_CreateObject(), if a match is found, set its alias instead. Thanks for the review~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/15146#issuecomment-1689063238 From valeriep at openjdk.org Wed Aug 23 00:15:47 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 23 Aug 2023 00:15:47 GMT Subject: Integrated: 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote: > This change addresses the scenario where a certificate is first stored as part of a certificate chain and then stored again as a certificate corresponding to a PrivateKey entry. Newer version of NSS errors out with CKR_GENERAL_ERROR with the 2nd store, i.e. C_CreateObject() call. > > Proposed fix is to check for match before calling C_CreateObject(), if a match is found, set its alias instead. This pull request has now been integrated. Changeset: ba6cdbe2 Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/ba6cdbe2c2897a0fdc266119f0fe4545c3352b8e Stats: 53 lines in 2 files changed: 39 ins; 12 del; 2 mod 8309214: sun/security/pkcs11/KeyStore/CertChainRemoval.java fails after 8301154 Reviewed-by: mbaesken, jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/15146 From mdoerr at openjdk.org Wed Aug 23 12:29:20 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 23 Aug 2023 12:29:20 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Please check windows-aarch64 build error: unresolved external symbol dlopen_ext ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1689871700 From mbaesken at openjdk.org Wed Aug 23 15:18:03 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 23 Aug 2023 15:18:03 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2] In-Reply-To: References: Message-ID: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: windows aarch64 build issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15264/files - new: https://git.openjdk.org/jdk/pull/15264/files/94e25ad7..9ceec5e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=00-01 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264 PR: https://git.openjdk.org/jdk/pull/15264 From duke at openjdk.org Wed Aug 23 15:57:51 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 23 Aug 2023 15:57:51 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v7] In-Reply-To: References: Message-ID: > Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Added bugid to ChangeProviders ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14925/files - new: https://git.openjdk.org/jdk/pull/14925/files/1addeebf..1d64bf9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14925&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14925/head:pull/14925 PR: https://git.openjdk.org/jdk/pull/14925 From mullan at openjdk.org Wed Aug 23 16:25:23 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 23 Aug 2023 16:25:23 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v7] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 15:57:51 GMT, Ben Perez wrote: >> Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added bugid to ChangeProviders Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14925#pullrequestreview-1591980412 From valeriep at openjdk.org Wed Aug 23 17:08:22 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 23 Aug 2023 17:08:22 GMT Subject: RFR: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. [v7] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 15:57:51 GMT, Ben Perez wrote: >> Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Added bugid to ChangeProviders Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14925#pullrequestreview-1592052169 From duke at openjdk.org Wed Aug 23 18:13:32 2023 From: duke at openjdk.org (Ben Perez) Date: Wed, 23 Aug 2023 18:13:32 GMT Subject: Integrated: 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 19:59:34 GMT, Ben Perez wrote: > Fixing the bug as stated would cause compatibility issues. E.g. the `addProvider` function always adds new providers at position 0 and therefore would always throw an error. Instead of changing how the function handles indices, we instead have added this behavior to the function spec. This pull request has now been integrated. Changeset: 9435cd19 Author: Ben Perez Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/9435cd19165c9ffc3f19fd423f3706b1e37212d8 Stats: 19 lines in 2 files changed: 16 ins; 0 del; 3 mod 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range. Reviewed-by: mullan, valeriep ------------- PR: https://git.openjdk.org/jdk/pull/14925 From andrew at openjdk.org Thu Aug 24 00:59:48 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 24 Aug 2023 00:59:48 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so Message-ID: There is a long standing limitation in the UNIX smartcardio implementation which means it will only look for the `pcsclite` library in two locations; `/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned library. On systems that separate libraries from development headers in separate subpackages, the unversioned library is only installed by the `-devel` package, which rarely happens unless the user wants to write their own application using the libpcsclite headers or build someone else's code themselves. An example of this is the [pcsc-lite-libs package on Fedora](https://koji.fedoraproject.org/koji/rpminfo?rpmID=35258843) On Debian-based systems, there is also the issue that libraries are now placed inside a subdirectory using a [tuple](https://wiki.debian.org/Multiarch/Tuples) consisting of the instruction set, syscall ABI and libc e.g. `x86_64-linux-gnu`. So it will not only fail to find the library when only the versioned library is installed (e.g. [libpcsclite1](https://packages.ubuntu.com/kinetic/amd64/libpcsclite1/filelist)) but also when the dev package is also installed (e.g. [libpcsclite-dev](https://packages.ubuntu.com/kinetic/amd64/libpcsclite-dev/filelist)), because the file is in e.g. `/usr/lib/x86_64-linux-gnu/libpcsclite.so` This patch makes both cases work. It prefers versioned libraries, as potentially a `libpcsclite.so.2` could become available with a different ABI that the JDK can not work with. All cases that worked before with just `libpcsclite.so` will still work, but it should also now pick up the library on many additional systems. A much simpler patch (search for the versioned symlink instead of unversioned) has been [in the Fedora and RHEL packages for nearly a decade](https://bugzilla.redhat.com/show_bug.cgi?id=910107), and an earlier version of this patch with Debian support has been used in IcedTea builds since 2015. It would be nice to finally fix this upstream. Testing: Test case: ~~~ import java.lang.reflect.Method; public class TestPlatformPCSC { public static void main(String[] args) throws Exception { Class cls = Class.forName("sun.security.smartcardio.PlatformPCSC"); Method m = cls.getDeclaredMethod("getLibraryName"); m.setAccessible(true); System.err.println(m.invoke(null)); } } ~~~ 1. With `libpcsclite.so.1` available: ~~~ $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.debug=pcsc TestPlatformPCSC pcsc: Looking for /usr/lib64/libpcsclite.so.1 pcsc: Using PC/SC library: /usr/lib64/libpcsclite.so.1 pcsc: Looking for /usr/lib64/libpcsclite.so.1 /usr/lib64/libpcsclite.so.1 ~~~ 2. With just `libpcsclite.so` available: ~~~ $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.debug=pcsc TestPlatformPCSC pcsc: Looking for /usr/lib64/libpcsclite.so.1 pcsc: Looking for /usr/lib64/libpcsclite.so.0 pcsc: Looking for /usr/lib64/libpcsclite.so pcsc: Using PC/SC library: /usr/lib64/libpcsclite.so ~~~ 4. With `libpcsclite.so.1` in the Debian-style structure: ~~~ $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.debug=pcsc TestPlatformPCSC pcsc: Looking for /usr/lib64/libpcsclite.so.1 pcsc: Looking for /usr/lib64/libpcsclite.so.0 pcsc: Looking for /usr/lib64/libpcsclite.so pcsc: Looking for /usr/local/lib64/libpcsclite.so.1 pcsc: Looking for /usr/local/lib64/libpcsclite.so.0 pcsc: Looking for /usr/local/lib64/libpcsclite.so pcsc: Looking for /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 pcsc: Using PC/SC library: /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 ~~~ 5. Without the library installed ~~~ $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.debug=pcsc TestPlatformPCSC pcsc: Looking for /usr/lib64/libpcsclite.so.1 pcsc: Looking for /usr/lib64/libpcsclite.so.0 pcsc: Looking for /usr/lib64/libpcsclite.so pcsc: Looking for /usr/local/lib64/libpcsclite.so.1 pcsc: Looking for /usr/local/lib64/libpcsclite.so.0 pcsc: Looking for /usr/local/lib64/libpcsclite.so pcsc: Looking for /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 pcsc: Looking for /usr/lib/x86_64-linux-gnu/libpcsclite.so.0 pcsc: Looking for /usr/lib/x86_64-linux-gnu/libpcsclite.so pcsc: Looking for /usr/lib/arm-linux-gnueabi/libpcsclite.so.1 pcsc: Looking for /usr/lib/arm-linux-gnueabi/libpcsclite.so.0 pcsc: Looking for /usr/lib/arm-linux-gnueabi/libpcsclite.so pcsc: Looking for /usr/lib/arm-linux-gnueabihf/libpcsclite.so.1 pcsc: Looking for /usr/lib/arm-linux-gnueabihf/libpcsclite.so.0 pcsc: Looking for /usr/lib/arm-linux-gnueabihf/libpcsclite.so pcsc: Looking for /usr/lib/x86_64-kfreebsd-gnu/libpcsclite.so.1 pcsc: Looking for /usr/lib/x86_64-kfreebsd-gnu/libpcsclite.so.0 pcsc: Looking for /usr/lib/x86_64-kfreebsd-gnu/libpcsclite.so pcsc: Looking for /usr/lib64/libpcsclite.so.1 pcsc: Looking for /usr/lib64/libpcsclite.so.0 pcsc: Looking for /usr/lib64/libpcsclite.so pcsc: Looking for /usr/local/lib64/libpcsclite.so.1 pcsc: Looking for /usr/local/lib64/libpcsclite.so.0 pcsc: Looking for /usr/local/lib64/libpcsclite.so pcsc: Looking for /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 pcsc: Looking for /usr/lib/x86_64-linux-gnu/libpcsclite.so.0 pcsc: Looking for /usr/lib/x86_64-linux-gnu/libpcsclite.so pcsc: Looking for /usr/lib/arm-linux-gnueabi/libpcsclite.so.1 pcsc: Looking for /usr/lib/arm-linux-gnueabi/libpcsclite.so.0 pcsc: Looking for /usr/lib/arm-linux-gnueabi/libpcsclite.so pcsc: Looking for /usr/lib/arm-linux-gnueabihf/libpcsclite.so.1 pcsc: Looking for /usr/lib/arm-linux-gnueabihf/libpcsclite.so.0 pcsc: Looking for /usr/lib/arm-linux-gnueabihf/libpcsclite.so pcsc: Looking for /usr/lib/x86_64-kfreebsd-gnu/libpcsclite.so.1 pcsc: Looking for /usr/lib/x86_64-kfreebsd-gnu/libpcsclite.so.0 pcsc: Looking for /usr/lib/x86_64-kfreebsd-gnu/libpcsclite.so Exception in thread "main" java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at TestPlatformPCSC.main(TestPlatformPCSC.java:9) Caused by: java.io.IOException: No PC/SC library found on this system ~~~ ------------- Commit messages: - 8009550: PlatformPCSC should load versioned so Changes: https://git.openjdk.org/jdk/pull/15409/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15409&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8009550 Stats: 53 lines in 2 files changed: 29 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/15409.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15409/head:pull/15409 PR: https://git.openjdk.org/jdk/pull/15409 From mbalao at openjdk.org Thu Aug 24 01:30:36 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 24 Aug 2023 01:30:36 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory [v2] In-Reply-To: References: Message-ID: 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. As commented here [1], @franferrax and I have been working on a different approach to this problem. We suggest to put this PR on hold until we have our proposal ready to compare and discuss further. -- [1] - https://bugs.openjdk.org/browse/JDK-8309331?focusedCommentId=14606264&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14606264 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14277#issuecomment-1690851967 From mbaesken at openjdk.org Thu Aug 24 07:29:25 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 24 Aug 2023 07:29:25 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: <3Z3DhL13S8nSO7g4EaiOmCxTAZERbtP-GlDzlHW-d34=.3a8a9c47-b3e6-4b7c-afac-567ab81f47c8@github.com> On Wed, 23 Aug 2023 12:26:36 GMT, Martin Doerr wrote: > Please check windows-aarch64 build error: unresolved external symbol dlopen_ext Hi Martin, thanks ! I did a small adjustment, now the windows aarch64 build works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1691148432 From svkamath at openjdk.org Thu Aug 24 18:10:54 2023 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 24 Aug 2023 18:10:54 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions Message-ID: Hi All, I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup |-------------|------------|---------------|------------------|-----------| |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 ? | ? | ? | ? | ? full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 ? | ? | ? | ? | ? full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 ? | ? | ? | ? | ? full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 full.AESGCMBench.decryptMultiPart | 65536 | 42649.816 | 47591.587 |1.11 full.AESGCMBench.encryptMultiPart | 65536 | 86025.621 | 112305.674 | 1.30 small.AESGCMBench.decryptMultiPart | 65536 | 42542.426 | 47899.088 | 1.12 small.AESGCMBench.encryptMultiPart | 65536 | 85522.057 | 111759.309 |1.30 ? | ? | ? | ? | ? full.AESGCMBench.decrypt | 1048576 | 5490.691 | 7335.672 | 1.33 full.AESGCMBench.encrypt | 1048576 | 5611.847 | 7338.246 | 1.30 small.AESGCMBench.decrypt | 1048576 | 5506.263 | 7247.359 | 1.31 small.AESGCMBench.encrypt | 1048576 | 5612.709 | 7331.576 | 1.30 full.AESGCMBench.decryptMultiPart | 1048576 | 2992.516 | 3405.349 | 1.13 full.AESGCMBench.encryptMultiPart | 1048576 | 5585.353 | 7341.056 | 1.31 small.AESGCMBench.decryptMultiPart | 1048576 | 2971.281 | 3390.593 | 1.14 small.AESGCMBench.encryptMultiPart | 1048576 | 5596.038 | 7322.126 | 1.30 Kindly review and provide feedback. Thanks, Smita ------------- Commit messages: - JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions Changes: https://git.openjdk.org/jdk/pull/15410/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15410&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314901 Stats: 1154 lines in 13 files changed: 1133 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/15410.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15410/head:pull/15410 PR: https://git.openjdk.org/jdk/pull/15410 From rhalade at openjdk.org Thu Aug 24 20:05:14 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 24 Aug 2023 20:05:14 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v3] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 20:29:29 GMT, Valerie Peng wrote: >> Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. >> >> This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. >> >> The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). >> >> Thanks in advance for review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > More review feedbacks Changes requested by rhalade (Reviewer). test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 117: > 115: System.out.println("=> Skip; no PSS support"); > 116: return; > 117: } else...Should the test be marked as failed? test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 117: > 115: System.out.println(" => Skip; no PSS support"); > 116: return; > 117: } Same here, should test fail here? ------------- PR Review: https://git.openjdk.org/jdk/pull/15217#pullrequestreview-1592168686 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1303387953 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1303393216 From rhalade at openjdk.org Thu Aug 24 20:05:16 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 24 Aug 2023 20:05:16 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v3] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 19:45:48 GMT, Valerie Peng wrote: >> test/jdk/sun/security/pkcs11/PSSUtil.java line 34: >> >>> 32: private static final String KEYALG = "RSA"; >>> 33: private static final String SIGALG = "RSASSA-PSS"; >>> 34: private static final String[] DIGESTS = { >> >> is this constant used anywhere or supposed to be used? > > Removed. DIGESTS is still not used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1304809707 From abakhtin at openjdk.org Thu Aug 24 21:24:51 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Thu, 24 Aug 2023 21:24:51 GMT Subject: RFR: 8311532: Option to disable Krb5LoginModule::login method [v2] In-Reply-To: References: Message-ID: <_NuXb0JAz7W1LzTmNQqxrBr8luIeIk1NdXwikbi4254=.3fad487f-41ab-4862-9075-0418893fc100@github.com> > JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS. > > This patch represents the configuration option ( `?doNotLogin?` ) to allow skipping the login, with a system property (`?sun.security.auth.skipLogin?`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Rename system property ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15254/files - new: https://git.openjdk.org/jdk/pull/15254/files/7bf8ec45..efc7d7f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15254&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15254&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15254/head:pull/15254 PR: https://git.openjdk.org/jdk/pull/15254 From valeriep at openjdk.org Fri Aug 25 00:42:21 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 25 Aug 2023 00:42:21 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 00:53:03 GMT, Andrew John Hughes wrote: > There is a long standing limitation in the UNIX smartcardio implementation which means it will only look for the `pcsclite` library in two locations; `/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned library. > > On systems that separate libraries from development headers in separate subpackages, the unversioned library is only installed by the `-devel` package, which rarely happens unless the user wants to write their own application using the libpcsclite headers or build someone else's code themselves. An example of this is the [pcsc-lite-libs package on Fedora](https://koji.fedoraproject.org/koji/rpminfo?rpmID=35258843) > > On Debian-based systems, there is also the issue that libraries are now placed inside a subdirectory using a [tuple](https://wiki.debian.org/Multiarch/Tuples) consisting of the instruction set, syscall ABI and libc e.g. `x86_64-linux-gnu`. So it will not only fail to find the library when only the versioned library is installed (e.g. [libpcsclite1](https://packages.ubuntu.com/kinetic/amd64/libpcsclite1/filelist)) but also when the dev package is also installed (e.g. [libpcsclite-dev](https://packages.ubuntu.com/kinetic/amd64/libpcsclite-dev/filelist)), because the file is in e.g. `/usr/lib/x86_64-linux-gnu/libpcsclite.so` > > This patch makes both cases work. It prefers versioned libraries, as potentially a `libpcsclite.so.2` could become available with a different ABI that the JDK can not work with. All cases that worked before with just `libpcsclite.so` will still work, but it should also now pick up the library on many additional systems. > > A much simpler patch (search for the versioned symlink instead of unversioned) has been [in the Fedora and RHEL packages for nearly a decade](https://bugzilla.redhat.com/show_bug.cgi?id=910107), and an earlier version of this patch with Debian support has been used in IcedTea builds since 2015. It would be nice to finally fix this upstream. > > Testing: > > Test case: > ~~~ > import java.lang.reflect.Method; > > public class TestPlatformPCSC { > public static void main(String[] args) > throws Exception { > Class cls = Class.forName("sun.security.smartcardio.PlatformPCSC"); > Method m = cls.getDeclaredMethod("getLibraryName"); > m.setAccessible(true); > System.err.println(m.invoke(null)); > } > } > ~~~ > > 1. With `libpcsclite.so.1` available: > ~~~ > $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.d... Changes look fine. I submitted a mach5 test job just in case. Will approve once the test job passes. BTW, I added a noreg-other label since there is no regression test for this change. ------------- PR Review: https://git.openjdk.org/jdk/pull/15409#pullrequestreview-1594643504 From rhalade at openjdk.org Fri Aug 25 00:47:34 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 25 Aug 2023 00:47:34 GMT Subject: RFR: 8314960: Add Certigna Root CA - 2 Message-ID: This PR is to add two new TLS root certificates from Certigna (Dhimyotis). This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process. The release-note is at [JDK-8314976](https://bugs.openjdk.org/browse/JDK-8314976) ------------- Commit messages: - 8314960: Add Certigna Root CA - 2 Changes: https://git.openjdk.org/jdk/pull/15425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314960 Stats: 568 lines in 4 files changed: 338 ins; 227 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15425/head:pull/15425 PR: https://git.openjdk.org/jdk/pull/15425 From valeriep at openjdk.org Fri Aug 25 03:04:22 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 25 Aug 2023 03:04:22 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 00:53:03 GMT, Andrew John Hughes wrote: > There is a long standing limitation in the UNIX smartcardio implementation which means it will only look for the `pcsclite` library in two locations; `/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned library. > > On systems that separate libraries from development headers in separate subpackages, the unversioned library is only installed by the `-devel` package, which rarely happens unless the user wants to write their own application using the libpcsclite headers or build someone else's code themselves. An example of this is the [pcsc-lite-libs package on Fedora](https://koji.fedoraproject.org/koji/rpminfo?rpmID=35258843) > > On Debian-based systems, there is also the issue that libraries are now placed inside a subdirectory using a [tuple](https://wiki.debian.org/Multiarch/Tuples) consisting of the instruction set, syscall ABI and libc e.g. `x86_64-linux-gnu`. So it will not only fail to find the library when only the versioned library is installed (e.g. [libpcsclite1](https://packages.ubuntu.com/kinetic/amd64/libpcsclite1/filelist)) but also when the dev package is also installed (e.g. [libpcsclite-dev](https://packages.ubuntu.com/kinetic/amd64/libpcsclite-dev/filelist)), because the file is in e.g. `/usr/lib/x86_64-linux-gnu/libpcsclite.so` > > This patch makes both cases work. It prefers versioned libraries, as potentially a `libpcsclite.so.2` could become available with a different ABI that the JDK can not work with. All cases that worked before with just `libpcsclite.so` will still work, but it should also now pick up the library on many additional systems. > > A much simpler patch (search for the versioned symlink instead of unversioned) has been [in the Fedora and RHEL packages for nearly a decade](https://bugzilla.redhat.com/show_bug.cgi?id=910107), and an earlier version of this patch with Debian support has been used in IcedTea builds since 2015. It would be nice to finally fix this upstream. > > Testing: > > Test case: > ~~~ > import java.lang.reflect.Method; > > public class TestPlatformPCSC { > public static void main(String[] args) > throws Exception { > Class cls = Class.forName("sun.security.smartcardio.PlatformPCSC"); > Method m = cls.getDeclaredMethod("getLibraryName"); > m.setAccessible(true); > System.err.println(m.invoke(null)); > } > } > ~~~ > > 1. With `libpcsclite.so.1` available: > ~~~ > $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.d... Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15409#pullrequestreview-1594756492 From stuefe at openjdk.org Fri Aug 25 05:42:10 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 25 Aug 2023 05:42:10 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 00:53:03 GMT, Andrew John Hughes wrote: > There is a long standing limitation in the UNIX smartcardio implementation which means it will only look for the `pcsclite` library in two locations; `/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned library. > > On systems that separate libraries from development headers in separate subpackages, the unversioned library is only installed by the `-devel` package, which rarely happens unless the user wants to write their own application using the libpcsclite headers or build someone else's code themselves. An example of this is the [pcsc-lite-libs package on Fedora](https://koji.fedoraproject.org/koji/rpminfo?rpmID=35258843) > > On Debian-based systems, there is also the issue that libraries are now placed inside a subdirectory using a [tuple](https://wiki.debian.org/Multiarch/Tuples) consisting of the instruction set, syscall ABI and libc e.g. `x86_64-linux-gnu`. So it will not only fail to find the library when only the versioned library is installed (e.g. [libpcsclite1](https://packages.ubuntu.com/kinetic/amd64/libpcsclite1/filelist)) but also when the dev package is also installed (e.g. [libpcsclite-dev](https://packages.ubuntu.com/kinetic/amd64/libpcsclite-dev/filelist)), because the file is in e.g. `/usr/lib/x86_64-linux-gnu/libpcsclite.so` > > This patch makes both cases work. It prefers versioned libraries, as potentially a `libpcsclite.so.2` could become available with a different ABI that the JDK can not work with. All cases that worked before with just `libpcsclite.so` will still work, but it should also now pick up the library on many additional systems. > > A much simpler patch (search for the versioned symlink instead of unversioned) has been [in the Fedora and RHEL packages for nearly a decade](https://bugzilla.redhat.com/show_bug.cgi?id=910107), and an earlier version of this patch with Debian support has been used in IcedTea builds since 2015. It would be nice to finally fix this upstream. > > Testing: > > Test case: > ~~~ > import java.lang.reflect.Method; > > public class TestPlatformPCSC { > public static void main(String[] args) > throws Exception { > Class cls = Class.forName("sun.security.smartcardio.PlatformPCSC"); > Method m = cls.getDeclaredMethod("getLibraryName"); > m.setAccessible(true); > System.err.println(m.invoke(null)); > } > } > ~~~ > > 1. With `libpcsclite.so.1` available: > ~~~ > $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.d... Hi @gnu-andrew, in your last example, why does it look for both arm and x64 packages? And why for kFreeBsd? I see you have both hardcoded, why? I would expect it only to attempt and pick up the architecture and OS the VM was built for. Cheers, Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1692789994 From mdonovan at openjdk.org Fri Aug 25 13:09:20 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 25 Aug 2023 13:09:20 GMT Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms Message-ID: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> This PR updates the version of NSS to 3.91 and includes aarch64 platforms. There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one. ------------- Commit messages: - 8314283: Support for NSS tests on aarch64 platforms Changes: https://git.openjdk.org/jdk/pull/15429/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15429&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314283 Stats: 40 lines in 2 files changed: 32 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15429/head:pull/15429 PR: https://git.openjdk.org/jdk/pull/15429 From mullan at openjdk.org Fri Aug 25 16:55:10 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 25 Aug 2023 16:55:10 GMT Subject: RFR: 8314960: Add Certigna Root CA - 2 In-Reply-To: References: Message-ID: <2s6-ypuejmDo3Msa4cQL3PNXDMV5E0bkfhZO6vbpvmk=.e317e7a3-331d-4030-afcb-d29769eafb5d@github.com> On Fri, 25 Aug 2023 00:39:49 GMT, Rajan Halade wrote: > This PR is to add new TLS root certificates from Certigna (Dhimyotis). This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process. > > The release-note is at [JDK-8314976](https://bugs.openjdk.org/browse/JDK-8314976) Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15425#pullrequestreview-1596138217 From rhalade at openjdk.org Fri Aug 25 18:20:21 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 25 Aug 2023 18:20:21 GMT Subject: Integrated: 8314960: Add Certigna Root CA - 2 In-Reply-To: References: Message-ID: <2jLgGc2vt0qRjOwa_fbHh9fpkXNqJx8pTAzOmuFSoik=.4c832d0c-597b-423f-bb64-dba9fa759216@github.com> On Fri, 25 Aug 2023 00:39:49 GMT, Rajan Halade wrote: > This PR is to add new TLS root certificates from Certigna (Dhimyotis). This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process. > > The release-note is at [JDK-8314976](https://bugs.openjdk.org/browse/JDK-8314976) This pull request has now been integrated. Changeset: e9ba8d5a Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/e9ba8d5a0e74c7e61f963b9a295662899d0156dd Stats: 568 lines in 4 files changed: 338 ins; 227 del; 3 mod 8314960: Add Certigna Root CA - 2 Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/15425 From valeriep at openjdk.org Fri Aug 25 19:52:11 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 25 Aug 2023 19:52:11 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v3] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 20:02:30 GMT, Rajan Halade wrote: >> Removed. > > DIGESTS is still not used. Missed to commit this file. Will update in the next commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1306090806 From valeriep at openjdk.org Fri Aug 25 19:52:15 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 25 Aug 2023 19:52:15 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v3] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 18:21:28 GMT, Rajan Halade wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> More review feedbacks > > test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 117: > >> 115: System.out.println("=> Skip; no PSS support"); >> 116: return; >> 117: } > > else...Should the test be marked as failed? Sure, should not happen but good to check to be sure. > test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 117: > >> 115: System.out.println(" => Skip; no PSS support"); >> 116: return; >> 117: } > > Same here, should test fail here? Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1306088345 PR Review Comment: https://git.openjdk.org/jdk/pull/15217#discussion_r1306090152 From valeriep at openjdk.org Fri Aug 25 22:42:05 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 25 Aug 2023 22:42:05 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v4] In-Reply-To: References: Message-ID: > Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. > > This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. > > The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). > > Thanks in advance for review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: address more review feedbacks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15217/files - new: https://git.openjdk.org/jdk/pull/15217/files/499e9636..03a194d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15217&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15217&range=02-03 Stats: 16 lines in 3 files changed: 7 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15217/head:pull/15217 PR: https://git.openjdk.org/jdk/pull/15217 From ascarpino at openjdk.org Sat Aug 26 00:18:07 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Sat, 26 Aug 2023 00:18:07 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 06:12:29 GMT, Smita Kamath wrote: > Hi All, > I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. > > Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: > > |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup > |-------------|------------|---------------|------------------|-----------| > |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 > full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 > small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 > small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 > full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 > full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 > small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 > small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 > full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 > small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 > small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 > full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 > full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 > small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 > small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 > full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 > small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 > small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 > full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 > full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 > small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 > small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 > full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 > small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 > small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 > full.AESGCMBench.decryptMultiPart | 65536 | 42649.816 | 47591.587 |1.11 > full.AESGCMBe... I'm curious in the Java code, why an encryption boolean was needed for this change but wasn't needed for the AVX512 changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1694061827 From alanb at openjdk.org Sat Aug 26 13:44:08 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 26 Aug 2023 13:44:08 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote: > yes this is of course AIX specific. However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files. Right now, you've got concerns/objections from two potential reviewers so it would be better to see if there are other options to help the error logs on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1694344116 From dholmes at openjdk.org Mon Aug 28 02:29:18 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 28 Aug 2023 02:29:18 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken wrote: >> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. >> Some examples : >> Events::log_dll_message for hs-err files reporting >> JFR event NativeLibraryLoad >> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), >> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information >> >> Offer an interface (e.g. jvm.cpp) to support this. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > windows aarch64 build issues Sorry but looking at the hotspot part of this I do not like the code in jvm.cpp at all - it is far too messy. I expected to see a simple interface to os::dlopen which then handles all the platform specific issues. I'm also somewhat dubious about having all the JDK code use a VM interface for this, The usual coupling to the VM is to just provide native implementations of core library methods, not to have the VM provide a general purpose utility interface like dynamic library loading. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1694907802 From dzhang at openjdk.org Mon Aug 28 03:28:15 2023 From: dzhang at openjdk.org (Dingli Zhang) Date: Mon, 28 Aug 2023 03:28:15 GMT Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> Message-ID: On Fri, 25 Aug 2023 13:02:39 GMT, Matthew Donovan wrote: > This PR updates the version of NSS to 3.91 and includes aarch64 platforms. > > There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one. Hi @mpdonova thanks for this PR! I executed `sun/security/pkcs11/SampleTest.java` on linux-aarch64 but the nss test is skipped. bash configure \ --with-jtreg=/home/dingli/jdk-tools/jtreg \ --disable-warnings-as-errors \ --with-boot-jdk=/home/dingli/jdk-bin/jdk-21 \ --with-debug-level=fastdebug \ --with-native-debug-symbols=none make test TEST="jtreg:sun/security/pkcs11/SampleTest.java" JOBS=8 Log in `test-support/jtreg_test_jdk_sun_security_pkcs11_SampleTest_java/sun/security/pkcs11/SampleTest.jtr` : ===> testNSS: Starting test run Cannot resolve artifact, please check if JIB jar is present in classpath. Warning: unsupported OS: Linux-aarch64-64, please initialize NSS library location, skipping test testNSS: Skipped jtreg.SkippedException: testNSS: Problem loading NSS libraries at PKCS11Test.testNSS(PKCS11Test.java:563) at PKCS11Test.main(PKCS11Test.java:205) at PKCS11Test.main(PKCS11Test.java:168) at SampleTest.main(SampleTest.java:42) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1570) The question here is do I need to set up the jib? I tried to use `bin/jib.sh` but I don't know how to set `JIB_SERVER`(`export JIB_SERVER=https://java.se.oracle.com/artifactory` doesn't seem to work). Could you give me some advice? Thanks a lot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15429#issuecomment-1694947348 From djelinski at openjdk.org Mon Aug 28 05:30:29 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 28 Aug 2023 05:30:29 GMT Subject: Integrated: 8314148: Fix variable scope in SunMSCAPI In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 06:36:42 GMT, Daniel Jeli?ski wrote: > Please review this patch that fixes the scope of 2 local variables to make sure they are in scope when they are used. > > The patch additionally fixes one `c++11-narrowing` Clang warning by explicitly casting string size (`size_t`) to `DWORD`. This pull request has now been integrated. Changeset: 12de9b02 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/12de9b0225363377e9a76729b11698221d4f29f2 Stats: 13 lines in 3 files changed: 4 ins; 4 del; 5 mod 8314148: Fix variable scope in SunMSCAPI Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/15242 From mbaesken at openjdk.org Mon Aug 28 07:05:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 28 Aug 2023 07:05:13 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2] In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 02:26:30 GMT, David Holmes wrote: > Sorry but looking at the hotspot part of this I do not like the code in jvm.cpp at all - it is far too messy. I expected to see a simple interface to os::dlopen which then handles all the platform specific issues. > > I'm also somewhat dubious about having all the JDK code use a VM interface for this, The usual coupling to the VM is to just provide native implementations of core library methods, not to have the VM provide a general purpose utility interface like dynamic library loading. Hi David, so would you prefer to call into 'os::dll_load' (probably you meant that) instead ? That would indeed make the coding smaller and less 'messy' . However 'os::dll_load' has no flags parameter but uses a default, have to check if this might be a problem ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1695142975 From duke at openjdk.org Mon Aug 28 14:04:10 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 28 Aug 2023 14:04:10 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions In-Reply-To: References: Message-ID: On Sat, 26 Aug 2023 00:15:44 GMT, Anthony Scarpino wrote: > I'm curious in the Java code, why an encryption boolean was needed for this change but wasn't needed for the AVX512 changes. It is the other way around, the java code accesses the class' "encrypt" variable easily, but it was easier to add it as an argument for the intrinsic. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1695755375 From lkorinth at openjdk.org Mon Aug 28 16:01:53 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 28 Aug 2023 16:01:53 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder Message-ID: Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: /** * Create ProcessBuilder using the java launcher from the jdk to * be tested. * *

Please observe that you likely should use * createTestJvm() instead of this method because createTestJvm() * will add JVM options from "test.vm.opts" and "test.java.opts" * and this method will not do that. * * @param command Arguments to pass to the java command. * @return The ProcessBuilder instance representing the java command. */ I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... I have run tier 1 testing, and I have started more exhaustive testing. ------------- Commit messages: - 8315097: Rename createJavaProcessBuilder Changes: https://git.openjdk.org/jdk/pull/15452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315097 Stats: 756 lines in 462 files changed: 22 ins; 10 del; 724 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From weijun at openjdk.org Mon Aug 28 18:31:23 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 28 Aug 2023 18:31:23 GMT Subject: RFR: 8311081: KeytoolReaderP12Test.java fail on localized Windows platform [v2] In-Reply-To: References: Message-ID: <0yu__L0QVwRSIg3PTDvBMn8Y1VObLAhCzW-7f0pY9Uc=.6c9fefea-d621-49ef-bb6a-04c490936248@github.com> On Thu, 13 Jul 2023 18:07:54 GMT, Justin Lu wrote: >> Please review this PR which addresses `KeytoolReaderP12Test.java` failing for non-English locale users. >> >> This test checks output from keytool, but fails on finding the value 'alias name' for non-English locale users. This is because 'alias name' is a localized value. (For example, in `ja` this is '??'). >> >> To fix the failing issue, the keytool process should be ran with `-J-Duser.language=en -J-Duser.country=US`. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Revert spacing changes to KeytoolReaderP12Test.java > - Move English locale params to executeKeytoolCommand Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14806#pullrequestreview-1598824120 From lmesnik at openjdk.org Mon Aug 28 19:06:11 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 28 Aug 2023 19:06:11 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth wrote: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. The. changes looks good. Please update copyrights for changed filed. I expect that you completed execution of all tests to ensure that nothing is broken. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1598884378 From jlu at openjdk.org Mon Aug 28 20:39:19 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 28 Aug 2023 20:39:19 GMT Subject: Integrated: 8311081: KeytoolReaderP12Test.java fail on localized Windows platform In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 18:58:02 GMT, Justin Lu wrote: > Please review this PR which addresses `KeytoolReaderP12Test.java` failing for non-English locale users. > > This test checks output from keytool, but fails on finding the value 'alias name' for non-English locale users. This is because 'alias name' is a localized value. (For example, in `ja` this is '??'). > > To fix the failing issue, the keytool process should be ran with `-J-Duser.language=en -J-Duser.country=US`. This pull request has now been integrated. Changeset: b4b2fecb Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/b4b2fecb42d9f14d73e8d79a9e59dee4d697f9cf Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8311081: KeytoolReaderP12Test.java fail on localized Windows platform Reviewed-by: lancea, jpai, weijun ------------- PR: https://git.openjdk.org/jdk/pull/14806 From valeriep at openjdk.org Mon Aug 28 23:40:10 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 28 Aug 2023 23:40:10 GMT Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> Message-ID: On Fri, 25 Aug 2023 13:02:39 GMT, Matthew Donovan wrote: > This PR updates the version of NSS to 3.91 and includes aarch64 platforms. > > There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one. There is another bug id for updating the NSS version to 3.91 - https://bugs.openjdk.org/browse/JDK-8312476 Besides just changing the NSS version, we need to ensure there is corresponding NSS library in the artifactory... So, this may have to wait til 8312476 is addressed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15429#issuecomment-1696563707 From dholmes at openjdk.org Tue Aug 29 05:06:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 29 Aug 2023 05:06:08 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth wrote: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. I think the admonition about using this method is a bit strong in that it is natural to use this plain process builder method when a test is going to set its own specific flags for the exec'd process. But I'm okay with renaming to avoid copy'n'paste errors that accidentally use the wrong version. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1599483514 From lkorinth at openjdk.org Tue Aug 29 09:12:51 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 29 Aug 2023 09:12:51 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15452/files - new: https://git.openjdk.org/jdk/pull/15452/files/4b2d1711..f3418c80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=00-01 Stats: 344 lines in 344 files changed: 0 ins; 0 del; 344 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From mdonovan at openjdk.org Tue Aug 29 11:55:09 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 29 Aug 2023 11:55:09 GMT Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> Message-ID: On Fri, 25 Aug 2023 13:02:39 GMT, Matthew Donovan wrote: > This PR updates the version of NSS to 3.91 and includes aarch64 platforms. > > There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one. If you have a local copy of NSS you can run the tests with jtreg instead of make. The tests expect a directory structure that looks like this: nss/ lib/ When I built NSS 3.91 locally, the final binaries were in `nss-3.91/dist/Debug/`. I created a directory, `nss`, and copied the bin, lib, and include directories into it: % ls $HOME/nss-3.91/dist/Debug/nss bin/ include/ lib/ ``` I can run the test with jtreg by specifying the path in a system property: jtreg -verbose:summary -ea -esa -a -agentvm -conc:4 -report:executed \ -Djdk.test.lib.artifacts.nsslib-macosx_aarch64=$HOME/nss-3.91/dist/Debug \ test/jdk/sun/security/pkcs11/SampleTest.java The final component of the system property will depend on that platform you're running the test on and some of the jtreg arguments and paths will be different on your machine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15429#issuecomment-1697295018 From rriggs at openjdk.org Tue Aug 29 14:09:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 29 Aug 2023 14:09:12 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 09:12:51 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > copyright I don't think this is the best change across so many files. It gives a very ugly name to a common test function and affects a very large number of tests. ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1600512718 From lkorinth at openjdk.org Tue Aug 29 15:13:11 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 29 Aug 2023 15:13:11 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 14:06:01 GMT, Roger Riggs wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright > > I don't think this is the best change across so many files. > It gives a very ugly name to a common test function and affects a very large number of tests. @RogerRiggs If it is only the name you want changed, maybe you can offer a better name? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1697634872 From rhalade at openjdk.org Tue Aug 29 16:47:13 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 29 Aug 2023 16:47:13 GMT Subject: RFR: 8312428: PKCS11 tests fail with NSS 3.91 [v4] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 22:42:05 GMT, Valerie Peng wrote: >> Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. >> >> This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. >> >> The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). >> >> Thanks in advance for review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > address more review feedbacks Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15217#pullrequestreview-1600868746 From rriggs at openjdk.org Tue Aug 29 16:48:15 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 29 Aug 2023 16:48:15 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com> On Tue, 29 Aug 2023 14:06:01 GMT, Roger Riggs wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright > > I don't think this is the best change across so many files. > It gives a very ugly name to a common test function and affects a very large number of tests. > @RogerRiggs If it is only the name you want changed, maybe you can offer a better name? @lkorinth Sorry for the too short comment; I wanted to make sure it wasn't integrated before I could look at it more closely. Neither the bug report or the PR describe the problem and its ramifications, only the solution. Can you elaborate on the conditions that lead to this. (and include them in the bug report). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1697803842 From rhalade at openjdk.org Tue Aug 29 16:58:12 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 29 Aug 2023 16:58:12 GMT Subject: RFR: 8314283: Support for NSS tests on aarch64 platforms In-Reply-To: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> References: <08633LT4oZahJyDN9EKp_OEDOwJ6MfNRRp2TMAyp-84=.92576e72-be06-47fc-aec4-4a6c6ee7488b@github.com> Message-ID: On Fri, 25 Aug 2023 13:02:39 GMT, Matthew Donovan wrote: > This PR updates the version of NSS to 3.91 and includes aarch64 platforms. > > There is a related bug in PR (https://github.com/openjdk/jdk/pull/15217) so we may want to wait for that to merge before merging this one. Please check lines of code at https://github.com/openjdk/jdk/pull/15429/files#diff-e49ff36652e24a0059feca1b9d68f2544ba609924e9ee25e01a90096532b66e5R709 added with [JDK-8296675](https://bugs.openjdk.org/browse/JDK-8296675). Should these be removed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15429#issuecomment-1697817194 From cjplummer at openjdk.org Tue Aug 29 19:25:12 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 29 Aug 2023 19:25:12 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 09:12:51 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > copyright > I kind of like that it is long and clumsy, that makes it harder to use... ...but it's used in 462 files. That implies it is commonly used. Are you suggesting nearly all those uses are incorrect and eventually should be converted to `createTestJvm()`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698003837 From ascarpino at openjdk.org Tue Aug 29 21:32:09 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 29 Aug 2023 21:32:09 GMT Subject: RFR: 8312306: Add more Reference.reachabilityFence() calls to the security classes using Cleaner In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 18:06:59 GMT, Valerie Peng wrote: > This PR updates the various security classes using Cleaner with the try/finally pattern. Also noticed that SunJCE's PBEKey impl class overrides the destroy() method but not the isDestroyed() method, fixed this inconsistency as well. > > Thanks in advance for the review! I am fine with the change ------------- Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15390#pullrequestreview-1601310478 From andrew at openjdk.org Tue Aug 29 21:59:37 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 29 Aug 2023 21:59:37 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory [v3] 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 with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge remote-tracking branch 'jdk/master' into secdir - Sort the returned list of property files and exclude hidden files. - 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=02 Stats: 172 lines in 3 files changed: 163 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 valeriep at openjdk.org Tue Aug 29 22:11:20 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 29 Aug 2023 22:11:20 GMT Subject: Integrated: 8312428: PKCS11 tests fail with NSS 3.91 In-Reply-To: References: Message-ID: <7cfHYVLcQ6ifWTb8gy9coyq6qxwhUWeZt9JVK6W3zvc=.8eb969c2-8910-448c-913b-6d648e4f7fa5@github.com> On Thu, 10 Aug 2023 00:56:56 GMT, Valerie Peng wrote: > Starting NSS v3.91, SHA-3 support is added for MessageDigest but not for PSS Signature. This breaks existing test assumptions made by PSS regression tests. In addition, the NSS SHA-3 message digests do not support cloning which causes the failure of TestCloning.java. > > This PR adds a PSSUtil.java class which provides utility method for detecting/guessing whether a digest algorithm is valid for PSS signature or not. > > The changes are verified with NSS v3.46, v3.57 and v3.91 (on local Linux machine). > > Thanks in advance for review~ This pull request has now been integrated. Changeset: 1c598c22 Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/1c598c2245c5c348e946f4d0df653daa6e42da94 Stats: 268 lines in 4 files changed: 153 ins; 60 del; 55 mod 8312428: PKCS11 tests fail with NSS 3.91 Reviewed-by: ssahoo, rhalade ------------- PR: https://git.openjdk.org/jdk/pull/15217 From andrew at openjdk.org Tue Aug 29 23:13:09 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 29 Aug 2023 23:13:09 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory [v2] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 01:27:55 GMT, Martin Balao wrote: > As commented here [1], @franferrax and I have been working on a different approach to this problem. We suggest to put this PR on hold until we have our proposal ready to compare and discuss further. > > -- [1] - https://bugs.openjdk.org/browse/JDK-8309331?focusedCommentId=14606264&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14606264 This doesn't seem to address the same problem. This PR & CSR are aimed at extending the existing functionality of `java.security.properties` with permanent configuration and the option of multiple files, while also allowing these configuration snippets to be maintained separately outside a single JDK. What you seem to be suggesting involves adding a meta-property to the property file to instruct it to be replaced with another file and would require multiple such instructions for each file. One of the benefits of this proposal is the directory can be setup once in the `java.security` file and then future maintenance can take place on the referenced directory for all JDKs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14277#issuecomment-1698259042 From andrew at openjdk.org Wed Aug 30 01:06:19 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 30 Aug 2023 01:06:19 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 05:39:39 GMT, Thomas Stuefe wrote: > Hi @gnu-andrew, > > in your last example, why does it look for both arm and x64 packages? And why for kFreeBsd? I see you have both hardcoded, why? > > I would expect it only to attempt and pick up the architecture and OS the VM was built for. Good question. Because they don't fit the template `$ARCH-linux-gnu/libpcsclite.so` which would expand to `arm-linux-gnu/libpcsclite.so`. I don't know of a way off-hand to get the ABI or the kernel in use (`kfreebsd` is not a BSD variant, but the usual GNU userland paired with the FreeBSD kernel rather than Linux). The [Wikipedia page](https://en.wikipedia.org/wiki/Debian#Derivatives_and_flavors) actually says it's now discontinued, so maybe we can just drop that one. It probably shows how long ago I [originally wrote and tested these paths](https://icedtea.wildebeest.org/hg/release/icedtea7-forest-2.6/jdk/rev/ae5765c7b8e2)... :) In short, that was my lazy option for catching those cases that won't fit the common one. I'm open to suggestions. We could skip any template with `'arm'` in, I guess, if the architecture doesn't match. It is worth noting though, that this file is already common to all the UNIX platforms and doesn't do any OS checks, despite the last check being a MacOS framework. That also presumably means MacOS doesn't have any of the `/usr` libraries in turn . > > Cheers, Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1698341466 From andrew at openjdk.org Wed Aug 30 01:09:17 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 30 Aug 2023 01:09:17 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so In-Reply-To: References: Message-ID: <7p4Yu7bY60i-wdyLGEuvxW2SYbd0mlFTW4u18Fg87lI=.d39275bc-b082-4fa0-99a7-ac4cadde8e89@github.com> On Fri, 25 Aug 2023 00:39:14 GMT, Valerie Peng wrote: > Changes look fine. I submitted a mach5 test job just in case. Will approve once the test job passes. BTW, I added a noreg-other label since there is no regression test for this change. Thanks. Yes, I don't see how we can have a regression test for this one. My own testing was manual and involved moving the system library around as root... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1698343166 From stuefe at openjdk.org Wed Aug 30 06:28:19 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 30 Aug 2023 06:28:19 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so In-Reply-To: References: Message-ID: <75cUAoWvGTN51A3OzZS9kHUgq08J-bj9RsUxd09OCEs=.f570cb9c-fb1b-4c33-9379-169e15ce5242@github.com> On Thu, 24 Aug 2023 00:53:03 GMT, Andrew John Hughes wrote: > There is a long standing limitation in the UNIX smartcardio implementation which means it will only look for the `pcsclite` library in two locations; `/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned library. > > On systems that separate libraries from development headers in separate subpackages, the unversioned library is only installed by the `-devel` package, which rarely happens unless the user wants to write their own application using the libpcsclite headers or build someone else's code themselves. An example of this is the [pcsc-lite-libs package on Fedora](https://koji.fedoraproject.org/koji/rpminfo?rpmID=35258843) > > On Debian-based systems, there is also the issue that libraries are now placed inside a subdirectory using a [tuple](https://wiki.debian.org/Multiarch/Tuples) consisting of the instruction set, syscall ABI and libc e.g. `x86_64-linux-gnu`. So it will not only fail to find the library when only the versioned library is installed (e.g. [libpcsclite1](https://packages.ubuntu.com/kinetic/amd64/libpcsclite1/filelist)) but also when the dev package is also installed (e.g. [libpcsclite-dev](https://packages.ubuntu.com/kinetic/amd64/libpcsclite-dev/filelist)), because the file is in e.g. `/usr/lib/x86_64-linux-gnu/libpcsclite.so` > > This patch makes both cases work. It prefers versioned libraries, as potentially a `libpcsclite.so.2` could become available with a different ABI that the JDK can not work with. All cases that worked before with just `libpcsclite.so` will still work, but it should also now pick up the library on many additional systems. > > A much simpler patch (search for the versioned symlink instead of unversioned) has been [in the Fedora and RHEL packages for nearly a decade](https://bugzilla.redhat.com/show_bug.cgi?id=910107), and an earlier version of this patch with Debian support has been used in IcedTea builds since 2015. It would be nice to finally fix this upstream. > > Testing: > > Test case: > ~~~ > import java.lang.reflect.Method; > > public class TestPlatformPCSC { > public static void main(String[] args) > throws Exception { > Class cls = Class.forName("sun.security.smartcardio.PlatformPCSC"); > Method m = cls.getDeclaredMethod("getLibraryName"); > m.setAccessible(true); > System.err.println(m.invoke(null)); > } > } > ~~~ > > 1. With `libpcsclite.so.1` available: > ~~~ > $ ~/builder/trunk/images/jdk/bin/java --add-opens java.smartcardio/sun.security.smartcardio=ALL-UNNAMED -Djava.security.d... Marked as reviewed by stuefe (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15409#pullrequestreview-1601963361 From stuefe at openjdk.org Wed Aug 30 06:28:20 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 30 Aug 2023 06:28:20 GMT Subject: RFR: 8009550: PlatformPCSC should load versioned so In-Reply-To: <7p4Yu7bY60i-wdyLGEuvxW2SYbd0mlFTW4u18Fg87lI=.d39275bc-b082-4fa0-99a7-ac4cadde8e89@github.com> References: <7p4Yu7bY60i-wdyLGEuvxW2SYbd0mlFTW4u18Fg87lI=.d39275bc-b082-4fa0-99a7-ac4cadde8e89@github.com> Message-ID: On Wed, 30 Aug 2023 01:06:01 GMT, Andrew John Hughes wrote: >> Changes look fine. I submitted a mach5 test job just in case. Will approve once the test job passes. >> BTW, I added a noreg-other label since there is no regression test for this change. > >> Changes look fine. I submitted a mach5 test job just in case. Will approve once the test job passes. BTW, I added a noreg-other label since there is no regression test for this change. > > Thanks. Yes, I don't see how we can have a regression test for this one. My own testing was manual and involved moving the system library around as root... > > Hi @gnu-andrew, > > in your last example, why does it look for both arm and x64 packages? And why for kFreeBsd? I see you have both hardcoded, why? > > I would expect it only to attempt and pick up the architecture and OS the VM was built for. > > Good question. > > Because they don't fit the template `$ARCH-linux-gnu/libpcsclite.so` which would expand to `arm-linux-gnu/libpcsclite.so`. > > I don't know of a way off-hand to get the ABI or the kernel in use (`kfreebsd` is not a BSD variant, but the usual GNU userland paired with the FreeBSD kernel rather than Linux). The [Wikipedia page](https://en.wikipedia.org/wiki/Debian#Derivatives_and_flavors) actually says it's now discontinued, so maybe we can just drop that one. It probably shows how long ago I [originally wrote and tested these paths](https://icedtea.wildebeest.org/hg/release/icedtea7-forest-2.6/jdk/rev/ae5765c7b8e2)... :) > > In short, that was my lazy option for catching those cases that won't fit the common one. I'm open to suggestions. We could skip any template with `'arm'` in, I guess, if the architecture doesn't match. It is worth noting though, that this file is already common to all the UNIX platforms and doesn't do any OS checks, despite the last check being a MacOS framework. That also presumably means MacOS doesn't have any of the `/usr` libraries in turn . Yes, that's a bit tricky. I was concerned about the JVM picking up the wrong library on a mulitarch system, since having multiple of these directories is the point of multiarch. But maybe its fine. The difference between the arm variants is that the float mode (soft vs hard) and I believe the former should always work, so if we accidentally pick it up, it should be no problem. The kfreebsd one I'd just drop. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1698566452 From dholmes at openjdk.org Wed Aug 30 07:22:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 30 Aug 2023 07:22:10 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com> References: <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com> Message-ID: On Tue, 29 Aug 2023 16:45:12 GMT, Roger Riggs wrote: >> I don't think this is the best change across so many files. >> It gives a very ugly name to a common test function and affects a very large number of tests. > >> @RogerRiggs If it is only the name you want changed, maybe you can offer a better name? > @lkorinth > > Sorry for the too short comment; I wanted to make sure it wasn't integrated before I could look at it more closely. > Neither the bug report or the PR describe the problem and its ramifications, only the solution. > Can you elaborate on the conditions that lead to this. (and include them in the bug report). @RogerRiggs , @plummercj , please see the additional discussion in the parent bug: https://bugs.openjdk.org/browse/JDK-8314823 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698629345 From lkorinth at openjdk.org Wed Aug 30 09:23:55 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 30 Aug 2023 09:23:55 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: fix static import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15452/files - new: https://git.openjdk.org/jdk/pull/15452/files/f3418c80..27da7150 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From msheppar at openjdk.org Wed Aug 30 11:34:12 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 30 Aug 2023 11:34:12 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import I don't think a name change is required. The method is createJavaProcessBuilder with a "list" of argurments and a builder is returned. As such, there is no inference, in the name, that test args will be propagated. Adding the additional java doc description should be sufficient to dispell any misconceptions. The createTestJvm is a misnomer as it returns a ProcessBulder rather than a Process, which is what I would expected from createTestJvm, without looking at its signature. So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g. createJavaProcessBuilder(List command, boolean addTestOpts) { ... } createProcessBuilderIgnoreJavaTestOpt(cmdArgs) maps to createJavaProcessBuilder(cmdArgs, false) createTestJvm(cmdArgs) maps to createJavaProcessBuilder(cmdArgs, true) But this is a lot more work. alternatively change createTestJvm to createTestJavaProcessBuilder or createJavaProcessBuilderAddTestOpts ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698985460 From rriggs at openjdk.org Wed Aug 30 15:10:13 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 30 Aug 2023 15:10:13 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import In the context of the goal is to declaratively identify tests that do or do not benefit from additional test flags renaming the `createjavaProcessBuilder` method does not further that goal. The method name and javadoc of `createjavaProcessBuilder` do not imply that the test options are consulted or used; it only says it creates a ProcessBuilder, and does not promise or document more than that. The javadoc should probably describe the use of the the three properties that modify the way that the java is launched. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699362435 From lkorinth at openjdk.org Wed Aug 30 17:13:53 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 30 Aug 2023 17:13:53 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: <3xqrbByJLBJTDN1-C_aG0wwe6PFy09-tMyL0TwEn4Gc=.88dbe2a2-ad5d-4545-ab30-4a9e5312641f@github.com> On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import I have some ideas that I will work on that might lead to a new proposal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699542111 From stefank at openjdk.org Wed Aug 30 17:40:33 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 30 Aug 2023 17:40:33 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import >From talking to other HotSpot devs it is quite clear that the different names lead to mistakes when writing (copy-n-pasting) tests, so I'm happy that we try to figure out some way to make it more obvious when we prepend the extra test options and when we don't. I agree with @msheppar that `createTestJvm` isn't a good name and I wouldn't be opposed to changing that name instead of `createJavaProcessBuilder`. However, if we do rename that function I strongly urge us to also rename the corresponding `executeTestJvm` function. I also think it is too obscure that functions with *Test* in the name prepend the extra test options, and those without *Test* don't, so I'd like to get rid of that convention. I wouldn't be opposed to a change that: * Keeps the `createJavaProcessBuilder` name * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts` * Renames `executeTestJvm` to `executeJavaPrependTestOpts` * Removes `createTestJava` * Removes `executeTestJava` ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699588853 From rhalade at openjdk.org Wed Aug 30 20:52:46 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 30 Aug 2023 20:52:46 GMT Subject: RFR: 8161536: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with ProviderException Message-ID: This test is removed from ProblemList. I ran test locally and on CI with hundred iteration. Failure is not seen as [JDK-8240256](https://bugs.openjdk.org/browse/JDK-8240256) is fixed. ------------- Commit messages: - 8161536: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with ProviderException Changes: https://git.openjdk.org/jdk/pull/15497/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15497&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8161536 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15497/head:pull/15497 PR: https://git.openjdk.org/jdk/pull/15497 From jjiang at openjdk.org Thu Aug 31 02:41:25 2023 From: jjiang at openjdk.org (John Jiang) Date: Thu, 31 Aug 2023 02:41:25 GMT Subject: RFR: JDK-8315422: getSoTimeout() would be in try block in SSLSocketImpl Message-ID: The method `SSLSocketImpl::closeSocket` has the below code snippet, if (appInput.readLock.tryLock()) { int soTimeout = getSoTimeout(); try { // deplete could hang on the skip operation // in case of infinite socket read timeout. // Change read timeout to avoid deadlock. // This workaround could be replaced later // with the right synchronization if (soTimeout == 0) setSoTimeout(DEFAULT_SKIP_TIMEOUT); inputRecord.deplete(false); } catch (java.net.SocketTimeoutException stEx) { // skip timeout exception during deplete } finally { if (soTimeout == 0) setSoTimeout(soTimeout); appInput.readLock.unlock(); } } If `getSoTimeout()` throws an exception, say `SocketException`, `appInput.readLock.unlock()` cannot be called. ------------- Commit messages: - JDK-8315422: getSoTimeout() would be in try block in SSLSocketImpl Changes: https://git.openjdk.org/jdk/pull/15503/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15503&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315422 Stats: 19 lines in 1 file changed: 6 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/15503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15503/head:pull/15503 PR: https://git.openjdk.org/jdk/pull/15503 From jnimeh at openjdk.org Thu Aug 31 02:57:58 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 31 Aug 2023 02:57:58 GMT Subject: RFR: JDK-8315422: getSoTimeout() would be in try block in SSLSocketImpl In-Reply-To: References: Message-ID: <-CmZQCRHlRNsfuAVaBaxuV6Q5gycBkrBRJsnLnte-VQ=.b7b4637e-99e5-4f97-9680-0e0a10c961a9@github.com> On Thu, 31 Aug 2023 02:34:58 GMT, John Jiang wrote: > The method `SSLSocketImpl::closeSocket` has the below code snippet, > > > if (appInput.readLock.tryLock()) { > int soTimeout = getSoTimeout(); > try { > // deplete could hang on the skip operation > // in case of infinite socket read timeout. > // Change read timeout to avoid deadlock. > // This workaround could be replaced later > // with the right synchronization > if (soTimeout == 0) > setSoTimeout(DEFAULT_SKIP_TIMEOUT); > inputRecord.deplete(false); > } catch (java.net.SocketTimeoutException stEx) { > // skip timeout exception during deplete > } finally { > if (soTimeout == 0) > setSoTimeout(soTimeout); > appInput.readLock.unlock(); > } > } > > > If `getSoTimeout()` throws an exception, say `SocketException`, `appInput.readLock.unlock()` cannot be called. This looks good to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15503#pullrequestreview-1603786718 From dholmes at openjdk.org Thu Aug 31 05:48:04 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 31 Aug 2023 05:48:04 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 11:31:20 GMT, Mark Sheppard wrote: > So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g. createJavaProcessBuilder(List command, boolean addTestOpts) { ... } @msheppar that is actually where we started, and it was then split into two differently named methods to "make it clear" which one included the test opts without having to remember the name of the parameter that the true/false argument was bound to. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700402301 From alanb at openjdk.org Thu Aug 31 06:51:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 31 Aug 2023 06:51:00 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote: > I wouldn't be opposed to a change that: > > * Keeps the `createJavaProcessBuilder` name > * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts` > * Renames `executeTestJvm` to `executeJavaPrependTestOpts` > * Removes `createTestJava` > * Removes `executeTestJava` The good thing with this is that it very explicit at the use-sites where the test opts are prepended. Also moving from "Jvm" to "Java" is probably right as it executes the "java" launcher, the options are a mix of java launcher options (that the VM doesn't know about) and VM options. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700459277 From msheppar at openjdk.org Thu Aug 31 10:11:02 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 31 Aug 2023 10:11:02 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 05:45:27 GMT, David Holmes wrote: > > So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g. > > createJavaProcessBuilder(List command, boolean addTestOpts) { ... } > > @msheppar that is actually where we started, and it was then split into two differently named methods to "make it clear" which one included the test opts without having to remember the name of the parameter that the true/false argument was bound to. cheers David thanks for the clarification on background ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700749844 From filipakanation at gmail.com Thu Aug 31 14:00:38 2023 From: filipakanation at gmail.com (Filip Petr.) Date: Thu, 31 Aug 2023 16:00:38 +0200 Subject: Modification of Client hello TLS packet Message-ID: My goal is for a community of automation experts to have a perfectly matched Client hello (JA3 hash) fingerprint as modern commercial browsers so they can do their job more successfully. For this to happen one must add 8 additional extensions to the Client hello request. Those changes were done under /sun/security/ssl. Mostly modifying SSLExtension.java file by adding additional extensions. My goal is to have perfectly working adjusted extensions and to use TLS1.3 on top of that. The extensions that my Java client using standard Java net library had prior me adding new ones were: 1.key_share 2. signature_algorithms_cert 3. psk_key_exchange_modes 4. supported_versions 5. signature_algorithms 6. application_layer_protocol_negotiation 7. supported_group 8. status_request 9. server_name After the change to match Chrome's extensions it became: 1. TLS_GREASE (0x5a5a) 2. status_request 3. ec_point_formats 4. supported_groups 5. signed_certificate_timestamp 6. application_settings 7. server_name 8. application_layer_protocol_negotiation 9. key_share 10. extended_master_secret 11. extensionRenegotiationInfo 12. session_ticket 13. supported_versions 14. signature_algorithms 15. psk_key_exchange_modes 16. TLS_GREASE (0x3a3a) 17. padding The reason for me making this post is because when I add application_settings extension, the module doesn't work for certain websites such as for google domains and for some it works perfectly fine. I analysed in Wireshark the requests they were all properly done but for some weird reason, Java gives back following exceptions once I encounter some sites it crashes on 1. Received fatal alert: decode_error 2. Unknown handshake type size, Handshake.msg_type = 25 3. Received fatal alert: unexpected_message Unfortunately I don't know how to track fatal alerts and their cores so I'm not sure how I can handle this. Why does Java crash on this simple extension such as application_settings? It holds nothing but following { "name": "application_settings (17513)", "protocols": [ "h2" ] } That's pretty much it. Once I remove this extension, the module works just fine with the rest added ones. I should add on top that i do these 2 following lines as my ssl configuration prior creating java client sslParams.setApplicationProtocols(new String[] {"h2", "http/1.1"}); sslParams.setProtocols(new String[]{"TLSv1.3"}); Any help would be welcome! Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.farrell at cs.tcd.ie Thu Aug 31 14:36:42 2023 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Thu, 31 Aug 2023 15:36:42 +0100 Subject: Modification of Client hello TLS packet In-Reply-To: References: Message-ID: <9f13bc10-18db-aec5-2ccb-1fff82cc5ea5@cs.tcd.ie> Hiya, On 31/08/2023 15:00, Filip Petr. wrote: > My goal is for a community of automation experts to have a perfectly > matched Client hello (JA3 hash) fingerprint as modern commercial browsers > so they can do their job more successfully. For this to happen one must add > 8 additional extensions to the Client hello request. Can't help with your query, sorry, but worth noting that work on encrypted client hello (ECH) is progressing towards completion in the IETF, and a pre-standards version is deployed now in browsers (albeit behind a flag for both FF and chromium-derived browsers). If, as I'd hope, ECH gets finalised early next year and then deployed, that'll change the profile of the ClientHello possibly significantly. As this is something on which I'm working [1] I'd be happy to discuss how to get ECH support working, then deployed, in this context too, so if that's of interest, just ping me. Cheers, S. [1] https://defo.ie > Those changes were > done under /sun/security/ssl. Mostly modifying SSLExtension.java file by > adding additional extensions. My goal is to have perfectly working adjusted > extensions and to use TLS1.3 on top of that. The extensions that my Java > client using standard Java net library had prior me adding new ones were: > 1.key_share > 2. signature_algorithms_cert > 3. psk_key_exchange_modes > 4. supported_versions > 5. signature_algorithms > 6. application_layer_protocol_negotiation > 7. supported_group > 8. status_request > 9. server_name > > After the change to match Chrome's extensions it became: > 1. TLS_GREASE (0x5a5a) > 2. status_request > 3. ec_point_formats > 4. supported_groups > 5. signed_certificate_timestamp > 6. application_settings > 7. server_name > 8. application_layer_protocol_negotiation > 9. key_share > 10. extended_master_secret > 11. extensionRenegotiationInfo > 12. session_ticket > 13. supported_versions > 14. signature_algorithms > 15. psk_key_exchange_modes > 16. TLS_GREASE (0x3a3a) > 17. padding > > The reason for me making this post is because when I > add application_settings extension, the module doesn't work for certain > websites such as for google domains and for some it works perfectly fine. I > analysed in Wireshark the requests they were all properly done but for some > weird reason, Java gives back following exceptions once I encounter some > sites it crashes on > > 1. Received fatal alert: decode_error > 2. Unknown handshake type size, Handshake.msg_type = 25 > 3. Received fatal alert: unexpected_message > > > Unfortunately I don't know how to track fatal alerts and their cores so I'm > not sure how I can handle this. Why does Java crash on this simple > extension such as application_settings? It holds nothing but following > > { > "name": "application_settings (17513)", > "protocols": [ > "h2" > ] > } > > > That's pretty much it. Once I remove this extension, the module works > just fine with the rest added ones. I should add on top that i do > these 2 following lines as my ssl configuration prior creating java > client > > sslParams.setApplicationProtocols(new String[] {"h2", "http/1.1"}); > sslParams.setProtocols(new String[]{"TLSv1.3"}); > > Any help would be welcome! Thanks in advance! > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xE4D8E9F997A833DD.asc Type: application/pgp-keys Size: 1197 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From sviswanathan at openjdk.org Thu Aug 31 18:32:02 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 31 Aug 2023 18:32:02 GMT Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests having shared state In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma wrote: > In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems. > > org/openjdk/bench/java/io/DataInputStreamTest.java > org/openjdk/bench/java/lang/ArrayClone.java > org/openjdk/bench/java/lang/StringCompareToDifferentLength.java > org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java > org/openjdk/bench/java/lang/StringComparisons.java > org/openjdk/bench/java/lang/StringEquals.java > org/openjdk/bench/java/lang/StringFormat.java > org/openjdk/bench/java/lang/StringReplace.java > org/openjdk/bench/java/lang/StringSubstring.java > org/openjdk/bench/java/lang/StringTemplateFMT.java > org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java > org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java > org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java > org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java > org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java > org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java > org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java > org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java > org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java > org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java > org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java > org/openjdk/bench/java/security/CipherSuiteBench.java > org/openjdk/bench/java/time/GetYearBench.java > org/openjdk/bench/java/time/InstantBench.java > org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java > org/openjdk/bench/java/util/ListArgs.java > org/openjdk/bench/java/util/LocaleDefaults.java > org/openjdk/bench/java/util/TestAdler32.java > org/openjdk/bench/java/util/TestCRC32.java > org/openjdk/bench/java/util/TestCRC32C.java > org/openjdk/bench/java/util/regex/Exponential.java > org/openjdk/bench/java/util/regex/Primality.java > org/openjdk/bench/java/util/regex/Trim.java > org/openjdk/bench/javax/crypto/AESReinit.java > org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java > org/openjdk/bench/vm/compiler/Rotation.java > org/openjdk/bench/vm/compiler/x86/ConvertF2I.java > org/openjdk/bench/vm/compiler/x86/BasicRules.java > > Please review and provide your feedback. > > Thanks, > Swati Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15230#pullrequestreview-1605442680 From valeriep at openjdk.org Thu Aug 31 20:50:12 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 31 Aug 2023 20:50:12 GMT Subject: Integrated: 8312306: Add more Reference.reachabilityFence() calls to the security classes using Cleaner In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 18:06:59 GMT, Valerie Peng wrote: > This PR updates the various security classes using Cleaner with the try/finally pattern. Also noticed that SunJCE's PBEKey impl class overrides the destroy() method but not the isDestroyed() method, fixed this inconsistency as well. > > Thanks in advance for the review! This pull request has now been integrated. Changeset: 2436fb01 Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/2436fb010e6a11755ee0ba2dbc51a230a2cb2c7f Stats: 238 lines in 6 files changed: 149 ins; 4 del; 85 mod 8312306: Add more Reference.reachabilityFence() calls to the security classes using Cleaner Reviewed-by: ascarpino ------------- PR: https://git.openjdk.org/jdk/pull/15390 From ecki at zusammenkunft.net Thu Aug 31 21:14:59 2023 From: ecki at zusammenkunft.net (Bernd) Date: Thu, 31 Aug 2023 23:14:59 +0200 Subject: Modification of Client hello TLS packet In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From rhalade at openjdk.org Thu Aug 31 21:19:26 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 31 Aug 2023 21:19:26 GMT Subject: RFR: 8313575: Refactor PKCS11Test tests Message-ID: PKCS11Test is updated to remove testDefault and testDeimos. Sun Crypto Accelerator is not supported now and there is no default PKCS11 provider with default JDK configuration. ------------- Commit messages: - 8313575: Refactor PKCS11Test tests Changes: https://git.openjdk.org/jdk/pull/15523/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15523&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313575 Stats: 98 lines in 4 files changed: 0 ins; 94 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15523/head:pull/15523 PR: https://git.openjdk.org/jdk/pull/15523 From jjiang at openjdk.org Thu Aug 31 22:29:48 2023 From: jjiang at openjdk.org (John Jiang) Date: Thu, 31 Aug 2023 22:29:48 GMT Subject: Integrated: JDK-8315422: getSoTimeout() would be in try block in SSLSocketImpl In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 02:34:58 GMT, John Jiang wrote: > The method `SSLSocketImpl::closeSocket` has the below code snippet, > > > if (appInput.readLock.tryLock()) { > int soTimeout = getSoTimeout(); > try { > // deplete could hang on the skip operation > // in case of infinite socket read timeout. > // Change read timeout to avoid deadlock. > // This workaround could be replaced later > // with the right synchronization > if (soTimeout == 0) > setSoTimeout(DEFAULT_SKIP_TIMEOUT); > inputRecord.deplete(false); > } catch (java.net.SocketTimeoutException stEx) { > // skip timeout exception during deplete > } finally { > if (soTimeout == 0) > setSoTimeout(soTimeout); > appInput.readLock.unlock(); > } > } > > > If `getSoTimeout()` throws an exception, say `SocketException`, `appInput.readLock.unlock()` cannot be called. This pull request has now been integrated. Changeset: 2264667b Author: John Jiang URL: https://git.openjdk.org/jdk/commit/2264667bba2311b568257a933813fa76a9e75313 Stats: 19 lines in 1 file changed: 6 ins; 3 del; 10 mod 8315422: getSoTimeout() would be in try block in SSLSocketImpl Reviewed-by: jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/15503 From michael.osipov at siemens.com Wed Aug 9 07:30:15 2023 From: michael.osipov at siemens.com (Osipov, Michael (SMD IT IN)) Date: Wed, 09 Aug 2023 07:30:15 -0000 Subject: KrbException exception does not contain error string although error is well-known Message-ID: <4d81f4c8-d2a1-45c2-898a-a918f5ddc6ba@siemens.com> Folks, Max, consider the following code snippet configured with the Krb5LoginModule: > LoginContext lc = new LoginContext(loginEntryName); > lc.login(); then a LoginException is thrown with the following stacktrace: > 2023-08-01T00:09:31.601 SCHWERWIEGEND [https-openssl-apr-8444-exec-5417] net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal Exception acquiring directory server connection > javax.naming.NamingException: null (29) [Root exception is javax.security.auth.login.LoginException: null (29)] > at net.sf.michaelo.dirctxsrc.DirContextSource.getGssApiDirContext(DirContextSource.java:625) > at net.sf.michaelo.dirctxsrc.DirContextSource.getDirContext(DirContextSource.java:685) > at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.open(ActiveDirectoryRealm.java:572) > at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.acquire(ActiveDirectoryRealm.java:506) > at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:432) > at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:461) > at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:426) > at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:497) > at net.sf.michaelo.tomcat.authenticator.SpnegoAuthenticator.doAuthenticate(SpnegoAuthenticator.java:163) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:564) > ... > at java.lang.Thread.run(Thread.java:750) > Caused by: javax.security.auth.login.LoginException: null (29) > at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:810) > at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) > at sun.reflect.GeneratedMethodAccessor10719.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) > at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) > at javax.security.auth.login.LoginContext.login(LoginContext.java:587) > at net.sf.michaelo.dirctxsrc.DirContextSource.getGssApiDirContext(DirContextSource.java:574) > ... 23 more > Caused by: KrbException: null (29) > at sun.security.krb5.KrbAsRep.(KrbAsRep.java:76) > at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:335) > at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:488) > at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:782) > ... 35 more > Caused by: KrbException: Identifier doesn't match expected value (906) > at sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) > at sun.security.krb5.internal.ASRep.init(ASRep.java:64) > at sun.security.krb5.internal.ASRep.(ASRep.java:59) > at sun.security.krb5.KrbAsRep.(KrbAsRep.java:60) > ... 38 more I am trying to obtain a TGT to authenticate thorugh SASL GSSAPI to Active Directory via LDAP. This happened to me now repeatedly in the last couple of days around midnight. Looking up error code 29 says KDC_ERR_SVC_UNAVAILABLE, obviously the AD DC server is maintenance mode. What bugs me is that KDC_ERR_SVC_UNAVAILABLE(29) is documented in Krb5.java, has an error message and KrbException.java does use it, but no error message is mapped to the code. Request: Maybe someone (Max?) log an improvement request with JBS to add missing error codes 26--28, 51 from [1] and > public static final int KRB_AP_ERR_NOREALM = 62; > public static final int KRB_AP_ERR_GEN_CRED = 63; look incorrect. Plus the mapping in errMsgList for those. Note: Tried with OpenJDK 8. Best regards, Michael [1] https://www.rfc-editor.org/rfc/rfc4120#section-7.5.9 From chen.j.patrick at gmail.com Wed Aug 9 07:32:39 2023 From: chen.j.patrick at gmail.com (Patrick Chen) Date: Wed, 09 Aug 2023 07:32:39 -0000 Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: Relax take it ezzzzzzzsy Le mer. 9 ao?t 2023, 08:57, David Holmes a ?crit : > On Tue, 8 Aug 2023 19:52:08 GMT, Thomas Stuefe wrote: > > >> I just checked and the value of the sentinel is ultimately the prvalue > 88. I don't know if we'd want to replace all the weird char usages here > with explicit values of 0 (and 88 for the sentinel). Maybe future reviews > can help with that > > > > I wrote this code ages ago. I'm not sure what's weird or suspicious > about it, though. The comment at the file's beginning explains this code's > motivation. > > > > The buffer was never thought to be used for something different than > HANDLEs or characters, where the assignment of integer literals work. I > often use char constants for sentinels as debugging aid. As for `'\0'`, > that indicates to the casual code reader that this is a termination of a > string, better than had I used a plain 0. > > Because there is nothing to state what T may be, I found assigning > character literals to be odd. If T is char and the buffer is meant to be a > C string then it makes more sense. But for non-char T it just raised > questions for me. > > ------------- > > PR Review Comment: > https://git.openjdk.org/jdk/pull/15096#discussion_r1288029698 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.j.patrick at gmail.com Wed Aug 9 08:20:15 2023 From: chen.j.patrick at gmail.com (Patrick Chen) Date: Wed, 09 Aug 2023 08:20:15 -0000 Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: Can you shut the f Le mer. 9 ao?t 2023, 10:10, Thomas Stuefe a ?crit : > On Wed, 9 Aug 2023 06:53:49 GMT, David Holmes wrote: > > >> I wrote this code ages ago. I'm not sure what's weird or suspicious > about it, though. The comment at the file's beginning explains this code's > motivation. > >> > >> The buffer was never thought to be used for something different than > HANDLEs or characters, where the assignment of integer literals work. I > often use char constants for sentinels as debugging aid. As for `'\0'`, > that indicates to the casual code reader that this is a termination of a > string, better than had I used a plain 0. > > > > Because there is nothing to state what T may be, I found assigning > character literals to be odd. If T is char and the buffer is meant to be a > C string then it makes more sense. But for non-char T it just raised > questions for me. > > I see that. We can remove the sentinel stuff, which leaves us with the > zero termination. Arguably, this could be done by sub classes that derive > from the char instantiation. > > ------------- > > PR Review Comment: > https://git.openjdk.org/jdk/pull/15096#discussion_r1288083649 > -------------- next part -------------- An HTML attachment was scrubbed... URL: