From anthony.scarpino at oracle.com Mon Jul 3 15:28:29 2023 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 3 Jul 2023 08:28:29 -0700 Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: <2c1ddf91-4c0c-537d-90f9-160988ce2d27@zeus.net.au> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> <2c1ddf91-4c0c-537d-90f9-160988ce2d27@zeus.net.au> Message-ID: On 6/30/23 4:26 AM, Peter Firmstone wrote: > > On 17/06/2023 11:13 pm, Alan Bateman wrote: >> On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino >> wrote: >> >>> This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC >>> has always been separate from the base module/pkg because of its >>> dependence on a native library. That library was removed in JDK 16. >> The proposed changes look okay, meaning it should be okay to have the >> SunEC provider in java.base. However, the motivation isn't clear as >> there isn't an issue with JCE providers in java.base using native >> code. I know there were non-technical issues with libsunec in the past >> but that would haven't prevent the SunEC code form being compiled into >> java.base. >> >> I assume the main implications of the change is that 3rd party JCE >> providers signed with an EC certificate can now be deployed on the >> module path.? Another way to solve that issue is that delay >> verification of signed JARs until the boot layer is created - if we >> did that, would you still want to move the SunEC provider into java.base? > > > Curious, the provider mechanism provides a level of indirection, aka > service, a boundary or separation.? How are module boundaries defined? > > Regards, > > Peter. With JCE, there is not specific boundary definition to modules. I was a case-by-case basis at the time the provider was integrated. Tony From mullan at openjdk.org Mon Jul 3 16:06:58 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 3 Jul 2023 16:06:58 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. The changes in the security classes look fine to me. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1511468933 From mullan at openjdk.org Mon Jul 3 16:11:02 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 3 Jul 2023 16:11:02 GMT Subject: [jdk21] RFR: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 18:37:57 GMT, Rajan Halade wrote: > This test update should be included in JDK 21 LTS release. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/71#pullrequestreview-1511474824 From ascarpino at openjdk.org Mon Jul 3 17:51:10 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 3 Jul 2023 17:51:10 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v3] In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: > Hi, > > I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. > > There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: return non volatile variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14457/files - new: https://git.openjdk.org/jdk/pull/14457/files/32b4cee1..cf8e954d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14457.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14457/head:pull/14457 PR: https://git.openjdk.org/jdk/pull/14457 From duke at openjdk.org Mon Jul 3 19:44:12 2023 From: duke at openjdk.org (Glavo) Date: Mon, 3 Jul 2023 19:44:12 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v5] In-Reply-To: References: Message-ID: > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'openjdk:master' into latin1-no-repl - Merge branch 'openjdk:master' into latin1-no-repl - Merge branch 'openjdk:master' into latin1-no-repl - update javadoc - clean newStringNoRepl1 - clean newStringNoRepl1 - Rename jla to JLA - Create new method JavaLangAccess::newStringLatin1NoRepl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14655/files - new: https://git.openjdk.org/jdk/pull/14655/files/512029d7..76498a5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=03-04 Stats: 7482 lines in 474 files changed: 4398 ins; 1064 del; 2020 mod Patch: https://git.openjdk.org/jdk/pull/14655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655 PR: https://git.openjdk.org/jdk/pull/14655 From duke at openjdk.org Mon Jul 3 19:46:38 2023 From: duke at openjdk.org (Glavo) Date: Mon, 3 Jul 2023 19:46:38 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v6] In-Reply-To: References: Message-ID: <7mAWi6eB57x0f0zs0fkVQ02POF5H05Dj3Jvw1QPa1IY=.1fa0133d-2a24-437e-b2a6-66cdf1ca0985@github.com> > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. Glavo has updated the pull request incrementally with one additional commit since the last revision: Use newStringLatin1NoRepl in UUID ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14655/files - new: https://git.openjdk.org/jdk/pull/14655/files/76498a5b..96788ddd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=04-05 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655 PR: https://git.openjdk.org/jdk/pull/14655 From valeriep at openjdk.org Tue Jul 4 00:51:10 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 4 Jul 2023 00:51:10 GMT Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v3] In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> Message-ID: On Mon, 3 Jul 2023 17:51:10 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a code review for moving the contents of the jdk.crypto.ec module into java.base. This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release. >> >> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes . Applications that unwisely accessing internal EC classes will need to use the java.base module. >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > return non volatile variable Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14457#pullrequestreview-1511888440 From clanger at openjdk.org Tue Jul 4 07:34:03 2023 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 4 Jul 2023 07:34:03 GMT Subject: [jdk21] RFR: 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns In-Reply-To: <5ji-LHKwHTkaSJkjD3ps6IBW2JqUvfmsmK4nWOfN1-U=.7dbfdd42-9e24-4260-b34f-ff631859a8b7@github.com> References: <5ji-LHKwHTkaSJkjD3ps6IBW2JqUvfmsmK4nWOfN1-U=.7dbfdd42-9e24-4260-b34f-ff631859a8b7@github.com> Message-ID: <5VvP5W0mLP27cSO_NN_Gd0WMUKYQ7K79NKP6UpVlJWs=.5b49b5dc-55d9-47e1-9f4f-7d0740b62226@github.com> On Fri, 30 Jun 2023 12:28:43 GMT, Matthias Baesken wrote: > 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/86#pullrequestreview-1512250194 From mbaesken at openjdk.org Tue Jul 4 07:46:06 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Jul 2023 07:46:06 GMT Subject: [jdk21] Integrated: 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns In-Reply-To: <5ji-LHKwHTkaSJkjD3ps6IBW2JqUvfmsmK4nWOfN1-U=.7dbfdd42-9e24-4260-b34f-ff631859a8b7@github.com> References: <5ji-LHKwHTkaSJkjD3ps6IBW2JqUvfmsmK4nWOfN1-U=.7dbfdd42-9e24-4260-b34f-ff631859a8b7@github.com> Message-ID: On Fri, 30 Jun 2023 12:28:43 GMT, Matthias Baesken wrote: > 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns This pull request has now been integrated. Changeset: 8d6ef6fd Author: Matthias Baesken URL: https://git.openjdk.org/jdk21/commit/8d6ef6fd5bedadee4afac66f3bd3b9213e72d5f5 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns Reviewed-by: clanger Backport-of: 7da3f1999fc5d1b9162443d97dfae7fe7b04dfc5 ------------- PR: https://git.openjdk.org/jdk21/pull/86 From peter.firmstone at zeus.net.au Tue Jul 4 10:23:40 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 4 Jul 2023 20:23:40 +1000 Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> <2c1ddf91-4c0c-537d-90f9-160988ce2d27@zeus.net.au> Message-ID: Thanks Anthony, Always interesting to see how others are managing modularity. Some time ago now (circa 2007), Sun released Jini as open source, set up a project at Apache called River, we struggled to get developers though, we had a big monolithic codebase and developers couldn't get their heads around it.?? When I was modularising it, I decided to use SPI's as module boundaries, it turned out to be a good decision, we ended up making all our SPI's OSGi services as well.?? Probably doesn't matter in this instance, OpenJDK is already modular, and it's implementation detail.?? Some of our crypto providers are in the same module, but I'm thinking of separating them into different modules now, as some are no longer secure, but some people may still need them for compatibility, by moving old code into different modules, we can allow to die a peaceful death, without requiring people who don't use it to be burdened by it. -- Regards, Peter On 4/07/2023 1:28 am, Anthony Scarpino wrote: > > > On 6/30/23 4:26 AM, Peter Firmstone wrote: >> >> On 17/06/2023 11:13 pm, Alan Bateman wrote: >>> On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino >>> wrote: >>> >>>> This moves the SunEC JCE Provider (Elliptic Curve) into java.base. >>>> EC has always been separate from the base module/pkg because of its >>>> dependence on a native library. That library was removed in JDK 16. >>> The proposed changes look okay, meaning it should be okay to have >>> the SunEC provider in java.base. However, the motivation isn't clear >>> as there isn't an issue with JCE providers in java.base using native >>> code. I know there were non-technical issues with libsunec in the >>> past but that would haven't prevent the SunEC code form being >>> compiled into java.base. >>> >>> I assume the main implications of the change is that 3rd party JCE >>> providers signed with an EC certificate can now be deployed on the >>> module path.? Another way to solve that issue is that delay >>> verification of signed JARs until the boot layer is created - if we >>> did that, would you still want to move the SunEC provider into >>> java.base? >> >> >> Curious, the provider mechanism provides a level of indirection, aka >> service, a boundary or separation.? How are module boundaries defined? >> >> Regards, >> >> Peter. > > With JCE, there is not specific boundary definition to modules.? I was > a case-by-case basis at the time the provider was integrated. > > Tony > > From prappo at openjdk.org Tue Jul 4 16:27:05 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 4 Jul 2023 16:27:05 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v3] 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: <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> > Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in security area. > > I understand that security area is sensitive and a non-expert, such as myself, should tread carefully; so below are my notes to assist the review. > > * Unlike `hashCode`, non-secure `equals` implementations are typically short-circuit. But because of "timing attacks", we seem to have specialized implementations, such as `java.security.MessageDigest.isEqual(byte[], byte[])` and a more general `sun.security.util.ByteArrays.isEqual(byte[], int, int, byte[], int, int)`. So while reviewing this PR, take an opportunity to audit the affected `equals` implementations: perhaps some of them need to become secure, not modern. I have no domain knowledge to tell those cases apart, I only note that those cases exist. > > * This PR sacrifices compatibility for pragmatism: it changes some `hashCode` implementations to produce different values than before to allow more utilization of methods from `Objects` and `Arrays`. To my mind, those changes are **benign**. If you disagree, I'd be happy to discuss that and/or retract the concerning part of the change. > > * BitArray could be a topic of its own, but I'll do my best to be concise. > > * Truth to be told, BitArray's `equals` and `hashCode` are not used anywhere in source, and `equals` is only used in one test. For that reason, I refrained from reimplementing internals of `BitArray` using more general `java.util.BitSet`: too much effort and risk for almost nothing. > * Speaking of `BitSet`-powered `BitArray`. Such an implementation is not for the faint of heart: there's too much impedance mismatch between data structures that those classes use to store bits. That said, for the sake of testing that it is possible and that I understand the `BitArray` correctly, I actually implemented it using `BitSet`. While that implementation is **NOT** part of this PR, you can have a look at it [here](https://cr.openjdk.org/~prappo/8311170/BitArray.java). > > * One suggestion to consider is to change this somewhat arcane piece in java.security.UnresolvedPermission.equals: > > // check certs > if (this.certs == null && that.certs != null || > this.certs != null && that.certs == null || > this.certs != null && > this.certs.length != that.certs.length) { > return false; > } > > int i,j; > boolean match; > > for (i = 0; this.certs != nu... Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Add even more cases and tidy up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/0727c264..c0c75c87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=01-02 Stats: 116 lines in 16 files changed: 17 ins; 43 del; 56 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 Jul 4 19:07:13 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 4 Jul 2023 19:07:13 GMT Subject: Integrated: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. This pull request has now been integrated. Changeset: 7b3c2dc5 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5 Stats: 23 lines in 13 files changed: 0 ins; 0 del; 23 mod 8311122: Fix typos in java.base Reviewed-by: darcy, naoto, mchung, iris, mli, mullan ------------- PR: https://git.openjdk.org/jdk/pull/14718 From prappo at openjdk.org Tue Jul 4 19:07:11 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 4 Jul 2023 19:07:11 GMT Subject: RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. Alright, I think all the areas that this PR touches have been reviewed by area experts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14718#issuecomment-1620628939 From prappo at openjdk.org Tue Jul 4 19:13:20 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 4 Jul 2023 19:13:20 GMT Subject: [jdk21] RFR: 8311122: Fix typos in java.base Message-ID: Hi all, This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Pavel Rappo on 4 Jul 2023 and was reviewed by Joe Darcy, Naoto Sato, Mandy Chung, Iris Clark, Hamlin Li and Sean Mullan. Thanks! ------------- Commit messages: - Backport 7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5 Changes: https://git.openjdk.org/jdk21/pull/94/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=94&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311122 Stats: 23 lines in 13 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk21/pull/94.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/94/head:pull/94 PR: https://git.openjdk.org/jdk21/pull/94 From prappo at openjdk.org Tue Jul 4 19:16:03 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 4 Jul 2023 19:16:03 GMT Subject: [jdk21] RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: <62_fhK8uOuKoer-B-6-CA5tbSGNiMJaEJwIUXP-VGrU=.f064e582-d6f3-4596-a367-8a4a85923ba4@github.com> On Tue, 4 Jul 2023 19:05:58 GMT, Pavel Rappo wrote: > Hi all, > > This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Pavel Rappo on 4 Jul 2023 and was reviewed by Joe Darcy, Naoto Sato, Mandy Chung, Iris Clark, Hamlin Li and Sean Mullan. > > Thanks! This PR is as close to noreg-doc as one can get. The only reason it should be backported to jdk21 is a typo in an error message here: https://github.com/openjdk/jdk21/blob/c9111d57ce132d70d4360535254658ef6b8d134d/src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java#L373 ------------- PR Comment: https://git.openjdk.org/jdk21/pull/94#issuecomment-1620635386 From iris at openjdk.org Tue Jul 4 23:32:59 2023 From: iris at openjdk.org (Iris Clark) Date: Tue, 4 Jul 2023 23:32:59 GMT Subject: [jdk21] RFR: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 19:05:58 GMT, Pavel Rappo wrote: > Hi all, > > This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Pavel Rappo on 4 Jul 2023 and was reviewed by Joe Darcy, Naoto Sato, Mandy Chung, Iris Clark, Hamlin Li and Sean Mullan. > > Thanks! Appears identical to change in 22, as expected. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk21/pull/94#pullrequestreview-1513478430 From djelinski at openjdk.org Wed Jul 5 12:14:55 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 5 Jul 2023 12:14:55 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v3] In-Reply-To: <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> Message-ID: <9zjRCaz5vT3_u34XeNA5pOA4yZB8qsvKDy8cWq3fad4=.cbfc2738-87b9-4cc9-ab5a-09ff8cf55713@github.com> On Tue, 4 Jul 2023 16:27:05 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: > > Add even more cases and tidy up src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 639: > 637: return false; > 638: > 639: if (Objects.equals(this.cryptoPermission, that.cryptoPermission)) { Suggestion: if (!Objects.equals(this.cryptoPermission, that.cryptoPermission)) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253015972 From djelinski at openjdk.org Wed Jul 5 12:18:56 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 5 Jul 2023 12:18:56 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v3] In-Reply-To: <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> Message-ID: On Tue, 4 Jul 2023 16:27:05 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: > > Add even more cases and tidy up src/java.base/share/classes/sun/security/provider/PolicyParser.java line 1133: > 1131: && Objects.equals(this.permission, that.permission) > 1132: && Objects.equals(this.name, that.name) > 1133: && Objects.equals(this.signedBy, that.signedBy); The original code also compared `action` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253020587 From djelinski at openjdk.org Wed Jul 5 12:33:56 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 5 Jul 2023 12:33:56 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v3] In-Reply-To: <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> Message-ID: <4Z6QENlIxOzMthECRf_UcqZHRmXbEwMZ7LFK-Sf_m9Y=.d0c24427-62c1-45e4-b412-96f163455a4c@github.com> On Tue, 4 Jul 2023 16:27:05 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: > > Add even more cases and tidy up src/java.base/share/classes/java/security/spec/ECFieldF2m.java line 235: > 233: public int hashCode() { > 234: int value = m << 5; > 235: // consider simplifying using Objects.hashCode(rp) after JDK-8015417 Could you explain this comment? Why does it apply here, and not to other methods like CodeSigner.hashCode? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253038416 From prappo at openjdk.org Wed Jul 5 14:43:57 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 5 Jul 2023 14:43:57 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v3] In-Reply-To: <4Z6QENlIxOzMthECRf_UcqZHRmXbEwMZ7LFK-Sf_m9Y=.d0c24427-62c1-45e4-b412-96f163455a4c@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> <4Z6QENlIxOzMthECRf_UcqZHRmXbEwMZ7LFK-Sf_m9Y=.d0c24427-62c1-45e4-b412-96f163455a4c@github.com> Message-ID: On Wed, 5 Jul 2023 12:31:09 GMT, Daniel Jeli?ski wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Add even more cases and tidy up > > src/java.base/share/classes/java/security/spec/ECFieldF2m.java line 235: > >> 233: public int hashCode() { >> 234: int value = m << 5; >> 235: // consider simplifying using Objects.hashCode(rp) after JDK-8015417 > > Could you explain this comment? Why does it apply here, and not to other methods like CodeSigner.hashCode? You are absolutely right: adding that comment, while actively disregarding concerns described in it elsewhere, warrants some explanation. While working on this and the related PRs, I discovered JDK-8015417. hashCode and, to a lesser extent, equals in ECFieldF2m seemed lean and performance-sensitive so as to apply the smarts of JDK-8015417. Frankly, performance sensitivity was my guess; anyway, I kept the original behaviour for that site. Since then, I learned that JDK-8015417 is quite complicated and well beyond my level of understanding of how JVM works. Until I have clearer understanding of the effects of that issue on this and similar refactoring efforts, I won't integrate this or any other PRs where using the java.util.Objects static methods is a primary goal. That said, I'll remove the comment and refactor that `?:` conditional to use `Objects.equals(Object, Object)`, to be consistent with the rest of this PR. FWIW, we've accidentally started discussion on those effects in another PR: https://github.com/openjdk/jdk/pull/14752#pullrequestreview-1511190453. It might as well have been this PR, but that PR was first. While either PR is good, let's keep it confined and organized. So, please follow that discussion, if you're interested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253214761 From prappo at openjdk.org Wed Jul 5 14:52:25 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 5 Jul 2023 14:52:25 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v3] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> <4Z6QENlIxOzMthECRf_UcqZHRmXbEwMZ7LFK-Sf_m9Y=.d0c24427-62c1-45e4-b412-96f163455a4c@github.com> Message-ID: On Wed, 5 Jul 2023 14:39:44 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/security/spec/ECFieldF2m.java line 235: >> >>> 233: public int hashCode() { >>> 234: int value = m << 5; >>> 235: // consider simplifying using Objects.hashCode(rp) after JDK-8015417 >> >> Could you explain this comment? Why does it apply here, and not to other methods like CodeSigner.hashCode? > > You are absolutely right: adding that comment, while actively disregarding concerns described in it elsewhere, warrants some explanation. > > While working on this and the related PRs, I discovered JDK-8015417. hashCode and, to a lesser extent, equals in ECFieldF2m seemed lean and performance-sensitive so as to apply the smarts of JDK-8015417. Frankly, performance sensitivity was my guess; anyway, I kept the original behaviour for that site. > > Since then, I learned that JDK-8015417 is quite complicated and well beyond my level of understanding of how JVM works. Until I have clearer understanding of the effects of that issue on this and similar refactoring efforts, I won't integrate this or any other PRs where using the java.util.Objects static methods is a primary goal. > > That said, I'll remove the comment and refactor that `?:` conditional to use `Objects.hashCode(Object)`, to be consistent with the rest of this PR. > > FWIW, we've accidentally started discussion on those effects in another PR: https://github.com/openjdk/jdk/pull/14752#pullrequestreview-1511190453. It might as well have been this PR, but that PR was first. While either PR is good, let's keep it confined and organized. So, please follow that discussion, if you're interested. Refactored in 3f316b49f26. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253222537 From prappo at openjdk.org Wed Jul 5 14:52:22 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 5 Jul 2023 14:52:22 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into 8311170 - Be consistent with the rest of the change - Fix reported bugs - Add even more cases and tidy up - More cases - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/c0c75c87..cb6e1776 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=02-03 Stats: 2254 lines in 210 files changed: 1031 ins; 456 del; 767 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 Wed Jul 5 14:52:26 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 5 Jul 2023 14:52:26 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v3] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_mvkx_d0KLo2ph6c32l7l9sy5umxAvQ9uv-1MkXR5aM=.8481c89d-3405-499d-9308-3d725664db09@github.com> Message-ID: <77hM1YWfeLEtFRax0Fn-k1RRk3rnfNLL_wL4a5ECa4E=.f1904891-f2d5-4da2-9cae-ee951cce3f9c@github.com> On Wed, 5 Jul 2023 12:16:32 GMT, Daniel Jeli?ski wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Add even more cases and tidy up > > src/java.base/share/classes/sun/security/provider/PolicyParser.java line 1133: > >> 1131: && Objects.equals(this.permission, that.permission) >> 1132: && Objects.equals(this.name, that.name) >> 1133: && Objects.equals(this.signedBy, that.signedBy); > > The original code also compared `action` Good catch; thanks! I have fixed this and the other bug you commented on in ca0d43a34ad. What's unpleasant is that tiers 1 and 2 didn't catch those bugs. One useful but separate from this PR exercise would be to gather code coverage for those tiers to see where we can improve our testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253221129 From djelinski at openjdk.org Wed Jul 5 15:20:55 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 5 Jul 2023 15:20:55 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Wed, 5 Jul 2023 14:52:22 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into 8311170 > - Be consistent with the rest of the change > - Fix reported bugs > - Add even more cases and tidy up > - More cases > - Initial commit Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14738#pullrequestreview-1514778691 From rhalade at openjdk.org Wed Jul 5 17:50:21 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 5 Jul 2023 17:50:21 GMT Subject: [jdk21] Integrated: 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 18:37:57 GMT, Rajan Halade wrote: > This test update should be included in JDK 21 LTS release. This pull request has now been integrated. Changeset: 604e03de Author: Rajan Halade URL: https://git.openjdk.org/jdk21/commit/604e03de78a0ed4f687ee2cd95b0d409b4c3736a Stats: 311 lines in 2 files changed: 179 ins; 51 del; 81 mod 8301379: Verify TLS_ECDH_* cipher suites cannot be negotiated Reviewed-by: mullan Backport-of: 9f64a64376c677dbe1358807329b42737ac78ad9 ------------- PR: https://git.openjdk.org/jdk21/pull/71 From rriggs at openjdk.org Wed Jul 5 18:21:03 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Jul 2023 18:21:03 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> On Wed, 5 Jul 2023 14:52:22 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into 8311170 > - Be consistent with the rest of the change > - Fix reported bugs > - Add even more cases and tidy up > - More cases > - Initial commit src/java.base/share/classes/java/security/cert/X509CRLEntry.java line 110: > 108: public int hashCode() { > 109: try { > 110: return Arrays.hashCode(this.getEncoded()); What data is at `entryData[0]` that will now be included in the hashCode when it was skipped before? src/java.base/share/classes/javax/security/cert/Certificate.java line 107: > 105: try { > 106: return Arrays.hashCode(this.getEncoded()); > 107: } catch (CertificateException e) { Ditto, what value at `certData[0]` is now included in the hash? src/java.base/share/classes/sun/security/util/BitArray.java line 72: > 70: * specified byte array. The most significant bit of {@code a[0]} gets > 71: * index zero in the BitArray. The array must be large enough to specify > 72: * a value for every bit of the BitArray, i.e. {@code 8*a.length >= length}. The original `<=` was correct, the number of bits in the input array must be less than the requested length of the BitArray. The constructors also describe the length using `<=`; they all should be consistent. src/java.base/share/classes/sun/security/x509/X500Name.java line 422: > 420: // quick check that number of RDNs and AVAs match before canonicalizing > 421: if (!Arrays.equals(this.names, other.names, > 422: Comparator.comparingInt(n -> n.assertion.length))) I'd keep the original comparison of the lengths; its a lot less magical than `Comparator.comparingInt(n -> n.assertion.length))` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253446806 PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253456172 PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253462853 PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253469604 From djelinski at openjdk.org Wed Jul 5 19:37:54 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 5 Jul 2023 19:37:54 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> Message-ID: On Wed, 5 Jul 2023 18:11:41 GMT, Roger Riggs wrote: >> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8311170 >> - Be consistent with the rest of the change >> - Fix reported bugs >> - Add even more cases and tidy up >> - More cases >> - Initial commit > > src/java.base/share/classes/sun/security/util/BitArray.java line 72: > >> 70: * specified byte array. The most significant bit of {@code a[0]} gets >> 71: * index zero in the BitArray. The array must be large enough to specify >> 72: * a value for every bit of the BitArray, i.e. {@code 8*a.length >= length}. > > The original `<=` was correct, the number of bits in the input array must be less than the requested length of the BitArray. The constructors also describe the length using `<=`; they all should be consistent. Are you sure? I just checked lines 91-92 and I'd say the change looks correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253548582 From rhalade at openjdk.org Wed Jul 5 19:57:51 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 5 Jul 2023 19:57:51 GMT Subject: RFR: 8156889: ListKeychainStore.sh fails in some virtualized environments In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 18:15:48 GMT, Rajan Halade wrote: > This fix converted shell test to java code. Following are the updates done to the original shell test logic: > > - Test is updated to be a manual test as it is rather difficult/impossible to have it run in virtualized environment where we can't update the security keychain search list to include created keychain. > - Test is updated to save earlier keychain search order and restore when test ends. > - Test is now using legacy encryption and MAC algorithms, refer macOS open radar FB8988319, as macOS security framework doesn't work with the latest algorithms. Algorithms were updated with JDK-8153005. Can someone please review this test update? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14424#issuecomment-1622404154 From prappo at openjdk.org Wed Jul 5 20:43:56 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 5 Jul 2023 20:43:56 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> Message-ID: On Wed, 5 Jul 2023 18:04:01 GMT, Roger Riggs wrote: >> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8311170 >> - Be consistent with the rest of the change >> - Fix reported bugs >> - Add even more cases and tidy up >> - More cases >> - Initial commit > > src/java.base/share/classes/javax/security/cert/Certificate.java line 107: > >> 105: try { >> 106: return Arrays.hashCode(this.getEncoded()); >> 107: } catch (CertificateException e) { > > Ditto, what value at `certData[0]` is now included in the hash? Those are correct observations. Unspecified hashCode methods changed in this proposal might return different values than the ones they currently return in the mainline; hence my disclaimer in this PR description: > 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. I'm waiting from someone from security-dev to tell me if that's okay to skip zeroth elements in both hashCode. It might've been an accidental skip in the first place. FWIW, their `equals` counterparts do not skip zeroth elements. On the other hand, javax.security.cert.Certificate is deprecated for removal, so I might as well exclude it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253622642 From prappo at openjdk.org Wed Jul 5 20:55:54 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 5 Jul 2023 20:55:54 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> Message-ID: On Wed, 5 Jul 2023 19:35:23 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/util/BitArray.java line 72: >> >>> 70: * specified byte array. The most significant bit of {@code a[0]} gets >>> 71: * index zero in the BitArray. The array must be large enough to specify >>> 72: * a value for every bit of the BitArray, i.e. {@code 8*a.length >= length}. >> >> The original `<=` was correct, the number of bits in the input array must be less than the requested length of the BitArray. The constructors also describe the length using `<=`; they all should be consistent. > > Are you sure? I just checked lines 91-92 and I'd say the change looks correct. > The original `<=` was correct, the number of bits in the input array must be less than the requested length of the BitArray. The constructors also describe the length using `<=`; they all should be consistent. Hm... My reading is that those "i.e." parts state preconditions for the constructors to return successfully, not preconditions for them to throw an exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253635237 From rriggs at openjdk.org Wed Jul 5 21:14:55 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Jul 2023 21:14:55 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com>

Message-ID: On Wed, 5 Jul 2023 20:52:56 GMT, Pavel Rappo wrote: >> Are you sure? I just checked lines 91-92 and I'd say the change looks correct. > >> The original `<=` was correct, the number of bits in the input array must be less than the requested length of the BitArray. The constructors also describe the length using `<=`; they all should be consistent. > > Hm... My reading is that those "i.e." parts state preconditions for the constructors to return successfully, not preconditions for them to throw an exception. I stand corrected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253655028 From aturbanov at openjdk.org Thu Jul 6 06:26:54 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 6 Jul 2023 06:26:54 GMT Subject: RFR: 8295068: SSLEngine throws NPE parsing CertificateRequests In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 20:25:26 GMT, Kevin Driver wrote: > JDK-8295068: an NPE is thrown when an invalid `id` is found to match up a `ClientCertificateType`; rather than throwing the `NPE`, we now throw an `IllegalArgumentException`. This does not seem to be a scenario where recovery is possible or desired, so the `IAE` should be the proper behavior. src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 131: > 129: for (byte id : ids) { > 130: ClientCertificateType cct = ClientCertificateType.valueOf(id); > 131: if(cct == null) { Suggestion: if (cct == null) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14778#discussion_r1253989234 From xuelei at openjdk.org Thu Jul 6 07:08:54 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 6 Jul 2023 07:08:54 GMT Subject: RFR: 8295068: SSLEngine throws NPE parsing CertificateRequests In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 20:25:26 GMT, Kevin Driver wrote: > JDK-8295068: an NPE is thrown when an invalid `id` is found to match up a `ClientCertificateType`; rather than throwing the `NPE`, we now throw an `IllegalArgumentException`. This does not seem to be a scenario where recovery is possible or desired, so the `IAE` should be the proper behavior. Changes requested by xuelei (Reviewer). src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 134: > 132: throw new IllegalArgumentException(id + " was " + > 133: "not a valid ClientCertificateType id"); > 134: } It may not comply to TLS specification if throwing exception here. Unknown types should be ignored for compatibility. - if (cct.isAvailable) { + if (cct != null && cct.isAvailable) { ------------- PR Review: https://git.openjdk.org/jdk/pull/14778#pullrequestreview-1515892219 PR Review Comment: https://git.openjdk.org/jdk/pull/14778#discussion_r1254023615 From prappo at openjdk.org Thu Jul 6 10:46:56 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 6 Jul 2023 10:46:56 GMT Subject: [jdk21] Integrated: 8311122: Fix typos in java.base In-Reply-To: References: Message-ID: <4upquGoBx6qmILTd-DmE9YQ3ZCqMQYTV-LKZBOMBL80=.901bb792-f564-4f30-80b6-a8591ceecead@github.com> On Tue, 4 Jul 2023 19:05:58 GMT, Pavel Rappo wrote: > Hi all, > > This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Pavel Rappo on 4 Jul 2023 and was reviewed by Joe Darcy, Naoto Sato, Mandy Chung, Iris Clark, Hamlin Li and Sean Mullan. > > Thanks! This pull request has now been integrated. Changeset: bfed32bd Author: Pavel Rappo URL: https://git.openjdk.org/jdk21/commit/bfed32bd092751f2dca1d1b546ed078f0e45574b Stats: 23 lines in 13 files changed: 0 ins; 0 del; 23 mod 8311122: Fix typos in java.base Reviewed-by: iris Backport-of: 7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5 ------------- PR: https://git.openjdk.org/jdk21/pull/94 From cslucas at openjdk.org Thu Jul 6 13:06:30 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 6 Jul 2023 13:06:30 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v21] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'openjdk:master' into rematerialization-of-merges - Addressing PR feedback. - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Merge branch 'openjdk:master' into rematerialization-of-merges - Rome minor refactorings. - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges Catching up with master. - Address PR review 6: debug format output & some refactoring. - Catching up with master branch. Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address PR review 6: refactoring around rematerialization & improve test cases. - Address PR review 5: refactor on rematerialization & add tests. - ... and 12 more: https://git.openjdk.org/jdk/compare/97e99f01...25b683d6 ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=20 Stats: 2733 lines in 26 files changed: 2485 ins; 108 del; 140 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From cslucas at openjdk.org Thu Jul 6 13:06:30 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 6 Jul 2023 13:06:30 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v18] In-Reply-To: <72OcyhmFKGyTwDy8LQ0blp5HG5dg5l9OsU5dh9osVxo=.73b3a79e-ff24-4f41-b39b-650a9036ee76@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>

<-A7bd8C0q5o1WuRSeSkYYnUoApV4s9uijPmiNB2Wteo=.c5bc944c-88a3-4228-bd41-091ac6c8fb1d@github.com> <72OcyhmFKGyTwDy8LQ0blp5HG5dg5l9OsU5dh9osVxo=.73b3a79e-ff24-4f41-b39b-650a9036ee76@github.com> Message-ID: <1gB4pzC79wZ9fs7t5eWE4yTlyYkz4oK1K36wc7MWgBo=.cc02b3a7-3b4d-4909-8013-746008f50058@github.com> On Tue, 20 Jun 2023 16:44:28 GMT, Vladimir Ivanov wrote: >> Thank you once more for the comments @iwanowww . I?ll address them asap. >> >> Can I ask what requirements are there for a product flag? > >> Can I ask what requirements are there for a product flag? > > Product flags are treated as part of public API of the JVM. So, changes in behavior have to go through CSR process. Also, a product flag has to be deprecated/obsoleted first before it can be removed which takes multiple releases to happen. Better to avoid introducing new product flags unless it is well-justified or necessary. @iwanowww - I believe I've addressed all your comments so far. Is everything still looking good? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1623641674 From mullan at openjdk.org Thu Jul 6 14:06:02 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 6 Jul 2023 14:06:02 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: References:

Message-ID: On Thu, 6 Jul 2023 07:05:46 GMT, Xue-Lei Andrew Fan wrote: >> JDK-8295068: an NPE is thrown when an invalid `id` is found to match up a `ClientCertificateType`; rather than throwing the `NPE`, we now throw an `IllegalArgumentException`. This does not seem to be a scenario where recovery is possible or desired, so the `IAE` should be the proper behavior. > > src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 134: > >> 132: throw new IllegalArgumentException(id + " was " + >> 133: "not a valid ClientCertificateType id"); >> 134: } > > It may not comply to TLS specification if throwing exception here. Unknown types should be ignored for compatibility. > > - if (cct.isAvailable) { > + if (cct != null && cct.isAvailable) { @XueleiFan It looks like the relevant bit of the RFC (as you point out) is this: For historical reasons, the names of some client certificate types include the algorithm used to sign the certificate. For example, in earlier versions of TLS, rsa_fixed_dh meant a certificate signed with RSA and containing a static DH key. In TLS 1.2, this functionality has been obsoleted by the supported_signature_algorithms, and the certificate type no longer restricts the algorithm used to sign the certificate. For example, if the server sends dss_fixed_dh certificate type and {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply with a certificate containing a static DH key, signed with RSA- SHA1. I had noticed the comments beginning on line 757 in CertificateRequest: // For TLS 1.2, we no longer use the certificate_types field // from the CertificateRequest message to directly determine // the SSLPossession. Instead, the choosePossession method // will use the accepted signature schemes in the message to // determine the set of acceptable certificate types to select from. I noted that the id byte generated by the test case was 0x72, and this is definitely not a recognized/supported type in JSSE ["Values in the range 64-223 (decimal) inclusive are assigned via Specification Required"]. I chose `IllegalArgumentException` because it seemed values so far "out of range" would be undesirable, and perhaps I misinterpreted the commented paragraph above as implying that the `id` value needed to be one of the set of "acceptable certificate types". After referring back to the RFC, I agree that your proposed fix seems more in line with the intent of the RFC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14778#discussion_r1254616765 From kdriver at openjdk.org Thu Jul 6 15:52:00 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 6 Jul 2023 15:52:00 GMT Subject: RFR: 8295068: SSLEngine throws NPE parsing CertificateRequests [v2] In-Reply-To: References: Message-ID: > JDK-8295068: an NPE is thrown when an invalid `id` is found to match up a `ClientCertificateType`; rather than throwing the `NPE`, we now throw an `IllegalArgumentException`. This does not seem to be a scenario where recovery is possible or desired, so the `IAE` should be the proper behavior. Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: - remove extra line break - fail to look up the id silently to not throw an unexpected error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14778/files - new: https://git.openjdk.org/jdk/pull/14778/files/d36df7ba..ce669848 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14778&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14778&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14778.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14778/head:pull/14778 PR: https://git.openjdk.org/jdk/pull/14778 From xuelei at openjdk.org Thu Jul 6 16:25:59 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 6 Jul 2023 16:25:59 GMT Subject: RFR: 8295068: SSLEngine throws NPE parsing CertificateRequests [v2] In-Reply-To: References:

Message-ID: <8rQcBMO1AsJYpqiRJu5mwb_iXAOb8eOZcB7v67YYngo=.5d7945a0-18a4-4365-a4ce-e1837ea7e61d@github.com> On Thu, 6 Jul 2023 15:52:00 GMT, Kevin Driver wrote: >> JDK-8295068: an NPE is thrown when an invalid `id` is found to match up a `ClientCertificateType`; rather than throwing the `NPE`, we now ignore an `id` which does match a `ClientCertificateType`. > > Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: > > - remove extra line break > - fail to look up the id silently to not throw an unexpected error It looks good to me. Thank you for the update. ------------- Marked as reviewed by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14778#pullrequestreview-1516909264 From mullan at openjdk.org Thu Jul 6 16:31:56 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 6 Jul 2023 16:31:56 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: <7yuqL0DLUyWhGC6wSWSW1-N1DaBS8BhckH497vDRjc0=.88229507-e548-48eb-ac9d-0de0322e3997@github.com> On Wed, 5 Jul 2023 14:52:22 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into 8311170 > - Be consistent with the rest of the change > - Fix reported bugs > - Add even more cases and tidy up > - More cases > - Initial commit src/java.base/share/classes/java/security/BasicPermission.java line 220: > 218: > 219: /** > 220: * {@return the hash code value for this object} Where is this new javadoc syntax documented/specified? I recall seeing something about it, but not sure where and now I would like to read up on it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1254668174 From prappo at openjdk.org Thu Jul 6 16:31:56 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 6 Jul 2023 16:31:56 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: <7yuqL0DLUyWhGC6wSWSW1-N1DaBS8BhckH497vDRjc0=.88229507-e548-48eb-ac9d-0de0322e3997@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <7yuqL0DLUyWhGC6wSWSW1-N1DaBS8BhckH497vDRjc0=.88229507-e548-48eb-ac9d-0de0322e3997@github.com> Message-ID: On Thu, 6 Jul 2023 16:25:05 GMT, Sean Mullan wrote: >> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8311170 >> - Be consistent with the rest of the change >> - Fix reported bugs >> - Add even more cases and tidy up >> - More cases >> - Initial commit > > src/java.base/share/classes/java/security/BasicPermission.java line 220: > >> 218: >> 219: /** >> 220: * {@return the hash code value for this object} > > Where is this new javadoc syntax documented/specified? I recall seeing something about it, but not sure where and now I would like to read up on it. It's relatively new: since JDK 16. You can read about `@return`: here https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#return ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1254670015 From mullan at openjdk.org Thu Jul 6 16:44:57 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 6 Jul 2023 16:44:57 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Wed, 5 Jul 2023 14:52:22 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into 8311170 > - Be consistent with the rest of the change > - Fix reported bugs > - Add even more cases and tidy up > - More cases > - Initial commit src/java.base/share/classes/java/security/cert/CertPath.java line 191: > 189: > 190: /** > 191: * {@return the hashcode value for this certification path} The hash code This looks a bit odd w/o a period at the end of the `}`. Is it optional? [The javadoc spec](https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#return) isn't very clear on that - perhaps you could clarify that in the spec. If it is optional, my general preference would be to include the period, as it makes the code more readable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1254683886 From jjg at openjdk.org Thu Jul 6 16:57:58 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 6 Jul 2023 16:57:58 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com>

Message-ID: On Thu, 6 Jul 2023 16:41:37 GMT, Sean Mullan wrote: >> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8311170 >> - Be consistent with the rest of the change >> - Fix reported bugs >> - Add even more cases and tidy up >> - More cases >> - Initial commit > > src/java.base/share/classes/java/security/cert/CertPath.java line 191: > >> 189: >> 190: /** >> 191: * {@return the hashcode value for this certification path} The hash code > > This looks a bit odd w/o a period at the end of the `}`. Is it optional? [The javadoc spec](https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#return) isn't very clear on that - perhaps you could clarify that in the spec. > > If it is optional, my general preference would be to include the period, as it makes the code more readable. > > Or maybe if you started "The hash code ..." on a new line it would look more reasonable. While I agree it looks "a bit odd", the problem is having to address the two ways in which the tag is rendered: 1. As the first sentence. In this case, the text in the braces is preceded by `Returns` and followed by a period. 2. As the equivalent for an `@return` tag, where `Returns:` is a bold heading, and the content is a phrase, and (generally) not followed by a period. The current guideline is that the period should not be present. Elsewhere, the "oddness" is reduced by putting a newline after the tag, so that the `{@return}` tag stands on a line by itself. To forestall any possible suggestion, I would not be in favor of looking outside the tag to see if there is a period following the tag. We can clarify the spec. If you are uncomfortable with the usage here, it is always possible to avoid using the short inline form, and to "duplicate" the text and use an old-fashioned plain first sentence, and an old-fashioned `@return` "block" tag ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1254696669 From mullan at openjdk.org Thu Jul 6 17:08:57 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 6 Jul 2023 17:08:57 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> Message-ID: On Wed, 5 Jul 2023 18:18:02 GMT, Roger Riggs wrote: >> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8311170 >> - Be consistent with the rest of the change >> - Fix reported bugs >> - Add even more cases and tidy up >> - More cases >> - Initial commit > > src/java.base/share/classes/sun/security/x509/X500Name.java line 422: > >> 420: // quick check that number of RDNs and AVAs match before canonicalizing >> 421: if (!Arrays.equals(this.names, other.names, >> 422: Comparator.comparingInt(n -> n.assertion.length))) > > I'd keep the original comparison of the lengths; its a lot less magical than `Comparator.comparingInt(n -> n.assertion.length))` I tend to agree with Roger. I have to think more about what is being compared with the new code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1254706673 From mchung at openjdk.org Thu Jul 6 17:17:57 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 6 Jul 2023 17:17:57 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: References:

Message-ID: On Thu, 29 Jun 2023 08:27:43 GMT, Alan Bateman wrote: > The changes make me wonder if `-XshowSetting:aardvark` should be an error rather than default to print all settings. Something we should look at again. Same thing for `-XshowSettings:system` on non-Linux, probably should have been a bit more discussion when that was added as its more about the container environment. I think throwing an error for an invalid suboption makes sense. `-XshowSetting` without the suboption is default to print all settings, i.e. equivalent to `-XshowSetting:all`. But the switch statment is missing the `all` case. I think we should fix this and error for any invalid option. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1624030798 From mullan at openjdk.org Thu Jul 6 17:35:57 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 6 Jul 2023 17:35:57 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> Message-ID: On Wed, 5 Jul 2023 17:53:55 GMT, Roger Riggs wrote: >> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8311170 >> - Be consistent with the rest of the change >> - Fix reported bugs >> - Add even more cases and tidy up >> - More cases >> - Initial commit > > src/java.base/share/classes/java/security/cert/X509CRLEntry.java line 110: > >> 108: public int hashCode() { >> 109: try { >> 110: return Arrays.hashCode(this.getEncoded()); > > What data is at `entryData[0]` that will now be included in the hashCode when it was skipped before? I would have to dump out an encoded CRL to check, but I think it should be ok to include it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1254732666 From mullan at openjdk.org Thu Jul 6 17:42:54 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 6 Jul 2023 17:42:54 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com>

Message-ID: On Thu, 6 Jul 2023 16:55:12 GMT, Jonathan Gibbons wrote: >> src/java.base/share/classes/java/security/cert/CertPath.java line 191: >> >>> 189: >>> 190: /** >>> 191: * {@return the hashcode value for this certification path} The hash code >> >> This looks a bit odd w/o a period at the end of the `}`. Is it optional? [The javadoc spec](https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#return) isn't very clear on that - perhaps you could clarify that in the spec. >> >> If it is optional, my general preference would be to include the period, as it makes the code more readable. >> >> Or maybe if you started "The hash code ..." on a new line it would look more reasonable. > > While I agree it looks "a bit odd", the problem is having to address the two ways in which the tag is rendered: > > 1. As the first sentence. In this case, the text in the braces is preceded by `Returns` and followed by a period. > 2. As the equivalent for an `@return` tag, where `Returns:` is a bold heading, and the content is a phrase, and (generally) not followed by a period. > > The current guideline is that the period should not be present. Elsewhere, the "oddness" is reduced by putting > a newline after the tag, so that the `{@return}` tag stands on a line by itself. To forestall any possible suggestion, > I would not be in favor of looking outside the tag to see if there is a period following the tag. > > We can clarify the spec. > > If you are uncomfortable with the usage here, it is always possible to avoid using the short inline form, and to "duplicate" the text and use an old-fashioned plain first sentence, and an old-fashioned `@return` "block" tag I think it may be one of those things that people won't realize the period should not be included and might miss as there are no errors and the rendered javadoc will include 2 periods, which is easy to miss. But now that I know about it, I will remember to check for it :) I think I would be more in favor of starting the next sentence on a new line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1254740661 From rriggs at openjdk.org Thu Jul 6 19:01:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Jul 2023 19:01:06 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: References:

Message-ID: On Tue, 27 Jun 2023 15:06:45 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: > > - Avoid sharing INDENT variables > - Merge branch 'master' into 8281658-showsettings-security > - Don't allow bad subcommand values for security component > - restore more informative help message > - Split long properties for ; also > - Pass PrintStream to security helper > - Refactor out security code to helper class > - Print aliases. Order Provider type/service output. > - Incorporate review comments from Roger and tweak some code > - Merge branch 'master' into 8281658-showsettings-security > - ... and 5 more: https://git.openjdk.org/jdk/compare/da750e20...7e6f5090 Marked as reviewed by rriggs (Reviewer). src/java.base/share/classes/sun/launcher/LauncherHelper.java line 115: > 113: private static StringBuilder outBuf = new StringBuilder(); > 114: > 115: private static final String INDENT = " ".repeat(4); Revert this, its just making a simple constant into a runtime expression. ------------- PR Review: https://git.openjdk.org/jdk/pull/14394#pullrequestreview-1517119059 PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1254799500 From prappo at openjdk.org Thu Jul 6 19:04:23 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 6 Jul 2023 19:04:23 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v5] 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: Revert for readability ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/cb6e1776..42d9543b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=03-04 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 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 Thu Jul 6 19:04:24 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 6 Jul 2023 19:04:24 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> <_0_sGy1nun0IvmqOEU-JJi8EX7vpWjlyE5QbCVegLf0=.bf0f9c04-0167-467d-8235-eecf8cb66914@github.com> Message-ID: On Thu, 6 Jul 2023 17:06:31 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/x509/X500Name.java line 422: >> >>> 420: // quick check that number of RDNs and AVAs match before canonicalizing >>> 421: if (!Arrays.equals(this.names, other.names, >>> 422: Comparator.comparingInt(n -> n.assertion.length))) >> >> I'd keep the original comparison of the lengths; its a lot less magical than `Comparator.comparingInt(n -> n.assertion.length))` > > I tend to agree with Roger. I have to think more about what is being compared with the new code. Yeah, I assume no matter how one shapes it, it doesn't seem a readability win: if (!Arrays.equals(this.names, other.names, (n1, n2) -> Integer.compare(n1.assertion.length, n2.assertion.length))) { return false; } Reverted in 42d9543b769. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1254811720 From prappo at openjdk.org Thu Jul 6 19:10:14 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 6 Jul 2023 19:10:14 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v6] 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: Reflow doc comment as suggested ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/42d9543b..054ae4b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 duke at openjdk.org Thu Jul 6 23:35:09 2023 From: duke at openjdk.org (duke) Date: Thu, 6 Jul 2023 23:35:09 GMT Subject: Withdrawn: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12726 From coffeys at openjdk.org Fri Jul 7 13:47:31 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 7 Jul 2023 13:47:31 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v9] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - tweaks based on latest reviews - Merge branch 'master' into 8281658-showsettings-security - Avoid sharing INDENT variables - Merge branch 'master' into 8281658-showsettings-security - Don't allow bad subcommand values for security component - restore more informative help message - Split long properties for ; also - Pass PrintStream to security helper - Refactor out security code to helper class - Print aliases. Order Provider type/service output. - ... and 7 more: https://git.openjdk.org/jdk/compare/f233ca46...c563e18e ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/7e6f5090..c563e18e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=07-08 Stats: 50304 lines in 563 files changed: 5893 ins; 41788 del; 2623 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From coffeys at openjdk.org Fri Jul 7 13:47:31 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 7 Jul 2023 13:47:31 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: References:

Message-ID: On Thu, 6 Jul 2023 17:15:20 GMT, Mandy Chung wrote: > > The changes make me wonder if `-XshowSetting:aardvark` should be an error rather than default to print all settings. Something we should look at again. Same thing for `-XshowSettings:system` on non-Linux, probably should have been a bit more discussion when that was added as its more about the container environment. > > I think throwing an error for an invalid suboption makes sense. `-XshowSetting` without the suboption is default to print all settings, i.e. equivalent to `-XshowSetting:all`. But the switch statment is missing the `all` case. I think we should fix this and error for any invalid option. fair point Mandy - I hope to change such behavior in a new follow on patch that I'll deliver shortly: JDK-8311653 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1625434995 From coffeys at openjdk.org Fri Jul 7 13:47:34 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 7 Jul 2023 13:47:34 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: References:

Message-ID: On Thu, 6 Jul 2023 18:43:41 GMT, Roger Riggs wrote: >> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: >> >> - Avoid sharing INDENT variables >> - Merge branch 'master' into 8281658-showsettings-security >> - Don't allow bad subcommand values for security component >> - restore more informative help message >> - Split long properties for ; also >> - Pass PrintStream to security helper >> - Refactor out security code to helper class >> - Print aliases. Order Provider type/service output. >> - Incorporate review comments from Roger and tweak some code >> - Merge branch 'master' into 8281658-showsettings-security >> - ... and 5 more: https://git.openjdk.org/jdk/compare/774eb316...7e6f5090 > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 115: > >> 113: private static StringBuilder outBuf = new StringBuilder(); >> 114: >> 115: private static final String INDENT = " ".repeat(4); > > Revert this, its just making a simple constant into a runtime expression. Thanks Roger. Fair point. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1255844148 From coffeys at openjdk.org Fri Jul 7 13:47:35 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 7 Jul 2023 13:47:35 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: References:

Message-ID: <9G_72rcKvOLsqveLtQOM5yxUBIeuKEZQGGrMjRSLk5o=.efe5f084-bc39-4ba3-84d9-ae52e7eb46eb@github.com> On Thu, 6 Jul 2023 14:03:12 GMT, Sean Mullan wrote: >> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: >> >> - Avoid sharing INDENT variables >> - Merge branch 'master' into 8281658-showsettings-security >> - Don't allow bad subcommand values for security component >> - restore more informative help message >> - Split long properties for ; also >> - Pass PrintStream to security helper >> - Refactor out security code to helper class >> - Print aliases. Order Provider type/service output. >> - Incorporate review comments from Roger and tweak some code >> - Merge branch 'master' into 8281658-showsettings-security >> - ... and 5 more: https://git.openjdk.org/jdk/compare/774eb316...7e6f5090 > > src/java.base/share/classes/sun/launcher/SecuritySettings.java line 123: > >> 121: } >> 122: >> 123: ostream.println(INDENT + "Security TLS configuration:"); > > What about also noting the name of the TLS/JSSE provider in this line, for example: > > "Security TLS configuration (SunJSSE provider):" > > This would be useful information if a customer is using a 3rd party JSSE provider, and it is selected before SunJSSE, as the defaults in that case may be different. good suggestion Sean. Patch updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1255842787 From coffeys at openjdk.org Fri Jul 7 14:53:00 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 7 Jul 2023 14:53:00 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v8] In-Reply-To: <9G_72rcKvOLsqveLtQOM5yxUBIeuKEZQGGrMjRSLk5o=.efe5f084-bc39-4ba3-84d9-ae52e7eb46eb@github.com> References:

<9G_72rcKvOLsqveLtQOM5yxUBIeuKEZQGGrMjRSLk5o=.efe5f084-bc39-4ba3-84d9-ae52e7eb46eb@github.com> Message-ID: On Fri, 7 Jul 2023 13:40:53 GMT, Sean Coffey wrote: >> src/java.base/share/classes/sun/launcher/SecuritySettings.java line 123: >> >>> 121: } >>> 122: >>> 123: ostream.println(INDENT + "Security TLS configuration:"); >> >> What about also noting the name of the TLS/JSSE provider in this line, for example: >> >> "Security TLS configuration (SunJSSE provider):" >> >> This would be useful information if a customer is using a 3rd party JSSE provider, and it is selected before SunJSSE, as the defaults in that case may be different. > > good suggestion Sean. Patch updated. I think we need to harden this area of code actually. Some JDK configurations may not have an SSL provider. e.g. (removing JSSE from config) See "java -X" for verbose security settings options Security provider static configuration: (in order of preference) Provider name: SUN Provider name: SunRsaSign Exception in thread "main" java.lang.InternalError: Failed to create SSL socket at java.base/sun.launcher.SecuritySettings.printSecurityTLSConfig(SecuritySettings.java:121) at java.base/sun.launcher.SecuritySettings.printSecuritySummarySettings(SecuritySettings.java:75) at java.base/sun.launcher.LauncherHelper.showSettings(LauncherHelper.java:188) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1255945485 From kdriver at openjdk.org Fri Jul 7 16:58:02 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 7 Jul 2023 16:58:02 GMT Subject: Integrated: 8295068: SSLEngine throws NPE parsing CertificateRequests In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 20:25:26 GMT, Kevin Driver wrote: > JDK-8295068: an NPE is thrown when an invalid `id` is found to match up a `ClientCertificateType`; rather than throwing the `NPE`, we now ignore an `id` which does match a `ClientCertificateType`. This pull request has now been integrated. Changeset: 5667afc3 Author: Kevin Driver Committer: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/5667afc36275b064c7700518f453fe8657e13636 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8295068: SSLEngine throws NPE parsing CertificateRequests Reviewed-by: xuelei ------------- PR: https://git.openjdk.org/jdk/pull/14778 From jlu at openjdk.org Fri Jul 7 19:05:02 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 7 Jul 2023 19:05:02 GMT Subject: RFR: 8311081: KeytoolReaderP12Test.java fail on localized Windows platform Message-ID: 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`. ------------- Commit messages: - Launch processes in English/US locale Changes: https://git.openjdk.org/jdk/pull/14806/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14806&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311081 Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14806/head:pull/14806 PR: https://git.openjdk.org/jdk/pull/14806 From rriggs at openjdk.org Fri Jul 7 19:07:56 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Jul 2023 19:07:56 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v6] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Thu, 6 Jul 2023 19:10:14 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: > > Reflow doc comment as suggested Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14738#pullrequestreview-1519605132 From lancea at openjdk.org Fri Jul 7 19:21:58 2023 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 7 Jul 2023 19:21:58 GMT Subject: RFR: 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`. Looks ok, you are probably going to need to add the noreg-self label to the bug ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14806#pullrequestreview-1519633108 From mullan at openjdk.org Fri Jul 7 19:23:59 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 7 Jul 2023 19:23:59 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v6] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: On Thu, 6 Jul 2023 19:10:14 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: > > Reflow doc comment as suggested Took another pass at this, looks good, but I would like to take another last look and make sure that changing the hash code for some of the classes like X509CRL is a benign change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14738#issuecomment-1625940764 From prappo at openjdk.org Fri Jul 7 19:24:00 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 7 Jul 2023 19:24:00 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v6] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com>

Message-ID: On Fri, 7 Jul 2023 19:19:03 GMT, Sean Mullan wrote: > Took another pass at this, looks good, but I would like to take another last look and make sure that changing the hash code for some of the classes like X509CRL is a benign change. Thanks, Sean. Take your time, you're an expert in this area. Meanwhile, I'll reflow other similar `{@return ... }` constructs that I missed before, for readability. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14738#issuecomment-1625945671 From coffeys at openjdk.org Fri Jul 7 19:42:18 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 7 Jul 2023 19:42:18 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v10] In-Reply-To: References: Message-ID: > New functionality in the -XshowSettings menu to display relevant information about JDK security configuration Sean Coffey has updated the pull request incrementally with two additional commits since the last revision: - Harden code to report lack of SSL support - Testcase correction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14394/files - new: https://git.openjdk.org/jdk/pull/14394/files/c563e18e..559f698e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=08-09 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394 PR: https://git.openjdk.org/jdk/pull/14394 From prappo at openjdk.org Fri Jul 7 23:19:27 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 7 Jul 2023 23:19:27 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v7] 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into 8311170 - Reflow previously missed doc comment - Reflow doc comment as suggested - Revert for readability - Merge branch 'master' into 8311170 - Be consistent with the rest of the change - Fix reported bugs - Add even more cases and tidy up - More cases - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/054ae4b9..bb504a7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=05-06 Stats: 42868 lines in 93 files changed: 1587 ins; 40719 del; 562 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 jpai at openjdk.org Sat Jul 8 05:47:53 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 8 Jul 2023 05:47:53 GMT Subject: RFR: 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`. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14806#pullrequestreview-1520649382 From Alan.Bateman at oracle.com Mon Jul 10 10:41:33 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jul 2023 11:41:33 +0100 Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base In-Reply-To: References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com> <2c1ddf91-4c0c-537d-90f9-160988ce2d27@zeus.net.au>

Message-ID: <1ae3a1dc-7bea-0622-5829-5088ce21dc37@oracle.com> On 04/07/2023 11:23, Peter Firmstone wrote: > Thanks Anthony, > > Always interesting to see how others are managing modularity. Some > time ago now (circa 2007), Sun released Jini as open source, set up a > project at Apache called River, we struggled to get developers though, > we had a big monolithic codebase and developers couldn't get their > heads around it.?? When I was modularising it, I decided to use SPI's > as module boundaries, it turned out to be a good decision, we ended up > making all our SPI's OSGi services as well.?? Probably doesn't matter > in this instance, OpenJDK is already modular, and it's implementation > detail.?? Some of our crypto providers are in the same module, but I'm > thinking of separating them into different modules now, as some are no > longer secure, but some people may still need them for compatibility, > by moving old code into different modules, we can allow to die a > peaceful death, without requiring people who don't use it to be > burdened by it. > The concept to learn here is "services" and the uses/provides clauses that are used to say if a module makes use of a service or provides an implementation of. When using services you get a lot more flexibility to refactor without breaking anyone. -Alan From mullan at openjdk.org Mon Jul 10 14:44:24 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 10 Jul 2023 14:44:24 GMT Subject: RFR: 8281658: Add a security category to the java -XshowSettings option [v10] In-Reply-To: References:

Message-ID: On Fri, 7 Jul 2023 19:42:18 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration > > Sean Coffey has updated the pull request incrementally with two additional commits since the last revision: > > - Harden code to report lack of SSL support > - Testcase correction Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14394#pullrequestreview-1522251783 From vlivanov at openjdk.org Mon Jul 10 17:04:30 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 10 Jul 2023 17:04:30 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v21] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <1s2gGfT_bsyz2mtAr3UFbXKlXniyiK2Hk4lZmBm_Crk=.89639816-872b-436f-9863-d5044e4a9ea5@github.com> On Thu, 6 Jul 2023 13:06:30 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Merge branch 'openjdk:master' into rematerialization-of-merges > - Addressing PR feedback. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Merge branch 'openjdk:master' into rematerialization-of-merges > - Rome minor refactorings. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > Catching up with master. > - Address PR review 6: debug format output & some refactoring. > - Catching up with master branch. > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address PR review 6: refactoring around rematerialization & improve test cases. > - Address PR review 5: refactor on rematerialization & add tests. > - ... and 12 more: https://git.openjdk.org/jdk/compare/97e99f01...25b683d6 The patch looks good. I resubmitted testing with the latest version and the results are clean. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1522564439 From kvn at openjdk.org Mon Jul 10 19:55:07 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 10 Jul 2023 19:55:07 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v21] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Thu, 6 Jul 2023 13:06:30 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Merge branch 'openjdk:master' into rematerialization-of-merges > - Addressing PR feedback. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Merge branch 'openjdk:master' into rematerialization-of-merges > - Rome minor refactorings. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > Catching up with master. > - Address PR review 6: debug format output & some refactoring. > - Catching up with master branch. > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address PR review 6: refactoring around rematerialization & improve test cases. > - Address PR review 5: refactor on rematerialization & add tests. > - ... and 12 more: https://git.openjdk.org/jdk/compare/97e99f01...25b683d6 The final version looks good to me too. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1522912018 From andrew at openjdk.org Tue Jul 11 08:51:13 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 11 Jul 2023 08:51:13 GMT Subject: RFR: 8309330: Allow java.security to be extended via a properties directory [v2] In-Reply-To: References:

Message-ID: <_Qg2VMk-lf7D-Qe8lt0W6ncUlLxdW8BykJp6JOfe62A=.e12e42ec-549c-45f3-ab95-52b6eb725721@github.com> On Fri, 2 Jun 2023 12:58:36 GMT, Andrew John Hughes wrote: >> Currently, security properties are held within the `java.security` file in the JDK tree for each installed JDK. The system property `java.security.properties` can be used to point to a file containing additional properties. These can be appended to the existing set or override all existing properties. >> >> There is currently no way to specify additional properties permanently or to reference multiple files. Making permanent changes to the `java.security` properties requires editing the `java.security` file in each JDK where the changes are required. >> >> This patch allows a directory tree to be specified either permanently in the java.security file by the `security.propertiesDir` property or on the command line using `java.security.propertiesDir`. Any property files found in this directory tree can be appended to those specified in `java.security`, as with the single file used by `java.security.properties`. >> >> As an example, the `security.propertiesDir` in the `java.security` file of each JDK can be set to a common shared directory, allowing all JDKs to share a common set of security properties. This eases setting up properties on each new JDK installation and also allows the shared properties to be maintained under different access permissions to those of the JDK. >> >> The command-line variant, `java.security.propertiesDir`, is intended primarily for testing and to disable a permanent properties directory by setting the value to empty. As with `java.security.properties`, the system property will be ignored if `security.overridePropertiesFile` in the `java.security` file is not set to true. >> >> A less flexible version of this patch (a permanent hardcoded single file) has been [used in our JDK installations since 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a system-wide crypto policy. Having support for this in the upstream JDK would allow us to remove a local patch from our builds and reduce divergence from upstream. > > Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision: > > Sort the returned list of property files and exclude hidden files. Still waiting on CSR resolution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14277#issuecomment-1630411780 From ecki at zusammenkunft.net Tue Jul 11 10:12:09 2023 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 11 Jul 2023 12:12:09 +0200 Subject: RFR: 8309330: Allow java.security to be extended via a properties directory [v2] In-Reply-To: <_Qg2VMk-lf7D-Qe8lt0W6ncUlLxdW8BykJp6JOfe62A=.e12e42ec-549c-45f3-ab95-52b6eb725721@github.com> References:

, <_Qg2VMk-lf7D-Qe8lt0W6ncUlLxdW8BykJp6JOfe62A=.e12e42ec-549c-45f3-ab95-52b6eb725721@github.com> Message-ID: <7E6B7F63-AE08-6B47-ABC3-E2AEA6419408@hxcore.ol> An HTML attachment was scrubbed... URL: From prappo at openjdk.org Tue Jul 11 19:38:02 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 11 Jul 2023 19:38:02 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v6] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com>

Message-ID: On Fri, 7 Jul 2023 19:21:29 GMT, Pavel Rappo wrote: > > Took another pass at this, looks good, but I would like to take another last look and make sure that changing the hash code for some of the classes like X509CRL is a benign change. > > Thanks, Sean. Take your time, you're an expert in this area. Meanwhile, I'll reflow other similar `{@return ... }` constructs that I missed before, for readability. This comment is NOT to rush the review. I once again note, that those classes in this PR that skip the first array element in `hashCode`, do not seem to skip that same element in `equals`. Although that does not breach equals-hashCode contract, it puzzles the reader and theoretically makes `hashCode` more blunt (i.e. more instances may share a hash code value). This observation is an investigation opportunity. But equally, I'm okay with skipping the investigation and reverting those particular changes, if security-dev wants to be on the safe side. We might soon have a more flexible way to compute hashCode [^*]. If we have it, we could then both refactor those hashCode implementations and preserve their behaviour. [^*]: https://github.com/openjdk/jdk/pull/14831 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14738#issuecomment-1631404126 From duke at openjdk.org Tue Jul 11 19:40:27 2023 From: duke at openjdk.org (Craig Andrews) Date: Tue, 11 Jul 2023 19:40:27 GMT Subject: RFR: JDK-8311892: TrustManagerFactory loading an invalid keystore yield vague exception Message-ID: When loading the default JVM trust store, if the JVM trust store contains an invalid certificate, the exception contains insufficient information to determine which certificate is invalid, making it very difficult to fix the problem. To reproduce the issue: 1. Modify the default JVM trust store to contain invalid information. A very easy way to do this on openjdk / red hat systems is to edit /etc/pki/ca-trust/extracted/java/cacerts and add garbage text to the file. 2. Run this code: TrustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); // initializing the trust store with a null KeyStore will load the default JVM trust store tmf.init((KeyStore) null); This stack trace results: Caused by: java.security.KeyStoreException: problem accessing trust store at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:73) at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:282) ... 81 common frames omitted Caused by: java.io.IOException: toDerInputStream rejects tag type 97 at java.base/sun.security.util.DerValue.toDerInputStream(DerValue.java:1155) at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2013) at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:221) at java.base/java.security.KeyStore.load(KeyStore.java:1473) at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:390) at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:336) at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:57) at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49) ... 83 common frames omitted Throwing an exception with a more detailed error message facilitates debugging and ultimately fixing such problems. ------------- Commit messages: - JDK-8311892: TrustManagerFactory loading an invalid keystore yield vague exception Changes: https://git.openjdk.org/jdk/pull/14834/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311892 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14834/head:pull/14834 PR: https://git.openjdk.org/jdk/pull/14834 From rhalade at openjdk.org Tue Jul 11 20:50:35 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 11 Jul 2023 20:50:35 GMT Subject: RFR: 8295894: Remove SECOM certificate that is expiring in September 2023 Message-ID: The fix is to remove the expiring SECOM root certificate after approval from root CA to remove it. Release note is at - https://bugs.openjdk.org/browse/JDK-8311884 ------------- Commit messages: - 8295894: Remove SECOM certificate that is expiring in September 2023 Changes: https://git.openjdk.org/jdk/pull/14838/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14838&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295894 Stats: 32 lines in 2 files changed: 0 ins; 29 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14838/head:pull/14838 PR: https://git.openjdk.org/jdk/pull/14838 From xuelei at openjdk.org Tue Jul 11 21:08:02 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 11 Jul 2023 21:08:02 GMT Subject: RFR: 8295894: Remove SECOM certificate that is expiring in September 2023 In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 20:42:14 GMT, Rajan Halade wrote: > The fix is to remove the expiring SECOM root certificate after approval from root CA to remove it. > > Release note is at - https://bugs.openjdk.org/browse/JDK-8311884 Marked as reviewed by xuelei (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14838#pullrequestreview-1525157343 From prappo at openjdk.org Tue Jul 11 22:01:15 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 11 Jul 2023 22:01:15 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v7] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: <67vihBZ2HHeUAjXXIVpF_h7Q1P-nIE6q__hlzS8OyaE=.d2d49fe1-1c48-4785-98c5-cea25ff8d1c0@github.com> On Fri, 7 Jul 2023 23:19:27 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 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 10 additional commits since the last revision: > > - Merge branch 'master' into 8311170 > - Reflow previously missed doc comment > - Reflow doc comment as suggested > - Revert for readability > - Merge branch 'master' into 8311170 > - Be consistent with the rest of the change > - Fix reported bugs > - Add even more cases and tidy up > - More cases > - Initial commit > > > Took another pass at this, looks good, but I would like to take another last look and make sure that changing the hash code for some of the classes like X509CRL is a benign change. > > > > > > Thanks, Sean. Take your time, you're an expert in this area. Meanwhile, I'll reflow other similar `{@return ... }` constructs that I missed before, for readability. > > This comment is NOT to rush the review. > > I once again note, that those classes in this PR that skip the first array element in `hashCode`, do not seem to skip that same element in `equals`. Although that does not breach equals-hashCode contract, it puzzles the reader and theoretically makes `hashCode` more blunt (i.e. more instances may share a hash code value). > > This observation is an investigation opportunity. But equally, I'm okay with skipping the investigation and reverting those particular changes, if security-dev wants to be on the safe side. We might soon have a more flexible way to compute hashCode [1](#user-content-fn-*-d08640fefec8cc5b91d743888afc0a5d). If we have it, we could then both refactor those hashCode implementations and preserve their behaviour. > > ## Footnotes > 1. https://github.com/openjdk/jdk/pull/14831 [?](#user-content-fnref-*-d08640fefec8cc5b91d743888afc0a5d) To add to my previous comment. Don't know if it helps, but I found this bug, that applies similar (to my non-expert eye) refactoring to java.security.cert.Certificate.hashCode: 8011402: Move blacklisting certificate logic from hard code to data ------------- PR Comment: https://git.openjdk.org/jdk/pull/14738#issuecomment-1631563886 From mullan at openjdk.org Tue Jul 11 22:36:10 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 11 Jul 2023 22:36:10 GMT Subject: RFR: 8295894: Remove SECOM certificate that is expiring in September 2023 In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 20:42:14 GMT, Rajan Halade wrote: > The fix is to remove the expiring SECOM root certificate after approval from root CA to remove it. > > Release note is at - https://bugs.openjdk.org/browse/JDK-8311884 Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14838#pullrequestreview-1525242154 From valeriep at openjdk.org Tue Jul 11 23:27:20 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 11 Jul 2023 23:27:20 GMT Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown Message-ID: This change refactors the RSAPadding class to return an output record containing the status instead of relying on exception object to indicate a failure. Thanks in advance for review~ Valerie ------------- Commit messages: - 8302017: Allocate BadPaddingException only if it will be thrown Changes: https://git.openjdk.org/jdk/pull/14839/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14839&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302017 Stats: 179 lines in 5 files changed: 107 ins; 23 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/14839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14839/head:pull/14839 PR: https://git.openjdk.org/jdk/pull/14839 From rhalade at openjdk.org Tue Jul 11 23:57:19 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 11 Jul 2023 23:57:19 GMT Subject: Integrated: 8295894: Remove SECOM certificate that is expiring in September 2023 In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 20:42:14 GMT, Rajan Halade wrote: > The fix is to remove the expiring SECOM root certificate after approval from root CA to remove it. > > Release note is at - https://bugs.openjdk.org/browse/JDK-8311884 This pull request has now been integrated. Changeset: fd7fddb6 Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/fd7fddb6ed24e0ae4b5e18fb27fd80230941dc0b Stats: 32 lines in 2 files changed: 0 ins; 29 del; 3 mod 8295894: Remove SECOM certificate that is expiring in September 2023 Reviewed-by: xuelei, mullan ------------- PR: https://git.openjdk.org/jdk/pull/14838 From duke at openjdk.org Wed Jul 12 12:55:34 2023 From: duke at openjdk.org (Glavo) Date: Wed, 12 Jul 2023 12:55:34 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base Message-ID: Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. ------------- Commit messages: - 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=00 Issue: https://bugs.openjdk.org/browse/JDK-8311943 Stats: 51 lines in 13 files changed: 9 ins; 0 del; 42 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 jpai at openjdk.org Wed Jul 12 12:55:34 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 12 Jul 2023 12:55:34 GMT Subject: RFR: 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. Hello Glavo, I've created https://bugs.openjdk.org/browse/JDK-8311943 to track this change. Please update the title to this PR to `8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base` so that it triggers the official RFR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1632426553 From alanb at openjdk.org Wed Jul 12 13:29:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 12 Jul 2023 13:29:11 GMT Subject: RFR: 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. src/java.base/share/classes/java/io/StreamTokenizer.java line 632: > 630: sval = String.copyValueOf(buf, 0, i); > 631: if (forceLower) > 632: sval = sval.toLowerCase(Locale.ROOT); I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261178834 From duke at openjdk.org Wed Jul 12 14:35:16 2023 From: duke at openjdk.org (Glavo) Date: Wed, 12 Jul 2023 14:35:16 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base In-Reply-To: References:

Message-ID: On Wed, 12 Jul 2023 13:26:03 GMT, Alan Bateman wrote: > I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful. I investigated some usage of this method on GitHub: https://github.com/search?q=%22lowerCaseMode%28true%29%22+language%3AJava&type=code In the use cases I see, it seems that no one wants to rely on the default locale. However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261271535 From duke at openjdk.org Wed Jul 12 15:06:36 2023 From: duke at openjdk.org (Glavo) Date: Wed, 12 Jul 2023 15:06:36 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References: Message-ID: <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com> > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14763/files - new: https://git.openjdk.org/jdk/pull/14763/files/944acdc4..8b8957f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14763&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14763&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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 cslucas at openjdk.org Wed Jul 12 15:12:23 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 12 Jul 2023 15:12:23 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v21] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Thu, 6 Jul 2023 13:06:30 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Merge branch 'openjdk:master' into rematerialization-of-merges > - Addressing PR feedback. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Merge branch 'openjdk:master' into rematerialization-of-merges > - Rome minor refactorings. > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > Catching up with master. > - Address PR review 6: debug format output & some refactoring. > - Catching up with master branch. > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address PR review 6: refactoring around rematerialization & improve test cases. > - Address PR review 5: refactor on rematerialization & add tests. > - ... and 12 more: https://git.openjdk.org/jdk/compare/97e99f01...25b683d6 Thank you all for reviewing this PR! Your feedback made it much better! ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1632721475 From mullan at openjdk.org Wed Jul 12 15:40:24 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 12 Jul 2023 15:40:24 GMT Subject: RFR: 8156889: ListKeychainStore.sh fails in some virtualized environments In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 18:15:48 GMT, Rajan Halade wrote: > This fix converted shell test to java code. Following are the updates done to the original shell test logic: > > - Test is updated to be a manual test as it is rather difficult/impossible to have it run in virtualized environment where we can't update the security keychain search list to include created keychain. > - Test is updated to save earlier keychain search order and restore when test ends. > - Test is now using legacy encryption and MAC algorithms, refer macOS open radar FB8988319, as macOS security framework doesn't work with the latest algorithms. Algorithms were updated with JDK-8153005. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14424#pullrequestreview-1526662501 From mdonovan at openjdk.org Wed Jul 12 15:43:50 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 12 Jul 2023 15:43:50 GMT Subject: RFR: 8309305: sun/security/ssl/SSLSocketImpl/BlockedAsyncClose.java fails with jtreg test timeout [v2] In-Reply-To: References:

Message-ID: On Tue, 13 Jun 2023 14:24:20 GMT, Matthew Donovan wrote: >> This PR improves the reliability of the BlockedAsyncClose test by addressing an edge case/race condition between the two test threads. The purpose of the test is to verify that an SSLSocket can be closed if a thread is blocked in a write operation. >> >> The test starts a "write" thread that writes data to a socket until the output buffer was filled, causing the write operation to block. The main thread then calls `SSLSocket.close()`. The original code used `Thread.sleep(1000)` to wait for the write-thread to block. However, 1 second isn't always long enough and if the write-thread isn't blocked and the output buffer is full (or almost full), the `socket.close()` call may block when it tries to send the close_notify alert. This is the condition that caused this bug. >> >> My change uses a Lock to determine if the write thread is blocked. In the write thread, the lock creates a critical section around the `write()` call. The main thread uses `tryLock()` with a timeout to determine that the write() call is taking too long and thus likely blocked. >> >> While there, I also updated the test to use the SSLContextTemplate class. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace. > > Co-authored-by: Andrey Turbanov Can someone please review this? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14378#issuecomment-1632777482 From uschindler at openjdk.org Wed Jul 12 16:08:17 2023 From: uschindler at openjdk.org (Uwe Schindler) Date: Wed, 12 Jul 2023 16:08:17 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References:

Message-ID: On Wed, 12 Jul 2023 14:31:53 GMT, Glavo wrote: >> src/java.base/share/classes/java/io/StreamTokenizer.java line 632: >> >>> 630: sval = String.copyValueOf(buf, 0, i); >>> 631: if (forceLower) >>> 632: sval = sval.toLowerCase(Locale.ROOT); >> >> I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful. > >> I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful. > > I investigated usage of this method on GitHub: > > https://github.com/search?q=%22lowerCaseMode%28true%29%22+language%3AJava&type=code > > In some of the use cases I investigated, it seems that no one wants to rely on the default locale. > > However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future. Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset). To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. Without that it could be that somebody else starts the discussion again. This is just a suggestion to be explicit as it makes maintaining the code easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261404900 From duke at openjdk.org Wed Jul 12 16:22:15 2023 From: duke at openjdk.org (Glavo) Date: Wed, 12 Jul 2023 16:22:15 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References:

Message-ID: On Wed, 12 Jul 2023 16:05:03 GMT, Uwe Schindler wrote: > Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset). To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. Without that it could be that somebody else starts the discussion again. > > This is just a suggestion to be explicit as it makes maintaining the code easier. I agree with this. I'm working on deprecating `toLowerCase()` and `toUpperCase()`, this PR is part of that effort. I wish to convert all use cases of them to `toLowerCase(Locale)` and `toUpperCase(Locale)`. More backstory is detailed in https://github.com/openjdk/jdk/pull/13434#issuecomment-1503989660. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261421937 From xuelei at openjdk.org Wed Jul 12 17:02:04 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 12 Jul 2023 17:02:04 GMT Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 23:19:40 GMT, Valerie Peng wrote: > This change refactors the RSAPadding class to return an output record containing the status instead of relying on exception object to indicate a failure. > > Thanks in advance for review~ > Valerie Changes requested by xuelei (Reviewer). src/java.base/share/classes/sun/security/rsa/RSAPadding.java line 372: > 370: return Output.FAIL; > 371: } else { > 372: return Output.pass(data); The Output.pass(byte[]) will create a new instance and thus make the behavior detectable. Maybe, the Output class is not necessary, 'null' value return could be used instead. - if (bp) { - return Output.FAIL; - } else { - return Output.pass(data); + return bp ? null : data; src/java.base/share/classes/sun/security/rsa/RSASignature.java line 217: > 215: byte[] digest = getDigestValue(); > 216: byte[] decrypted = RSACore.rsa(sigBytes, publicKey); > 217: RSAPadding.Output po = padding.unpad(decrypted); In case you are already here, what if comparing the padded/encoded result, without use unpad() any longer? I meant to follow the spec as described in RFC8017#section-8.2.2: encode the `decryped` bytes and then compare the result with the `digest` bytes. ------------- PR Review: https://git.openjdk.org/jdk/pull/14839#pullrequestreview-1526794400 PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1261451456 PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1261463911 From rhalade at openjdk.org Wed Jul 12 17:59:35 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 12 Jul 2023 17:59:35 GMT Subject: [jdk21] RFR: 8295894: Remove SECOM certificate that is expiring in September 2023 Message-ID: JDK 21 will be released in Sept 2023 so this certificate should be removed from it as there would only be a week or so left once the release is shipped before the certificate expired. ------------- Commit messages: - Backport fd7fddb6ed24e0ae4b5e18fb27fd80230941dc0b Changes: https://git.openjdk.org/jdk21/pull/114/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=114&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295894 Stats: 32 lines in 2 files changed: 0 ins; 29 del; 3 mod Patch: https://git.openjdk.org/jdk21/pull/114.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/114/head:pull/114 PR: https://git.openjdk.org/jdk21/pull/114 From mullan at openjdk.org Wed Jul 12 18:15:15 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 12 Jul 2023 18:15:15 GMT Subject: [jdk21] RFR: 8295894: Remove SECOM certificate that is expiring in September 2023 In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 17:52:47 GMT, Rajan Halade wrote: > JDK 21 will be released in Sept 2023 so this certificate should be removed from it as there would only be a week or so left once the release is shipped before the certificate expired. Looks good. I think the RN should have a fixVersion of 21. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk21/pull/114#pullrequestreview-1526963303 From rhalade at openjdk.org Wed Jul 12 18:18:26 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 12 Jul 2023 18:18:26 GMT Subject: Integrated: 8156889: ListKeychainStore.sh fails in some virtualized environments In-Reply-To: References: Message-ID: <62dI3azIOf6r_t0R7x47gPoWaG4Y_RgErjloSjhY6lQ=.fdaa72b4-2470-43a7-9237-2ea7186648f1@github.com> On Mon, 12 Jun 2023 18:15:48 GMT, Rajan Halade wrote: > This fix converted shell test to java code. Following are the updates done to the original shell test logic: > > - Test is updated to be a manual test as it is rather difficult/impossible to have it run in virtualized environment where we can't update the security keychain search list to include created keychain. > - Test is updated to save earlier keychain search order and restore when test ends. > - Test is now using legacy encryption and MAC algorithms, refer macOS open radar FB8988319, as macOS security framework doesn't work with the latest algorithms. Algorithms were updated with JDK-8153005. This pull request has now been integrated. Changeset: 119cc495 Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/119cc495fc6c18a29b7484d294c31ad1d478791c Stats: 449 lines in 4 files changed: 202 ins; 247 del; 0 mod 8156889: ListKeychainStore.sh fails in some virtualized environments Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/14424 From rhalade at openjdk.org Wed Jul 12 18:21:24 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 12 Jul 2023 18:21:24 GMT Subject: [jdk21] Integrated: 8295894: Remove SECOM certificate that is expiring in September 2023 In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 17:52:47 GMT, Rajan Halade wrote: > JDK 21 will be released in Sept 2023 so this certificate should be removed from it as there would only be a week or so left once the release is shipped before the certificate expired. This pull request has now been integrated. Changeset: 72cf3c95 Author: Rajan Halade URL: https://git.openjdk.org/jdk21/commit/72cf3c958f764a255e59b8267aec6ed1847de225 Stats: 32 lines in 2 files changed: 0 ins; 29 del; 3 mod 8295894: Remove SECOM certificate that is expiring in September 2023 Reviewed-by: mullan Backport-of: fd7fddb6ed24e0ae4b5e18fb27fd80230941dc0b ------------- PR: https://git.openjdk.org/jdk21/pull/114 From rhalade at openjdk.org Wed Jul 12 18:29:21 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 12 Jul 2023 18:29:21 GMT Subject: [jdk21] RFR: 8156889: ListKeychainStore.sh fails in some virtualized environments Message-ID: Critical test update to be included in JDK 21 LTS release. ------------- Commit messages: - Backport 119cc495fc6c18a29b7484d294c31ad1d478791c Changes: https://git.openjdk.org/jdk21/pull/116/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=116&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8156889 Stats: 449 lines in 4 files changed: 202 ins; 247 del; 0 mod Patch: https://git.openjdk.org/jdk21/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/116/head:pull/116 PR: https://git.openjdk.org/jdk21/pull/116 From mullan at openjdk.org Wed Jul 12 18:46:20 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 12 Jul 2023 18:46:20 GMT Subject: [jdk21] RFR: 8156889: ListKeychainStore.sh fails in some virtualized environments In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 18:21:53 GMT, Rajan Halade wrote: > Critical test update to be included in JDK 21 LTS release. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/116#pullrequestreview-1527035043 From rhalade at openjdk.org Wed Jul 12 18:52:27 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 12 Jul 2023 18:52:27 GMT Subject: [jdk21] Integrated: 8156889: ListKeychainStore.sh fails in some virtualized environments In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 18:21:53 GMT, Rajan Halade wrote: > Critical test update to be included in JDK 21 LTS release. This pull request has now been integrated. Changeset: 82c8b28f Author: Rajan Halade URL: https://git.openjdk.org/jdk21/commit/82c8b28f4005c3c335d4fd60c2e3b55adfd200c6 Stats: 449 lines in 4 files changed: 202 ins; 247 del; 0 mod 8156889: ListKeychainStore.sh fails in some virtualized environments Reviewed-by: mullan Backport-of: 119cc495fc6c18a29b7484d294c31ad1d478791c ------------- PR: https://git.openjdk.org/jdk21/pull/116 From valeriep at openjdk.org Wed Jul 12 18:55:25 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 12 Jul 2023 18:55:25 GMT Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown In-Reply-To: References:

Message-ID: On Wed, 12 Jul 2023 16:46:08 GMT, Xue-Lei Andrew Fan wrote: >> This change refactors the RSAPadding class to return an output record containing the status instead of relying on exception object to indicate a failure. >> >> Thanks in advance for review~ >> Valerie > > src/java.base/share/classes/sun/security/rsa/RSAPadding.java line 372: > >> 370: return Output.FAIL; >> 371: } else { >> 372: return Output.pass(data); > > The Output.pass(byte[]) will create a new instance and thus make the behavior detectable. Maybe, the Output class is not necessary, 'null' value return could be used instead. > > > - if (bp) { > - return Output.FAIL; > - } else { > - return Output.pass(data); > + return bp ? null : data; Ok, I can change it back to byte[] ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1261602015 From valeriep at openjdk.org Wed Jul 12 19:07:16 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 12 Jul 2023 19:07:16 GMT Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown In-Reply-To: References:

Message-ID: <96lhIZwGkNPn4U2o-DAxONb8_6Xhwz1cgvU7czXc6M8=.ecf6ced1-5e0f-460b-968f-d470d51d0a47@github.com> On Wed, 12 Jul 2023 16:58:20 GMT, Xue-Lei Andrew Fan wrote: >> This change refactors the RSAPadding class to return an output record containing the status instead of relying on exception object to indicate a failure. >> >> Thanks in advance for review~ >> Valerie > > src/java.base/share/classes/sun/security/rsa/RSASignature.java line 217: > >> 215: byte[] digest = getDigestValue(); >> 216: byte[] decrypted = RSACore.rsa(sigBytes, publicKey); >> 217: RSAPadding.Output po = padding.unpad(decrypted); > > In case you are already here, what if comparing the padded/encoded result, without use unpad() any longer? I meant to follow the spec as described in RFC8017#section-8.2.2: encode the `decryped` bytes and then compare the result with the `digest` bytes. Ok, I can switch to this approach. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1261612766 From mullan at openjdk.org Wed Jul 12 19:15:00 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 12 Jul 2023 19:15:00 GMT Subject: RFR: JDK-8311892: TrustManagerFactory loading an invalid keystore yield vague exception In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 18:09:26 GMT, Craig Andrews wrote: > When loading the default JVM trust store, if the JVM trust store contains an invalid certificate, the exception contains insufficient information to determine which certificate is invalid, making it very difficult to fix the problem. > > To reproduce the issue: > 1. Modify the default JVM trust store to contain invalid information. A very easy way to do this on openjdk / red hat systems is to edit /etc/pki/ca-trust/extracted/java/cacerts and add garbage text to the file. > 2. Run this code: > > TrustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); > // initializing the trust store with a null KeyStore will load the default JVM trust store > tmf.init((KeyStore) null); > > > This stack trace results: > > Caused by: java.security.KeyStoreException: problem accessing trust store > at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:73) > at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:282) > ... 81 common frames omitted > Caused by: java.io.IOException: toDerInputStream rejects tag type 97 > at java.base/sun.security.util.DerValue.toDerInputStream(DerValue.java:1155) > at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2013) > at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:221) > at java.base/java.security.KeyStore.load(KeyStore.java:1473) > at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:390) > at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:336) > at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:57) > at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49) > ... 83 common frames omitted > > > Throwing an exception with a more detailed error message facilitates debugging and ultimately fixing such problems. Can you provide an example of the stack trace you now get with your proposed fix? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14834#issuecomment-1633068231 From valeriep at openjdk.org Wed Jul 12 23:12:18 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 12 Jul 2023 23:12:18 GMT Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown [v2] In-Reply-To: References: Message-ID: <9av18v7LjWdgjmIQNoOlDoT_oj5GcP_ROfGUx5Q9uUE=.30d64de6-5a5b-4799-b358-cd29b61f3b8e@github.com> > This change refactors the RSAPadding class to return an output record containing the status instead of relying on exception object to indicate a failure. > > Thanks in advance for review~ > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as before. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14839/files - new: https://git.openjdk.org/jdk/pull/14839/files/52e8e28f..cbb958d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14839&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14839&range=00-01 Stats: 83 lines in 5 files changed: 17 ins; 24 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/14839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14839/head:pull/14839 PR: https://git.openjdk.org/jdk/pull/14839 From valeriep at openjdk.org Thu Jul 13 02:53:29 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 13 Jul 2023 02:53:29 GMT Subject: RFR: 8311902: Concurrency regression in the PBKDF2 key impl of SunJCE provider Message-ID: This change adds back the Reference.ReachabilityFence(Object) call removed by [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553). Please help review. Thanks! Valerie ------------- Commit messages: - 8311902: Concurrency regression in the PBKDF2 key impl of SunJCE provider Changes: https://git.openjdk.org/jdk/pull/14859/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14859&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311902 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14859.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14859/head:pull/14859 PR: https://git.openjdk.org/jdk/pull/14859 From ascarpino at openjdk.org Thu Jul 13 03:55:52 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 13 Jul 2023 03:55:52 GMT Subject: RFR: 8311902: Concurrency regression in the PBKDF2 key impl of SunJCE provider In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 02:46:10 GMT, Valerie Peng wrote: > This change adds back the Reference.ReachabilityFence(Object) call removed by [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553). > > Please help review. > Thanks! > Valerie Looks good to me ------------- Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14859#pullrequestreview-1527528956 From xuelei at openjdk.org Thu Jul 13 04:18:52 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 13 Jul 2023 04:18:52 GMT Subject: RFR: 8311902: Concurrency regression in the PBKDF2 key impl of SunJCE provider In-Reply-To: References: Message-ID: <1HJGC1CrE5aqAaogrzoW1ZhxdnzGLeR-z1857YENk_8=.3c292fba-897a-4fd4-82ce-a38d0ff85be5@github.com> On Thu, 13 Jul 2023 02:46:10 GMT, Valerie Peng wrote: > This change adds back the Reference.ReachabilityFence(Object) call removed by [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553). > > Please help review. > Thanks! > Valerie It looks good to me to rollback to previous behaviors. I was just wondering, if the use of key in other methods, like hashCode()/equals(), has the similar issue? Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14859#pullrequestreview-1527542265 From xuelei at openjdk.org Thu Jul 13 04:41:14 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 13 Jul 2023 04:41:14 GMT Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown [v2] In-Reply-To: <9av18v7LjWdgjmIQNoOlDoT_oj5GcP_ROfGUx5Q9uUE=.30d64de6-5a5b-4799-b358-cd29b61f3b8e@github.com> References: <9av18v7LjWdgjmIQNoOlDoT_oj5GcP_ROfGUx5Q9uUE=.30d64de6-5a5b-4799-b358-cd29b61f3b8e@github.com> Message-ID: On Wed, 12 Jul 2023 23:12:18 GMT, Valerie Peng wrote: >> This change refactors the RSAPadding class to return an output record containing the status instead of relying on exception object to indicate a failure. >> >> Thanks in advance for review~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as before. Thank you for the update. src/java.base/share/classes/sun/security/rsa/RSASignature.java line 196: > 194: return RSACore.rsa(padded, privateKey, true); > 195: } > 196: throw new SignatureException("Could not sign data"); It may be clearer if the throw line is moved to the end of the method. Otherwise, I have to check if SignatureException is a sub-class of GeneralSecurityException. src/java.base/share/classes/sun/security/rsa/RSASignature.java line 231: > 229: RSAUtil.decodeSignature(digestOID, unpadded)); > 230: } > 231: } I understand where the fallback code came from. As the padding code is exactly the same as engineSign(), the risk may be minimal. With the fallback code, the security concern (time-constant) we cared about will come back. Did you run into testing failure without the fallback doe? ------------- PR Review: https://git.openjdk.org/jdk/pull/14839#pullrequestreview-1527547950 PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1261964861 PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1261970478 From prappo at openjdk.org Thu Jul 13 08:51:23 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 13 Jul 2023 08:51:23 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v8] 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: <-trukyY0g7D4huUrA8u9GBY13F_8Pyza8rPOlRMgUSM=.9fac7a62-4c79-4a42-b9f3-d4c1b60f6662@github.com> > Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in security area. > > I understand that security area is sensitive and a non-expert, such as myself, should tread carefully; so below are my notes to assist the review. > > * Unlike `hashCode`, non-secure `equals` implementations are typically short-circuit. But because of "timing attacks", we seem to have specialized implementations, such as `java.security.MessageDigest.isEqual(byte[], byte[])` and a more general `sun.security.util.ByteArrays.isEqual(byte[], int, int, byte[], int, int)`. So while reviewing this PR, take an opportunity to audit the affected `equals` implementations: perhaps some of them need to become secure, not modern. I have no domain knowledge to tell those cases apart, I only note that those cases exist. > > * This PR sacrifices compatibility for pragmatism: it changes some `hashCode` implementations to produce different values than before to allow more utilization of methods from `Objects` and `Arrays`. To my mind, those changes are **benign**. If you disagree, I'd be happy to discuss that and/or retract the concerning part of the change. > > * BitArray could be a topic of its own, but I'll do my best to be concise. > > * Truth to be told, BitArray's `equals` and `hashCode` are not used anywhere in source, and `equals` is only used in one test. For that reason, I refrained from reimplementing internals of `BitArray` using more general `java.util.BitSet`: too much effort and risk for almost nothing. > * Speaking of `BitSet`-powered `BitArray`. Such an implementation is not for the faint of heart: there's too much impedance mismatch between data structures that those classes use to store bits. That said, for the sake of testing that it is possible and that I understand the `BitArray` correctly, I actually implemented it using `BitSet`. While that implementation is **NOT** part of this PR, you can have a look at it [here](https://cr.openjdk.org/~prappo/8311170/BitArray.java). > > * One suggestion to consider is to change this somewhat arcane piece in java.security.UnresolvedPermission.equals: > > // check certs > if (this.certs == null && that.certs != null || > this.certs != null && that.certs == null || > this.certs != null && > this.certs.length != that.certs.length) { > return false; > } > > int i,j; > boolean match; > > for (i = 0; this.certs != nu... Pavel Rappo 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 12 additional commits since the last revision: - Much more cases: apologies for extra review work - Merge branch 'master' into 8311170 - Merge branch 'master' into 8311170 - Reflow previously missed doc comment - Reflow doc comment as suggested - Revert for readability - Merge branch 'master' into 8311170 - Be consistent with the rest of the change - Fix reported bugs - Add even more cases and tidy up - ... and 2 more: https://git.openjdk.org/jdk/compare/0c4516a6...457b9c56 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14738/files - new: https://git.openjdk.org/jdk/pull/14738/files/bb504a7a..457b9c56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14738&range=06-07 Stats: 15590 lines in 352 files changed: 7610 ins; 7165 del; 815 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 Thu Jul 13 08:54:16 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 13 Jul 2023 08:54:16 GMT Subject: RFR: 8311170: Simplify and modernize equals and hashCode in security area [v7] In-Reply-To: References: <26J4DxGERYIGa_G5PQDHzsE_axYce-hsOxfwYGK7OBw=.86332f20-6a8f-420b-be93-3cb0cf0089d1@github.com> Message-ID: <_Uj3GSbiRrgky3FbCJ-Z61Qri6S62ZzRPd02haCaars=.e08e0d71-b093-458b-af85-cd43ff9c643a@github.com> On Fri, 7 Jul 2023 23:19:27 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 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 10 additional commits since the last revision: > > - Merge branch 'master' into 8311170 > - Reflow previously missed doc comment > - Reflow doc comment as suggested > - Revert for readability > - Merge branch 'master' into 8311170 > - Be consistent with the rest of the change > - Fix reported bugs > - Add even more cases and tidy up > - More cases > - Initial commit I pushed a new commit, 457b9c5, that changes almost 90 files; I realise its huge review cost. Perhaps at this stage, reviewers could glance at that commit, and we could then collectively cherry-pick the most useful changes. FWIW, the tests are green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14738#issuecomment-1633831460 From duke at openjdk.org Thu Jul 13 10:01:04 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 13 Jul 2023 10:01:04 GMT Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown [v2] In-Reply-To: References: <9av18v7LjWdgjmIQNoOlDoT_oj5GcP_ROfGUx5Q9uUE=.30d64de6-5a5b-4799-b358-cd29b61f3b8e@github.com> Message-ID: On Thu, 13 Jul 2023 04:35:31 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as before. > > src/java.base/share/classes/sun/security/rsa/RSASignature.java line 231: > >> 229: RSAUtil.decodeSignature(digestOID, unpadded)); >> 230: } >> 231: } > > I understand where the fallback code came from. As the padding code is exactly the same as engineSign(), the risk may be minimal. With the fallback code, the security concern (time-constant) we cared about will come back. Did you run into testing failure without the fallback doe? Instead of falling back to unpad()/decodeSignature() I suggest to try a new version of encodeSignature() in which you omit putting the null for params into the DER encoding and compare the decrypted message with that, too. Accept if any of the two encodings matches the decrypted one, reject otherwise. This can be done in constant time, although it is not necessary to be constant time as the time of doing it does not depend on any secret. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1262326648 From duke at openjdk.org Thu Jul 13 11:35:16 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 13 Jul 2023 11:35:16 GMT Subject: RFR: 8302017: Allocate BadPaddingException only if it will be thrown [v2] In-Reply-To: <9av18v7LjWdgjmIQNoOlDoT_oj5GcP_ROfGUx5Q9uUE=.30d64de6-5a5b-4799-b358-cd29b61f3b8e@github.com> References: <9av18v7LjWdgjmIQNoOlDoT_oj5GcP_ROfGUx5Q9uUE=.30d64de6-5a5b-4799-b358-cd29b61f3b8e@github.com> Message-ID: On Wed, 12 Jul 2023 23:12:18 GMT, Valerie Peng wrote: >> This change refactors the RSAPadding class to return an output record containing the status instead of relying on exception object to indicate a failure. >> >> Thanks in advance for review~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as before. src/java.base/share/classes/sun/security/rsa/RSASignature.java line 223: > 221: byte[] decrypted = RSACore.rsa(sigBytes, publicKey); > 222: > 223: boolean status = MessageDigest.isEqual(padded, decrypted); You should compare only the relevant parts (mask out the random padding bytes). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1262427325 From mdonovan at openjdk.org Thu Jul 13 12:14:20 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 13 Jul 2023 12:14:20 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v2] In-Reply-To: References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com>

<0gMLhW0oFZMkxjclDGbIJLyh0vhqr8e2cP6Cimb2w9w=.408d9450-09fd-4276-868e-b28a175a60b9@github.com>

<2XuGMZnGZ8-4EACWi1YLy8rXEmWHwulFOK6QJkcPNrk=.80ab389c-ecf1-4597-83c1-1ff02b884124@github.com> Message-ID: On Wed, 21 Jun 2023 12:04:34 GMT, Matthew Donovan wrote: >> There's a bit of a history with SSLSocket closures since the new handshaker was brought into JDK11. Some of it dealt with synchronization, others with properly handling full vs. half-duplex closes. You may want to look up some of the bug history on changes surrounding the SSLSocket closures just to make sure we don't undo any fixes that were previously integrated. As Xuelei's comment indicates, this is a delicate part of the handshaker. > > I reverted the changes to SSLEngineImpl and looked at the history of SSLSocketImpl and TransportContext but didn't see anything that I would be undoing with this change. Sorry for the delay on any updates here. I updated this branch and verified the tests still pass. I ran jdk_security3 tests from test/jdk/TEST.groups. Is there anything else I should do to test this change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1262468647 From mdonovan at openjdk.org Thu Jul 13 12:34:02 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 13 Jul 2023 12:34:02 GMT Subject: RFR: 8310070: Test: javax/net/ssl/DTLS/DTLSWontNegotiateV10.java timed out In-Reply-To: References: