From weijun at openjdk.java.net Wed Dec 1 00:51:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 1 Dec 2021 00:51:39 GMT Subject: Integrated: 8272162: S4U2Self ticket without forwardable flag In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang wrote: > The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set, but some versions of Windows Server do not set the forwardable flag in a S4U2self response and accept it in a S4U2proxy request. > > There are 2 commits now. The 1st is a refactoring that sends more info into the methods (Ex: `KdcComm::send(byte[])` -> `KdcComm::send(KrbKdcReq)`, and `Ticket` -> `Credentials` in multiple places) so that inside `KdcComm::send` there is enough info to decide how to deal with various errors. The 2nd is the actual fix to this issue, i.e. ignore the flag and retry another KDC. This pull request has now been integrated. Changeset: ab867f6c Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/ab867f6c7c578ae7e65af2989b6836d523a41c5a Stats: 413 lines in 17 files changed: 218 ins; 38 del; 157 mod 8272162: S4U2Self ticket without forwardable flag Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/6082 From weijun at openjdk.java.net Wed Dec 1 01:01:31 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 1 Dec 2021 01:01:31 GMT Subject: RFR: 8276660: Scalability bottleneck in java.security.Provider.getService() [v2] In-Reply-To: References:

Message-ID: On Wed, 24 Nov 2021 21:17:34 GMT, Valerie Peng wrote: >> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service. >> >> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". >> >> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass. >> >> Please review and thanks in advance, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Updated to use pattern matching with instanceof operator. Since all legacy registration are done eagerly, I assume the original `ensureLegacyParsed()` method should be super fast now. Maybe we don't need to change any synchronized keyword. ------------- PR: https://git.openjdk.java.net/jdk/pull/6513 From weijun at openjdk.java.net Wed Dec 1 01:04:34 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 1 Dec 2021 01:04:34 GMT Subject: Integrated: 8231107: Allow store password to be null when saving a PKCS12 KeyStore In-Reply-To: References: Message-ID: <4PWegQ4sEk9thgrQG3fmufcgBM0P_5CnRT_2K4aGyyA=.b9bfc012-42a5-477d-ac4d-a59294025088@github.com> On Thu, 14 Oct 2021 14:43:32 GMT, Weijun Wang wrote: > You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`. > > Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must be retained (at the moment) because the tool is launched with BOOT_JDK. This pull request has now been integrated. Changeset: 7049c13c Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/7049c13cf4bf4cdfcd0c8f0fa96bf4c3748ae1e7 Stats: 70 lines in 4 files changed: 37 ins; 16 del; 17 mod 8231107: Allow store password to be null when saving a PKCS12 KeyStore Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/5950 From weijun at openjdk.java.net Wed Dec 1 01:15:27 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 1 Dec 2021 01:15:27 GMT Subject: RFR: 8225181: KeyStore should have a getAttributes method [v5] In-Reply-To: References: Message-ID: > Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - final spec change - Merge branch 'master' into 8225181 - Merge branch 'master' into 8225181 - redine spec - more clear and precise spec - clarification on protected attributes - 8225181: KeyStore should have a getAttributes method 8225181: KeyStore should have a getAttributes method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6026/files - new: https://git.openjdk.java.net/jdk/pull/6026/files/901bdf83..702168db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=03-04 Stats: 929909 lines in 2271 files changed: 483097 ins; 432951 del; 13861 mod Patch: https://git.openjdk.java.net/jdk/pull/6026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6026/head:pull/6026 PR: https://git.openjdk.java.net/jdk/pull/6026 From weijun at openjdk.java.net Wed Dec 1 01:15:28 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 1 Dec 2021 01:15:28 GMT Subject: RFR: 8225181: KeyStore should have a getAttributes method [v4] In-Reply-To: References:

Message-ID: On Thu, 4 Nov 2021 19:34:50 GMT, Weijun Wang wrote: >> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > redine spec New commits pushed. Except for the merge commits, the only change is method spec update to match the text in the approved CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6026 From mstjohns at comcast.net Wed Dec 1 03:01:58 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 30 Nov 2021 22:01:58 -0500 Subject: RFR: 8225181: KeyStore should have a getAttributes method [v5] In-Reply-To: References:

Message-ID: <93aeca60-53e4-fe1b-67f5-8886a675e338@comcast.net> Hi - Generically, PKCS12 doesn't require an alias (friendlyName) for a particular Bag, but does permit it. Which means that getAttributes(String alias) could fail on a legal PKCS12.? It may be worthwhile to add a Set KeyStore::getAttributes(int bagNumber) method. Mike On 11/30/2021 8:15 PM, Weijun Wang wrote: >> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password. > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - final spec change > - Merge branch 'master' into 8225181 > - Merge branch 'master' into 8225181 > - redine spec > - more clear and precise spec > - clarification on protected attributes > - 8225181: KeyStore should have a getAttributes method > > 8225181: KeyStore should have a getAttributes method > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/6026/files > - new: https://git.openjdk.java.net/jdk/pull/6026/files/901bdf83..702168db > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=04 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=03-04 > > Stats: 929909 lines in 2271 files changed: 483097 ins; 432951 del; 13861 mod > Patch: https://git.openjdk.java.net/jdk/pull/6026.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/6026/head:pull/6026 > > PR: https://git.openjdk.java.net/jdk/pull/6026 From weijun.wang at oracle.com Wed Dec 1 03:07:30 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 1 Dec 2021 03:07:30 +0000 Subject: RFR: 8225181: KeyStore should have a getAttributes method [v5] In-Reply-To: <93aeca60-53e4-fe1b-67f5-8886a675e338@comcast.net> References:

<93aeca60-53e4-fe1b-67f5-8886a675e338@comcast.net> Message-ID: <497A535B-78B6-4A6E-A2C3-B008D8AC3530@oracle.com> My understanding is that Java's PKCS12KeyStore will fabricate an alias string if there is no friendlyName, since every entry inside a KeyStore object must have an alias. I'll take some look tomorrow. Thanks, Max > On Nov 30, 2021, at 10:01 PM, Michael StJohns wrote: > > Hi - > > Generically, PKCS12 doesn't require an alias (friendlyName) for a particular Bag, but does permit it. Which means that getAttributes(String alias) could fail on a legal PKCS12. It may be worthwhile to add a Set KeyStore::getAttributes(int bagNumber) method. > > Mike > > On 11/30/2021 8:15 PM, Weijun Wang wrote: >>> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password. >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - final spec change >> - Merge branch 'master' into 8225181 >> - Merge branch 'master' into 8225181 >> - redine spec >> - more clear and precise spec >> - clarification on protected attributes >> - 8225181: KeyStore should have a getAttributes method >> 8225181: KeyStore should have a getAttributes method >> >> ------------- >> >> Changes: >> - all: https://git.openjdk.java.net/jdk/pull/6026/files >> - new: https://git.openjdk.java.net/jdk/pull/6026/files/901bdf83..702168db >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=04 >> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=03-04 >> >> Stats: 929909 lines in 2271 files changed: 483097 ins; 432951 del; 13861 mod >> Patch: https://git.openjdk.java.net/jdk/pull/6026.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/6026/head:pull/6026 >> >> PR: https://git.openjdk.java.net/jdk/pull/6026 > > From ssahoo at openjdk.java.net Wed Dec 1 06:35:43 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 1 Dec 2021 06:35:43 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out Message-ID: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> This Test gets timeout during low cpu availability. It is modified to support extended timeout period during JTREG execution. ------------- Commit messages: - 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out - 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out Changes: https://git.openjdk.java.net/jdk/pull/6626/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6626&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277353 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6626/head:pull/6626 PR: https://git.openjdk.java.net/jdk/pull/6626 From weijun at openjdk.java.net Wed Dec 1 15:15:28 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 1 Dec 2021 15:15:28 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out In-Reply-To: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> Message-ID: On Wed, 1 Dec 2021 06:26:58 GMT, Sibabrata Sahoo wrote: > This Test gets timeout during low cpu availability. It is modified to support extended timeout period during JTREG execution. Can you lower the `threadsFactor` or `duration`? Or set an upper limit for `nTasks`? ------------- PR: https://git.openjdk.java.net/jdk/pull/6626 From weijun at openjdk.java.net Wed Dec 1 17:11:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 1 Dec 2021 17:11:43 GMT Subject: RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa Message-ID: Update Public Suffix List data to the latest version at https://github.com/publicsuffix/list. ------------- Commit messages: - 8255266: 2021-11-27 public suffix list update v 3c213aa Changes: https://git.openjdk.java.net/jdk/pull/6643/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6643&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255266 Stats: 1254 lines in 5 files changed: 887 ins; 215 del; 152 mod Patch: https://git.openjdk.java.net/jdk/pull/6643.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6643/head:pull/6643 PR: https://git.openjdk.java.net/jdk/pull/6643 From weijun at openjdk.java.net Wed Dec 1 17:38:37 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 1 Dec 2021 17:38:37 GMT Subject: RFR: 8275082: Update XML Security for Java to 2.3.0 Message-ID: Import Apache Santuario 2.3.0 without the secure validation changes since in OpenJDK we are using the `jdk.xml.dsig.secureValidationPolicy` security property for XML Signature secure validation protection. Two commits are pushed: - 2.3.0: Import 2.3.0 code changes - revert: revert the Santuario secure validation changes ------------- Commit messages: - revert - 2.3.0 Changes: https://git.openjdk.java.net/jdk/pull/6644/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6644&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275082 Stats: 406 lines in 32 files changed: 54 ins; 267 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/6644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6644/head:pull/6644 PR: https://git.openjdk.java.net/jdk/pull/6644 From valeriep at openjdk.java.net Wed Dec 1 18:10:00 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 1 Dec 2021 18:10:00 GMT Subject: RFR: 8276660: Scalability bottleneck in java.security.Provider.getService() [v3] In-Reply-To: References: Message-ID: <9B6vK6bURls5Vfk5WRbQBUDuJJwjV9ij9njZT2SuN_I=.45a72e57-62cb-41a6-8da9-8dc5bd092851@github.com> > It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service. > > Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". > > The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass. > > Please review and thanks in advance, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update for address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6513/files - new: https://git.openjdk.java.net/jdk/pull/6513/files/37dc1d9f..178161d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6513&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6513&range=01-02 Stats: 24 lines in 1 file changed: 5 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6513.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6513/head:pull/6513 PR: https://git.openjdk.java.net/jdk/pull/6513 From bchristi at openjdk.java.net Wed Dec 1 18:21:04 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 1 Dec 2021 18:21:04 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v2] In-Reply-To: References: Message-ID: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge branch 'master' into 8276447 - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - Indicate that runFinalizers does nothing if finalization is disabled or removed - Fix @since on @Deprecated for java.lang.Enum - ... and 22 more: https://git.openjdk.java.net/jdk/compare/a363b7b9...e4986a48 ------------- Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=01 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From bchristi at openjdk.java.net Wed Dec 1 19:23:59 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 1 Dec 2021 19:23:59 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v3] In-Reply-To: References: Message-ID: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Merge branch 'master' into 8276447 - Merge branch 'master' into 8276447 - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - Indicate that runFinalizers does nothing if finalization is disabled or removed - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674 ------------- Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=02 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From ssahoo at openjdk.java.net Wed Dec 1 19:32:27 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 1 Dec 2021 19:32:27 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out In-Reply-To: References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> Message-ID: <-1XBp6JiiqgD7WCk_V3z8NovGNS1LScKU5vRgM4muBw=.86f26cb4-6150-44a7-b076-b63e1ea53221@github.com> On Wed, 1 Dec 2021 15:12:16 GMT, Weijun Wang wrote: > Can you lower the `threadsFactor` or `duration`? Or set an upper limit for `nTasks`? I can reduce the threadFactor and duration to close to half(threadsFactor=2 and duration=2 Or hardcode nTasks=20) and i think there still will be enough threads to verify threadsafety. In that case default JTREG timeout period should be enough and no need for any additional timeout with @run tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/6626 From valeriep at openjdk.java.net Wed Dec 1 21:49:40 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 1 Dec 2021 21:49:40 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 Message-ID: PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE, it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not explicitly specified in config. In addition, PKCS#11 v3.0 defines a new API for cancelling session operations, so I've also updated various classes to call this new API if the PKCS#11 library version is 3.0. Otherwise, these classes will try to cancel by finishing off current operations as before. The support for the new C_LoginUser() has not been tested, so I commented it out for now. Given the current release schedule, support for other new PKCS#11 APIs (such as message-based ones and parameters structure) and options for C_GetInterface (if needed) will be handled later. I validated the current changes against different NSS releases (supports PKCS#11 v2.40 and v3..0 respectively) with existing regression tests. Thanks, Valerie ------------- Commit messages: - 8255409: Support the new APIs in PKCS#11 v3.0 Changes: https://git.openjdk.java.net/jdk/pull/6655/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255409 Stats: 706 lines in 17 files changed: 552 ins; 17 del; 137 mod Patch: https://git.openjdk.java.net/jdk/pull/6655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6655/head:pull/6655 PR: https://git.openjdk.java.net/jdk/pull/6655 From kcr at openjdk.java.net Wed Dec 1 21:58:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Dec 2021 21:58:22 GMT Subject: RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 17:03:24 GMT, Weijun Wang wrote: > Update Public Suffix List data to the latest version at https://github.com/publicsuffix/list. This is not a formal review, but it looks good to me. I verified that the new file matches the one from the referenced upstream commit. I also did a local JDK build with this fix, and then used that in a local test build of FX 8 for [JDK-8277734](https://bugs.openjdk.java.net/browse/JDK-8277734). All passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6643 From mstjohns at comcast.net Wed Dec 1 23:28:45 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 1 Dec 2021 18:28:45 -0500 Subject: RFR: 8225181: KeyStore should have a getAttributes method [v5] In-Reply-To: <497A535B-78B6-4A6E-A2C3-B008D8AC3530@oracle.com> References:

<93aeca60-53e4-fe1b-67f5-8886a675e338@comcast.net> <497A535B-78B6-4A6E-A2C3-B008D8AC3530@oracle.com> Message-ID: On 11/30/2021 10:07 PM, Wei-Jun Wang wrote: > My understanding is that Java's PKCS12KeyStore will fabricate an alias string if there is no friendlyName, since every entry inside a KeyStore object must have an alias. I'll take some look tomorrow. Ah - I see it now in PKCS12KeyStore - it assigns an "unfriendlyName" as an alias if "friendlyName" is missing - basically "0", "1", etc. Thanks - Mike > > Thanks, > Max > >> On Nov 30, 2021, at 10:01 PM, Michael StJohns wrote: >> >> Hi - >> >> Generically, PKCS12 doesn't require an alias (friendlyName) for a particular Bag, but does permit it. Which means that getAttributes(String alias) could fail on a legal PKCS12. It may be worthwhile to add a Set KeyStore::getAttributes(int bagNumber) method. >> >> Mike >> >> On 11/30/2021 8:15 PM, Weijun Wang wrote: >>>> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password. >>> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >>> >>> - final spec change >>> - Merge branch 'master' into 8225181 >>> - Merge branch 'master' into 8225181 >>> - redine spec >>> - more clear and precise spec >>> - clarification on protected attributes >>> - 8225181: KeyStore should have a getAttributes method >>> 8225181: KeyStore should have a getAttributes method >>> >>> ------------- >>> >>> Changes: >>> - all: https://git.openjdk.java.net/jdk/pull/6026/files >>> - new: https://git.openjdk.java.net/jdk/pull/6026/files/901bdf83..702168db >>> >>> Webrevs: >>> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=04 >>> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6026&range=03-04 >>> >>> Stats: 929909 lines in 2271 files changed: 483097 ins; 432951 del; 13861 mod >>> Patch: https://git.openjdk.java.net/jdk/pull/6026.diff >>> Fetch: git fetch https://git.openjdk.java.net/jdk pull/6026/head:pull/6026 >>> >>> PR: https://git.openjdk.java.net/jdk/pull/6026 >> From weijun at openjdk.java.net Thu Dec 2 00:29:28 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 2 Dec 2021 00:29:28 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out In-Reply-To: <-1XBp6JiiqgD7WCk_V3z8NovGNS1LScKU5vRgM4muBw=.86f26cb4-6150-44a7-b076-b63e1ea53221@github.com> References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> <-1XBp6JiiqgD7WCk_V3z8NovGNS1LScKU5vRgM4muBw=.86f26cb4-6150-44a7-b076-b63e1ea53221@github.com> Message-ID: On Wed, 1 Dec 2021 19:29:36 GMT, Sibabrata Sahoo wrote: > > Can you lower the `threadsFactor` or `duration`? Or set an upper limit for `nTasks`? > > I can reduce the threadFactor and duration to close to half(threadsFactor=2 and duration=2 Or hardcode nTasks=20) and i think there still will be enough threads to verify threadsafety. In that case default JTREG timeout period should be enough and no need for any additional timeout with @run tag. Maybe you can contact the author of this test to see if that's enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/6626 From smarks at openjdk.java.net Thu Dec 2 01:26:30 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 2 Dec 2021 01:26:30 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v3] In-Reply-To: References:

Message-ID: On Thu, 2 Dec 2021 00:09:31 GMT, Sergey Bylokhov wrote: > I have a question related to the custom cacerts which can be added to the OpenJDK bundle. How do you pass the tests like test/jdk/sun/security/lib/cacerts/VerifyCACerts.java using that custom jdk bundle? Probably we can add an additional configuration to that test so it will check the custom cacerts passed to the build as well? @mrserb So VerifyCACerts is specific to the make/data/cacerts certificates, the README specifically states there that when those are updated VerifyCACerts needs updating. It checks things like fingerprints etc.. If a developer or other provider decide to provide their own cacerts file, then it is up to them to have verified and trust those certificates. They won't run the VerifyCACerts which is specific to the openjdk certs. This is the case at Adoptium for example, which uses the Mozilla trusted CA certs. ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From aleonard at openjdk.java.net Thu Dec 2 12:13:03 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 2 Dec 2021 12:13:03 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References: Message-ID: > Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation Signed-off-by: Andrew Leonard - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation Signed-off-by: Andrew Leonard - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation Signed-off-by: Andrew Leonard ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6647/files - new: https://git.openjdk.java.net/jdk/pull/6647/files/1084c4e1..16c5ca6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6647&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6647&range=00-01 Stats: 1879 lines in 62 files changed: 1045 ins; 297 del; 537 mod Patch: https://git.openjdk.java.net/jdk/pull/6647.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6647/head:pull/6647 PR: https://git.openjdk.java.net/jdk/pull/6647 From aleonard at openjdk.java.net Thu Dec 2 12:13:07 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 2 Dec 2021 12:13:07 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

Message-ID: On Wed, 1 Dec 2021 18:47:41 GMT, Erik Joelsson wrote: >> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation >> >> Signed-off-by: Andrew Leonard >> - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc >> - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation >> >> Signed-off-by: Andrew Leonard >> - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation >> >> Signed-off-by: Andrew Leonard > > make/autoconf/jdk-options.m4 line 176: > >> 174: [specify alternative cacerts source folder containing certificates])]) >> 175: AC_MSG_CHECKING([for cacerts source]) >> 176: if test "x$with_cacerts_src" == x; then > > Before this if block, please assign an empty value to CACERTS_SRC. Otherwise, if the user happens to have that variable set in the environment, that value will get recorded by configure, which is usually not something we want. done ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From abakhtin at openjdk.java.net Thu Dec 2 12:54:24 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 2 Dec 2021 12:54:24 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out In-Reply-To: <-1XBp6JiiqgD7WCk_V3z8NovGNS1LScKU5vRgM4muBw=.86f26cb4-6150-44a7-b076-b63e1ea53221@github.com> References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> <-1XBp6JiiqgD7WCk_V3z8NovGNS1LScKU5vRgM4muBw=.86f26cb4-6150-44a7-b076-b63e1ea53221@github.com> Message-ID: On Wed, 1 Dec 2021 19:29:36 GMT, Sibabrata Sahoo wrote: >> Can you lower the `threadsFactor` or `duration`? Or set an upper limit for `nTasks`? > >> Can you lower the `threadsFactor` or `duration`? Or set an upper limit for `nTasks`? > > I can reduce the threadFactor and duration to close to half(threadsFactor=2 and duration=2 Or hardcode nTasks=20) and i think there still will be enough threads to verify threadsafety. In that case default JTREG timeout period should be enough and no need for any additional timeout with @run tag. Hi @sisahoo, Yes, I think the number of threads and duration can be lowered. For example like this: diff --git a/test/jdk/java/security/MessageDigest/ThreadSafetyTest.java b/test/jdk/java/security/MessageDigest/ThreadSafetyTest.java index 41ecbca2677..f179bd54257 100644 --- a/test/jdk/java/security/MessageDigest/ThreadSafetyTest.java +++ b/test/jdk/java/security/MessageDigest/ThreadSafetyTest.java @@ -25,7 +25,7 @@ * @test * @bug 8241960 * @summary Confirm that java.security.MessageDigest is thread-safe after clone. - * @run main/othervm ThreadSafetyTest 5 4 + * @run main/othervm ThreadSafetyTest 5 2 */ import java.security.MessageDigest; @@ -56,7 +56,7 @@ public class ThreadSafetyTest { duration = Integer.parseInt(args[1]); } int nProcessors = Runtime.getRuntime().availableProcessors(); - int nTasks = nProcessors * threadsFactor; + int nTasks = Math.min(nProcessors, 4) * threadsFactor; System.out.println("Testing with " + nTasks + " threads on " + nProcessors + " processors for " + duration + ------------- PR: https://git.openjdk.java.net/jdk/pull/6626 From erikj at openjdk.java.net Thu Dec 2 13:58:25 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 2 Dec 2021 13:58:25 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

Message-ID: <9birWuJ4GIzSwQHZSrNlLO2fvrHy7bAxvEBqq4t80vc=.c7f7884e-c33e-45ff-b8d6-e3ee84efdb74@github.com> On Thu, 2 Dec 2021 14:29:00 GMT, Sean Mullan wrote: > I don?t have any major concerns with this change, as long as the default cacerts are still the ones that are in the JDK. As an aside, using Mozilla's root certificates might be fine for TLS certificates, but if you need to support code signing certificates you may run into issues with missing CAs as Mozilla's Root program does not support that use case. Also, by overriding the roots included in the JDK, you are taking on the responsibility (which is significant, in my opinion) of ensuring that those roots are trusted and have not been compromised, revoked, have weak keys, etc. @seanjmullan Thanks Sean, I'll pass your comment on, cheers Andrew ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From dcubed at openjdk.java.net Thu Dec 2 15:18:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 2 Dec 2021 15:18:29 GMT Subject: RFR: 8278099: two sun/security/pkcs11/Signature tests failed with AssertionError In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 01:20:30 GMT, Valerie Peng wrote: > Can someone help reviewing this trivial one-line fix? The assert check in CK_MECHANISM.java is too strict and fail unexpectedly when digest-specific PSS signature mechanisms are supported by the underlying PKCS#11 library. The fix is to remove this assert check. No new regression test added with this fix as this is already covered by existing regression tests. > > Thanks, > Valerie Have you verified that this fix works on an Oracle_Linux_8.4 test machine? And I agree that this is a trivial fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/6656 From aleonard at openjdk.java.net Thu Dec 2 15:40:33 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 2 Dec 2021 15:40:33 GMT Subject: Integrated: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard wrote: > Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool. > > Signed-off-by: Andrew Leonard This pull request has now been integrated. Changeset: dc2abc9f Author: Andrew Leonard URL: https://git.openjdk.java.net/jdk/commit/dc2abc9f05c2b7c52aeb242082359c48963f9854 Stats: 22 lines in 3 files changed: 22 ins; 0 del; 0 mod 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From ihse at openjdk.java.net Thu Dec 2 17:39:29 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 2 Dec 2021 17:39:29 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Dec 2021 17:33:49 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation >> >> Signed-off-by: Andrew Leonard >> - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc >> - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation >> >> Signed-off-by: Andrew Leonard >> - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation >> >> Signed-off-by: Andrew Leonard > > make/modules/java.base/Gendata.gmk line 76: > >> 74: ifneq ($(CACERTS_SRC), ) >> 75: GENDATA_CACERTS_SRC := $(CACERTS_SRC) >> 76: endif > > Does this even work?! You are reassigning the variable after it has been used. The := assignment means that it not a macro. I would have expected to see something like: ifneq ($(CACERTS_SRC), ) GENDATA_CACERTS_SRC := $(CACERTS_SRC) else GENDATA_CACERTS_SRC := $(TOPDIR)/make/data/cacerts/ endif at line 63. ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From aleonard at openjdk.java.net Thu Dec 2 17:50:15 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 2 Dec 2021 17:50:15 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Dec 2021 17:35:36 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/Gendata.gmk line 76: >> >>> 74: ifneq ($(CACERTS_SRC), ) >>> 75: GENDATA_CACERTS_SRC := $(CACERTS_SRC) >>> 76: endif >> >> Does this even work?! You are reassigning the variable after it has been used. The := assignment means that it not a macro. > > I would have expected to see something like: > > ifneq ($(CACERTS_SRC), ) > GENDATA_CACERTS_SRC := $(CACERTS_SRC) > else > GENDATA_CACERTS_SRC := $(TOPDIR)/make/data/cacerts/ > endif > > at line 63. you make a valid point, but i've tested this numerous times, but let me check again ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From aleonard at openjdk.java.net Thu Dec 2 17:50:15 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 2 Dec 2021 17:50:15 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Dec 2021 17:46:35 GMT, Andrew Leonard wrote: >> I would have expected to see something like: >> >> ifneq ($(CACERTS_SRC), ) >> GENDATA_CACERTS_SRC := $(CACERTS_SRC) >> else >> GENDATA_CACERTS_SRC := $(TOPDIR)/make/data/cacerts/ >> endif >> >> at line 63. > > you make a valid point, but i've tested this numerous times, but let me check again my assumption was the recipe gets resolved later ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From aleonard at openjdk.java.net Thu Dec 2 18:07:16 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 2 Dec 2021 18:07:16 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Dec 2021 17:48:04 GMT, Andrew Leonard wrote: >> you make a valid point, but i've tested this numerous times, but let me check again > > my assumption was the recipe gets resolved later this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. but i'm going to double check I was checking the resultant cacerts correctly in my tests ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From erikj at openjdk.java.net Thu Dec 2 18:49:18 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 2 Dec 2021 18:49:18 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

Message-ID: <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com> On Thu, 2 Dec 2021 18:03:50 GMT, Andrew Leonard wrote: >> my assumption was the recipe gets resolved later > > this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html > > This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. > > but i'm going to double check I was checking the resultant cacerts correctly in my tests Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass. I very much agree with Magnus that this conditional belongs around line 63. ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From aleonard at openjdk.java.net Thu Dec 2 19:15:22 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 2 Dec 2021 19:15:22 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com> References:

<7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com> Message-ID: On Thu, 2 Dec 2021 18:46:09 GMT, Erik Joelsson wrote: >> this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html >> >> This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. >> >> but i'm going to double check I was checking the resultant cacerts correctly in my tests > > Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass. > > I very much agree with Magnus that this conditional belongs around line 63. yes, thanks, feeling rather stupid here! i'll raise an issue to fix ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From valeriep at openjdk.java.net Thu Dec 2 19:34:20 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 2 Dec 2021 19:34:20 GMT Subject: RFR: 8278099: two sun/security/pkcs11/Signature tests failed with AssertionError In-Reply-To: References:

Message-ID: <4CyoArEUBBNKVLG5k1V69BVqTvdwy6tax5pviFPGdIk=.d41be135-3b3b-4f4d-b95e-cac81725dc9a@github.com> On Thu, 2 Dec 2021 01:42:58 GMT, Weijun Wang wrote: > Not a PKCS11 expert, but does a "digest-specific PSS signature mechanism" needs `setParameter` anymore? Or, must it be the same as the existing parameters dictated by the specified digest? Previously when PSS support is added, the NSS library that we have does not support digest-specific PSS signatures. Now that some machine starts failing due to this assert and passes without this assert, it at least confirms that these digest-specific PSS signature mechanisms still work with the setParameter() call. I will take a closer look at these new mechanisms and see if any changes are needed. Best to remove this assert ASAP for a clean tier 2 result... ------------- PR: https://git.openjdk.java.net/jdk/pull/6656 From valeriep at openjdk.java.net Thu Dec 2 19:34:21 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 2 Dec 2021 19:34:21 GMT Subject: Integrated: 8278099: two sun/security/pkcs11/Signature tests failed with AssertionError In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 01:20:30 GMT, Valerie Peng wrote: > Can someone help reviewing this trivial one-line fix? The assert check in CK_MECHANISM.java is too strict and fail unexpectedly when digest-specific PSS signature mechanisms are supported by the underlying PKCS#11 library. The fix is to remove this assert check. No new regression test added with this fix as this is already covered by existing regression tests. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 669c90e2 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/669c90e23b2397fa9fb4388e8380c95c3b19eb48 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8278099: two sun/security/pkcs11/Signature tests failed with AssertionError Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/6656 From ihse at openjdk.java.net Thu Dec 2 19:57:18 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 2 Dec 2021 19:57:18 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

<7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com> Message-ID: On Thu, 2 Dec 2021 19:12:37 GMT, Andrew Leonard wrote: >> Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass. >> >> I very much agree with Magnus that this conditional belongs around line 63. > > yes, thanks, feeling rather stupid here! i'll raise an issue to fix @andrew-m-leonard Don't be. Make is a horrible programming language, both syntactically and semantically. It's taken me years to be somewhat comfortable with it, and often I just manage to get it right only by sticking to a few, well-proven and battle-hardened patterns. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From valeriep at openjdk.java.net Thu Dec 2 20:31:12 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 2 Dec 2021 20:31:12 GMT Subject: RFR: 8275082: Update XML Security for Java to 2.3.0 In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 17:31:37 GMT, Weijun Wang wrote: > Import Apache Santuario 2.3.0 without the secure validation changes since in OpenJDK we are using the `jdk.xml.dsig.secureValidationPolicy` security property for XML Signature secure validation protection. > > Two commits are pushed: > > - 2.3.0: Import 2.3.0 code changes > - revert: revert the Santuario secure validation changes The revert is done manually and covered by existing regression tests? May need to add a noreg-xxx label ------------- PR: https://git.openjdk.java.net/jdk/pull/6644 From valeriep at openjdk.java.net Thu Dec 2 20:40:22 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 2 Dec 2021 20:40:22 GMT Subject: RFR: 8275082: Update XML Security for Java to 2.3.0 In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 17:31:37 GMT, Weijun Wang wrote: > Import Apache Santuario 2.3.0 without the secure validation changes since in OpenJDK we are using the `jdk.xml.dsig.secureValidationPolicy` security property for XML Signature secure validation protection. > > Two commits are pushed: > > - 2.3.0: Import 2.3.0 code changes > - revert: revert the Santuario secure validation changes src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Policy.java line 53: > 51: private static Map minKeyMap; > 52: private static boolean noDuplicateIds; > 53: private static boolean noRMLoops; Does it really make any difference, moving the initialization to the initialize() method? The comment on line 46 no longer apply now that the initialization is relocated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6644 From duke at openjdk.java.net Thu Dec 2 21:02:40 2021 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 2 Dec 2021 21:02:40 GMT Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java Message-ID: JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java ------------- Commit messages: - Merge branch 'master' into JDK-8276681 - Fix missing '@' in javadoc for JDK-8276681 Changes: https://git.openjdk.java.net/jdk/pull/6486/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6486&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276681 Stats: 13 lines in 10 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/6486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6486/head:pull/6486 PR: https://git.openjdk.java.net/jdk/pull/6486 From lancea at openjdk.java.net Thu Dec 2 21:08:17 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 2 Dec 2021 21:08:17 GMT Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java In-Reply-To: References: Message-ID: On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing wrote: > JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6486 From duke at openjdk.java.net Thu Dec 2 21:25:54 2021 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 2 Dec 2021 21:25:54 GMT Subject: Integrated: JDK-8276681: Additional malformed Javadoc inline tags in JDK source In-Reply-To: References: Message-ID: On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing wrote: > JDK-8276681: Additional malformed Javadoc inline tags in JDK source This pull request has now been integrated. Changeset: b8ac0d20 Author: Tim Prinzing Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/b8ac0d20ceec26b3a1dd0b9577817fa6320ea9ef Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod 8276681: Additional malformed Javadoc inline tags in JDK source Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/6486 From duke at openjdk.java.net Thu Dec 2 21:25:53 2021 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 2 Dec 2021 21:25:53 GMT Subject: RFR: JDK-8276681: Additional malformed Javadoc inline tags in JDK source [v2] In-Reply-To: References: Message-ID: > JDK-8276681: Additional malformed Javadoc inline tags in JDK source Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8276681 - Merge branch 'master' into JDK-8276681 - Fix missing '@' in javadoc for JDK-8276681 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6486/files - new: https://git.openjdk.java.net/jdk/pull/6486/files/e8071197..8eaf05bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6486&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6486&range=00-01 Stats: 29529 lines in 653 files changed: 17761 ins; 7341 del; 4427 mod Patch: https://git.openjdk.java.net/jdk/pull/6486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6486/head:pull/6486 PR: https://git.openjdk.java.net/jdk/pull/6486 From mbalao at openjdk.java.net Thu Dec 2 21:31:52 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 2 Dec 2021 21:31:52 GMT Subject: RFR: 8271566: DSA signature length value is not accurate in P11Signature [v3] In-Reply-To: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> Message-ID: > As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4. > > Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed. > > No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8271566 Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8271566: DSA signature length value is not accurate in P11Signature (Webrev.02 based) - Merge branch 'master' into JDK-8271566 - Revert 8271566: DSA signature length value is not accurate in P11Signature - Revert P11Key static inner classes refactorings. - P11Key static inner classes refactorings. - 8271566: DSA signature length value is not accurate in P11Signature ------------- Changes: https://git.openjdk.java.net/jdk/pull/4961/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4961&range=02 Stats: 682 lines in 4 files changed: 380 ins; 121 del; 181 mod Patch: https://git.openjdk.java.net/jdk/pull/4961.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4961/head:pull/4961 PR: https://git.openjdk.java.net/jdk/pull/4961 From mbalao at openjdk.java.net Thu Dec 2 21:53:23 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 2 Dec 2021 21:53:23 GMT Subject: RFR: 8271566: DSA signature length value is not accurate in P11Signature [v2] In-Reply-To: References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> <8vTXZjaSwUZ3IoHJcfC2cllpmm75dey2vtvVenwo1I4=.8e9ed87b-36de-42c6-b70b-554ba2db23ab@github.com> Message-ID: <3QULgzggAtGLP5n2mZd7SzVtcdxLhRMJzhfIrNxvgyw=.dda06c44-e5fe-4814-89eb-b59dcb6fa867@github.com> On Tue, 30 Nov 2021 19:48:19 GMT, Valerie Peng wrote: >> Hmm, thinking more about "internal"/"opaque", given this is naming for the parent, maybe "internal" is more correct. The non-sensitive keys are encapsulated by the children classes and is still an instance of the parent. If you name the parent class w/ "opaque" suffix, it looks misleading/confusing. The opaqueness is implied by the implementation instead of the properties of the objects. > >> Hi @valeriepeng , >> >> Yes, I just verified how serialization works for P11Keys and your 'transient' change makes sense to me now. >> >> I see your point about Internal/Opaque. Keep 'Internal' then if you prefer. The whole inheritance relationship between these classes sounds a bit weird to me, beyond the names we call them. I wouldn't suggest any additional changes there now, though. >> >> It looks to me that the only 2 changes expected for Webrev.02 are: 1) P11RSAPrivateNonCRTKey to use the parent's protected 'n'; and 2) removal of 'long errorCode = e.getErrorCode();'. >> >> Now that we almost have the changeset ready, I'm not sure of how to proceed with the push. Do you want me to commit Webrev.02 in my own branch and use the 'Co-authored-by:' header? If we do that, do we still need an additional Reviewer? Do you prefer to have your own branch? Please let me know of how to move forward. >> >> Martin.- > > You can just incorporate the changes on your branch and proceeds with me being the reviewer. The webrev that I sent u is just an easier way to express the comments/feedbacks. > > Thanks, > Valerie Hi @valeriepeng I've reverted the initial 2 changesets on this branch, rebased to the latest commit on 'master' (git merge), applied Webrev.02 as discussed and added the test case from the initial commit (with the change from the 2nd commit applied on top). I've noticed no regressions in jdk/sun/security/pkcs11. Does it look good to you? Thanks, Martin.- ------------- PR: https://git.openjdk.java.net/jdk/pull/4961 From ssahoo at openjdk.java.net Fri Dec 3 06:14:49 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Fri, 3 Dec 2021 06:14:49 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out [v2] In-Reply-To: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> Message-ID: <4b_-Dz3yRbOwJziNmKdlAsCBuEXLn37aewRH3pVdDG0=.462e6f8d-63f3-4f2b-8100-e6d731fcf379@github.com> > This Test gets timeout during low cpu availability. It is modified to support extended timeout period during JTREG execution. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6626/files - new: https://git.openjdk.java.net/jdk/pull/6626/files/325e351d..9a197651 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6626&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6626&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6626/head:pull/6626 PR: https://git.openjdk.java.net/jdk/pull/6626 From ssahoo at openjdk.java.net Fri Dec 3 06:22:15 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Fri, 3 Dec 2021 06:22:15 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out [v2] In-Reply-To: <4b_-Dz3yRbOwJziNmKdlAsCBuEXLn37aewRH3pVdDG0=.462e6f8d-63f3-4f2b-8100-e6d731fcf379@github.com> References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> <4b_-Dz3yRbOwJziNmKdlAsCBuEXLn37aewRH3pVdDG0=.462e6f8d-63f3-4f2b-8100-e6d731fcf379@github.com> Message-ID: On Fri, 3 Dec 2021 06:14:49 GMT, Sibabrata Sahoo wrote: >> This Test gets timeout during low cpu availability. It is modified to support extended timeout period during JTREG execution. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out Thanks Alexey, I have updated the threadsFactor=4 and duration=2. With this change the Test is completing ~50 seconds in my laptop which is 50% improvement over original. ------------- PR: https://git.openjdk.java.net/jdk/pull/6626 From weijun at openjdk.java.net Fri Dec 3 15:24:54 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 3 Dec 2021 15:24:54 GMT Subject: RFR: 8275082: Update XML Security for Java to 2.3.0 [v2] In-Reply-To: References: Message-ID: <1rndJ3etjd4wF0wf6EKNDM4bAjItCEc0nApENWdwyp4=.3ad0ea6f-3aa8-4532-a385-4fefc89b30b0@github.com> > Import Apache Santuario 2.3.0 without the secure validation changes since in OpenJDK we are using the `jdk.xml.dsig.secureValidationPolicy` security property for XML Signature secure validation protection. > > Two commits are pushed: > > - 2.3.0: Import 2.3.0 code changes > - revert: revert the Santuario secure validation changes Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6644/files - new: https://git.openjdk.java.net/jdk/pull/6644/files/26a8a428..318a7c89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6644&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6644&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6644/head:pull/6644 PR: https://git.openjdk.java.net/jdk/pull/6644 From mullan at openjdk.java.net Fri Dec 3 17:46:18 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 3 Dec 2021 17:46:18 GMT Subject: RFR: 8225181: KeyStore should have a getAttributes method [v5] In-Reply-To: References:

Message-ID: On Wed, 1 Dec 2021 01:15:27 GMT, Weijun Wang wrote: >> Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - final spec change > - Merge branch 'master' into 8225181 > - Merge branch 'master' into 8225181 > - redine spec > - more clear and precise spec > - clarification on protected attributes > - 8225181: KeyStore should have a getAttributes method > > 8225181: KeyStore should have a getAttributes method Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6026 From weijun at openjdk.java.net Fri Dec 3 18:56:22 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 3 Dec 2021 18:56:22 GMT Subject: Integrated: 8225181: KeyStore should have a getAttributes method In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 02:08:24 GMT, Weijun Wang wrote: > Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password. This pull request has now been integrated. Changeset: a729a70c Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/a729a70c0119ed071ff490b0dfd4e3e2cb1a5ae4 Stats: 169 lines in 6 files changed: 167 ins; 0 del; 2 mod 8225181: KeyStore should have a getAttributes method Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/6026 From serb at openjdk.java.net Fri Dec 3 18:58:16 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 3 Dec 2021 18:58:16 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation In-Reply-To: References:

Message-ID: On Thu, 2 Dec 2021 10:55:57 GMT, Andrew Leonard wrote: > This is the case at Adoptium for example, which uses the Mozilla trusted CA certs. But they didn't think skipping this test was too strong a step? For example validation of the certs expiration is quite useful. I tried to update the test to take into account additional certs, but it caused a merge conflict each time the certs in OpenJDK are updated. Probably we can add a config file that can inject/override some info in the test(at least skip the checksum validation)? By default this config file will be empty and will not be modified in the OpenJDK, but the vendors will be able to modify it. @wangweij @rhalade what do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From rhalade at openjdk.java.net Fri Dec 3 19:09:23 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Fri, 3 Dec 2021 19:09:23 GMT Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard wrote: >> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation > > Signed-off-by: Andrew Leonard > - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation > > Signed-off-by: Andrew Leonard > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation > > Signed-off-by: Andrew Leonard The purpose of this test is to ensure integrity of the cacerts file along with basic validation of included roots. Having a config file with this information sounds like a good idea for now to be able to handle multiple files. ------------- PR: https://git.openjdk.java.net/jdk/pull/6647 From weijun at openjdk.java.net Fri Dec 3 19:45:32 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 3 Dec 2021 19:45:32 GMT Subject: RFR: 8278247: KeyStoreSpi::engineGetAttributes does not throws KeyStoreException Message-ID: <1yRV1NBDy3k4gVPG6beVIbT5imhPijk8n0HzfD5_3KU=.1b3beb06-d476-41a2-80ec-fcb02d722dcf@github.com> The specification wrongly claims there could be an exception thrown, but it's not true. ------------- Commit messages: - 8278247: KeyStoreSpi::engineGetAttributes does not throws KeyStoreException Changes: https://git.openjdk.java.net/jdk/pull/6706/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6706&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278247 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6706.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6706/head:pull/6706 PR: https://git.openjdk.java.net/jdk/pull/6706 From mullan at openjdk.java.net Fri Dec 3 19:52:15 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 3 Dec 2021 19:52:15 GMT Subject: RFR: 8278247: KeyStoreSpi::engineGetAttributes does not throws KeyStoreException In-Reply-To: <1yRV1NBDy3k4gVPG6beVIbT5imhPijk8n0HzfD5_3KU=.1b3beb06-d476-41a2-80ec-fcb02d722dcf@github.com> References: <1yRV1NBDy3k4gVPG6beVIbT5imhPijk8n0HzfD5_3KU=.1b3beb06-d476-41a2-80ec-fcb02d722dcf@github.com> Message-ID: On Fri, 3 Dec 2021 19:36:51 GMT, Weijun Wang wrote: > The specification wrongly claims there could be an exception thrown, but it's not true. Looks good. Add a noreg-doc or something similar to the bug. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6706 From valeriep at openjdk.java.net Fri Dec 3 19:52:26 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 3 Dec 2021 19:52:26 GMT Subject: RFR: 8271566: DSA signature length value is not accurate in P11Signature [v3] In-Reply-To: References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> Message-ID: On Thu, 2 Dec 2021 21:31:52 GMT, Martin Balao wrote: >> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4. >> >> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed. >> >> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566 > > Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - 8271566: DSA signature length value is not accurate in P11Signature (Webrev.02 based) > - Merge branch 'master' into JDK-8271566 > - Revert 8271566: DSA signature length value is not accurate in P11Signature > - Revert P11Key static inner classes refactorings. > - P11Key static inner classes refactorings. > - 8271566: DSA signature length value is not accurate in P11Signature src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 126: > 124: boolean sensitive = false; > 125: boolean extractable = true; > 126: for (CK_ATTRIBUTE attr : attrs) { Just noticed this: add a check for non-null attrs? If null, skip the for-loop. ------------- PR: https://git.openjdk.java.net/jdk/pull/4961 From weijun at openjdk.java.net Fri Dec 3 19:56:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 3 Dec 2021 19:56:19 GMT Subject: Integrated: 8278247: KeyStoreSpi::engineGetAttributes does not throws KeyStoreException In-Reply-To: <1yRV1NBDy3k4gVPG6beVIbT5imhPijk8n0HzfD5_3KU=.1b3beb06-d476-41a2-80ec-fcb02d722dcf@github.com> References: <1yRV1NBDy3k4gVPG6beVIbT5imhPijk8n0HzfD5_3KU=.1b3beb06-d476-41a2-80ec-fcb02d722dcf@github.com> Message-ID: On Fri, 3 Dec 2021 19:36:51 GMT, Weijun Wang wrote: > The specification wrongly claims there could be an exception thrown, but it's not true. This pull request has now been integrated. Changeset: e1cde19d Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/e1cde19dbdbbca365ecfea6d1e2e85a42ed8bde0 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8278247: KeyStoreSpi::engineGetAttributes does not throws KeyStoreException Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/6706 From valeriep at openjdk.java.net Fri Dec 3 21:26:25 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 3 Dec 2021 21:26:25 GMT Subject: RFR: 8271566: DSA signature length value is not accurate in P11Signature [v3] In-Reply-To: References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> Message-ID: <-yIPPPmtHHi1gZhXmeLa-6dr_5XbAfQWWC2Wz7PY3t4=.6e2c7ccb-4881-4073-9a7d-1553ee5e139c@github.com> On Thu, 2 Dec 2021 21:31:52 GMT, Martin Balao wrote: >> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4. >> >> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed. >> >> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566 > > Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - 8271566: DSA signature length value is not accurate in P11Signature (Webrev.02 based) > - Merge branch 'master' into JDK-8271566 > - Revert 8271566: DSA signature length value is not accurate in P11Signature > - Revert P11Key static inner classes refactorings. > - P11Key static inner classes refactorings. > - 8271566: DSA signature length value is not accurate in P11Signature test/jdk/TEST.groups line 202: > 200: > 201: jdk_security1 = \ > 202: sun/security/pkcs11 Please discard this, this is just for quick testing, it's not meant to be part of this change... ------------- PR: https://git.openjdk.java.net/jdk/pull/4961 From mbalao at openjdk.java.net Sat Dec 4 21:59:21 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Sat, 4 Dec 2021 21:59:21 GMT Subject: RFR: 8271566: DSA signature length value is not accurate in P11Signature [v3] In-Reply-To: References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com>

Message-ID: On Fri, 3 Dec 2021 19:48:53 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - 8271566: DSA signature length value is not accurate in P11Signature (Webrev.02 based) >> - Merge branch 'master' into JDK-8271566 >> - Revert 8271566: DSA signature length value is not accurate in P11Signature >> - Revert P11Key static inner classes refactorings. >> - P11Key static inner classes refactorings. >> - 8271566: DSA signature length value is not accurate in P11Signature > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 126: > >> 124: boolean sensitive = false; >> 125: boolean extractable = true; >> 126: for (CK_ATTRIBUTE attr : attrs) { > > Just noticed this: add a check for non-null attrs? If null, skip the for-loop. I've noticed that when reviewing your Webrev.01 but thought that the change was on purpose because of the P11Key constructor callers, which do not currently pass null. Anyways, I'll add the null check again just in case. > test/jdk/TEST.groups line 202: > >> 200: >> 201: jdk_security1 = \ >> 202: sun/security/pkcs11 > > Please discard this, this is just for quick testing, it's not meant to be part of this change... Well spotted. ------------- PR: https://git.openjdk.java.net/jdk/pull/4961 From mbalao at openjdk.java.net Sat Dec 4 22:03:53 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Sat, 4 Dec 2021 22:03:53 GMT Subject: RFR: 8271566: DSA signature length value is not accurate in P11Signature [v4] In-Reply-To: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> Message-ID: > As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4. > > Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed. > > No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8271566 Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Null check added and a fix in the security test group ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4961/files - new: https://git.openjdk.java.net/jdk/pull/4961/files/00564198..1e53b6d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4961&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4961&range=02-03 Stats: 10 lines in 2 files changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4961.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4961/head:pull/4961 PR: https://git.openjdk.java.net/jdk/pull/4961 From mbalao at openjdk.java.net Sat Dec 4 22:14:22 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Sat, 4 Dec 2021 22:14:22 GMT Subject: RFR: 8271566: DSA signature length value is not accurate in P11Signature [v2] In-Reply-To: References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> <8vTXZjaSwUZ3IoHJcfC2cllpmm75dey2vtvVenwo1I4=.8e9ed87b-36de-42c6-b70b-554ba2db23ab@github.com> Message-ID: On Tue, 30 Nov 2021 19:48:19 GMT, Valerie Peng wrote: >> Hmm, thinking more about "internal"/"opaque", given this is naming for the parent, maybe "internal" is more correct. The non-sensitive keys are encapsulated by the children classes and is still an instance of the parent. If you name the parent class w/ "opaque" suffix, it looks misleading/confusing. The opaqueness is implied by the implementation instead of the properties of the objects. > >> Hi @valeriepeng , >> >> Yes, I just verified how serialization works for P11Keys and your 'transient' change makes sense to me now. >> >> I see your point about Internal/Opaque. Keep 'Internal' then if you prefer. The whole inheritance relationship between these classes sounds a bit weird to me, beyond the names we call them. I wouldn't suggest any additional changes there now, though. >> >> It looks to me that the only 2 changes expected for Webrev.02 are: 1) P11RSAPrivateNonCRTKey to use the parent's protected 'n'; and 2) removal of 'long errorCode = e.getErrorCode();'. >> >> Now that we almost have the changeset ready, I'm not sure of how to proceed with the push. Do you want me to commit Webrev.02 in my own branch and use the 'Co-authored-by:' header? If we do that, do we still need an additional Reviewer? Do you prefer to have your own branch? Please let me know of how to move forward. >> >> Martin.- > > You can just incorporate the changes on your branch and proceeds with me being the reviewer. The webrev that I sent u is just an easier way to express the comments/feedbacks. > > Thanks, > Valerie Hi @valeriepeng , Please take a look at the latest change based on your comments. No regressions found in 'jdk/sun/security/pkcs11'. Thanks, Martin.- ------------- PR: https://git.openjdk.java.net/jdk/pull/4961 From weijun at openjdk.java.net Sun Dec 5 05:15:11 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 5 Dec 2021 05:15:11 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 21:42:51 GMT, Valerie Peng wrote: > PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE, it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not explicitly specified in config. In addition, PKCS#11 v3.0 defines a new API for cancelling session operations, so I've also updated various classes to call this new API if the PKCS#11 library version is 3.0. Otherwise, these classes will try to cancel by finishing off current operations as before. The support for the new C_LoginUser() has not been tested, so I commented it out for now. Given the current release schedule, support for other new PKCS#11 APIs (such as message-based ones and parameters structure) and options for C_GetInterface (if needed) will be handled later. > > I validated the current changes against different NSS releases (supports PKCS#11 v2.40 and v3..0 respectively) with existing regression tests. > > Thanks, > Valerie src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java line 418: > 416: } > 417: String word = st.sval; > 418: switch (word) { Since every case has a break it's probably better to use the enhanced switch (`case "x" -> ...;`). It's safer and also saves quite some lines. An IDE can help you with the conversion. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 405: > 403: private void cancelOperation() { > 404: // cancel operation by finishing it; avoid killSession as some > 405: // hardware vendors may require re-login The new `cancelOperation()` methods seems identical everywhere. Is it possible to consolidate it to a helper method like `trySessionCancel(token, session, flags)`? It can return true if canceled successfully, false if needs a fallback, and can still throw a `ProviderException`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6655 From abakhtin at openjdk.java.net Mon Dec 6 09:24:10 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Mon, 6 Dec 2021 09:24:10 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out [v2] In-Reply-To: <4b_-Dz3yRbOwJziNmKdlAsCBuEXLn37aewRH3pVdDG0=.462e6f8d-63f3-4f2b-8100-e6d731fcf379@github.com> References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> <4b_-Dz3yRbOwJziNmKdlAsCBuEXLn37aewRH3pVdDG0=.462e6f8d-63f3-4f2b-8100-e6d731fcf379@github.com> Message-ID: On Fri, 3 Dec 2021 06:14:49 GMT, Sibabrata Sahoo wrote: >> This Test gets timeout during low cpu availability. It is modified to support extended timeout period during JTREG execution. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out Thank you. Looks good to me, but I'm not a reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/6626 From weijun at openjdk.java.net Mon Dec 6 13:58:17 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 6 Dec 2021 13:58:17 GMT Subject: RFR: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out [v2] In-Reply-To: <4b_-Dz3yRbOwJziNmKdlAsCBuEXLn37aewRH3pVdDG0=.462e6f8d-63f3-4f2b-8100-e6d731fcf379@github.com> References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> <4b_-Dz3yRbOwJziNmKdlAsCBuEXLn37aewRH3pVdDG0=.462e6f8d-63f3-4f2b-8100-e6d731fcf379@github.com> Message-ID: On Fri, 3 Dec 2021 06:14:49 GMT, Sibabrata Sahoo wrote: >> This Test gets timeout during low cpu availability. It is modified to support extended timeout period during JTREG execution. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out Looks good. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6626 From mullan at openjdk.java.net Mon Dec 6 17:12:11 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 6 Dec 2021 17:12:11 GMT Subject: RFR: 8275082: Update XML Security for Java to 2.3.0 [v2] In-Reply-To: <1rndJ3etjd4wF0wf6EKNDM4bAjItCEc0nApENWdwyp4=.3ad0ea6f-3aa8-4532-a385-4fefc89b30b0@github.com> References: <1rndJ3etjd4wF0wf6EKNDM4bAjItCEc0nApENWdwyp4=.3ad0ea6f-3aa8-4532-a385-4fefc89b30b0@github.com> Message-ID: On Fri, 3 Dec 2021 15:24:54 GMT, Weijun Wang wrote: >> Import Apache Santuario 2.3.0 without the secure validation changes since in OpenJDK we are using the `jdk.xml.dsig.secureValidationPolicy` security property for XML Signature secure validation protection. >> >> Two commits are pushed: >> >> - 2.3.0: Import 2.3.0 code changes >> - revert: revert the Santuario secure validation changes > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update comment Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6644 From prr at openjdk.java.net Mon Dec 6 17:57:14 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 6 Dec 2021 17:57:14 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v3] In-Reply-To: References:

Message-ID: On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian wrote: >> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. >> >> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. >> >> The CSR has been approved. >> An automated test build+test run passes cleanly (FWIW :D ). > > Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into 8276447 > - Merge branch 'master' into 8276447 > - merge > - @SuppressWarnings(removal) in Windows CKey.java > - Add jls tag to runFinalization methods > - Update wording of Object.finalize, new paragraph is now bold > - update Object.finalize javadoc > - update Object.finalize JavaDoc and @deprecated tag > - Update Object.finalize deprecation message > - Indicate that runFinalizers does nothing if finalization is disabled or removed > - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From weijun at openjdk.java.net Mon Dec 6 18:04:21 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 6 Dec 2021 18:04:21 GMT Subject: Integrated: 8275082: Update XML Security for Java to 2.3.0 In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 17:31:37 GMT, Weijun Wang wrote: > Import Apache Santuario 2.3.0 without the secure validation changes since in OpenJDK we are using the `jdk.xml.dsig.secureValidationPolicy` security property for XML Signature secure validation protection. > > Two commits are pushed: > > - 2.3.0: Import 2.3.0 code changes > - revert: revert the Santuario secure validation changes This pull request has now been integrated. Changeset: 2c31a173 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/2c31a1735d5b8646ed8984a5475d5c8c9c91c19d Stats: 409 lines in 32 files changed: 56 ins; 268 del; 85 mod 8275082: Update XML Security for Java to 2.3.0 Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/6644 From ascarpino at openjdk.java.net Mon Dec 6 18:53:13 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 6 Dec 2021 18:53:13 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 21:42:51 GMT, Valerie Peng wrote: > PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE, it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not explicitly specified in config. In addition, PKCS#11 v3.0 defines a new API for cancelling session operations, so I've also updated various classes to call this new API if the PKCS#11 library version is 3.0. Otherwise, these classes will try to cancel by finishing off current operations as before. The support for the new C_LoginUser() has not been tested, so I commented it out for now. Given the current release schedule, support for other new PKCS#11 APIs (such as message-based ones and parameters structure) and options for C_GetInterface (if needed) will be handled later. > > I validated the current changes against different NSS releases (supports PKCS#11 v2.40 and v3..0 respectively) with existing regression tests. > > Thanks, > Valerie Are there no tests because there is no support for 3.0 in nss? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 406: > 404: token.ensureValid(); > 405: if (token.p11.getVersion().major == 3) { > 406: long flags = (encrypt? CKF_ENCRYPT : CKF_DECRYPT); I think this is a syntax nit with no space between "encrypt" and '?' src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 449: > 447: token.ensureValid(); > 448: if (token.p11.getVersion().major == 3) { > 449: long flags = (encrypt? CKF_ENCRYPT : CKF_DECRYPT); I think this is a syntax nit with no space between "encrypt" and '?' src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyWrapCipher.java line 291: > 289: > 290: if (token.p11.getVersion().major == 3) { > 291: long flags = (opmode == Cipher.ENCRYPT_MODE? CKF_ENCRYPT : I think this is a syntax nit with no space between MODE and '?' src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java line 275: > 273: > 274: if (token.p11.getVersion().major == 3) { > 275: long flags = (mode == M_SIGN? CKF_SIGN : CKF_VERIFY); I think this is a syntax nit with no space between M_SIGN and '?' src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java line 285: > 283: > 284: if (token.p11.getVersion().major == 3) { > 285: long flags = (mode == M_SIGN? CKF_SIGN : CKF_VERIFY); M_SIGN ? ... src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 558: > 556: throws PKCS11Exception; > 557: > 558: ///** Was it intentional to have the below commented out? src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/p11_md.c line 128: > 126: } > 127: > 128: #ifdef DEBUG Is C_GetInterfaceList in DEBUG only because it's a new 3.0 function we are not supporting yet? ------------- PR: https://git.openjdk.java.net/jdk/pull/6655 From ascarpino at openjdk.java.net Mon Dec 6 19:03:17 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 6 Dec 2021 19:03:17 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 In-Reply-To: References: Message-ID: <2QWSpMna1XYVuQXlt7hss4vuZ7-zz2-tUf56KuL0a-w=.97f834d3-ab28-4344-aed6-371af911a506@github.com> On Wed, 1 Dec 2021 21:42:51 GMT, Valerie Peng wrote: > PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE, it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not explicitly specified in config. In addition, PKCS#11 v3.0 defines a new API for cancelling session operations, so I've also updated various classes to call this new API if the PKCS#11 library version is 3.0. Otherwise, these classes will try to cancel by finishing off current operations as before. The support for the new C_LoginUser() has not been tested, so I commented it out for now. Given the current release schedule, support for other new PKCS#11 APIs (such as message-based ones and parameters structure) and options for C_GetInterface (if needed) will be handled later. > > I validated the current changes against different NSS releases (supports PKCS#11 v2.40 and v3..0 respectively) with existing regression tests. > > Thanks, > Valerie I updated my comments because I neglected to read your initial message and went straight to the code review ------------- PR: https://git.openjdk.java.net/jdk/pull/6655 From valeriep at openjdk.java.net Mon Dec 6 20:10:16 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 6 Dec 2021 20:10:16 GMT Subject: RFR: 8271566: DSA signature length value is not accurate in P11Signature [v4] In-Reply-To: References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> Message-ID: On Sat, 4 Dec 2021 22:03:53 GMT, Martin Balao wrote: >> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4. >> >> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed. >> >> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566 > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Null check added and a fix in the security test group Looks good. Thanks! Valerie ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4961 From mbalao at openjdk.java.net Mon Dec 6 20:35:23 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Mon, 6 Dec 2021 20:35:23 GMT Subject: Integrated: 8271566: DSA signature length value is not accurate in P11Signature In-Reply-To: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> References: <1TPW26SEl6BcKnQobVmN2SVGnU4RBrhaeLtx28AJzt0=.162e98c1-94e9-47ee-8070-b4dde6dbf66f@github.com> Message-ID: On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao wrote: > As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4. > > Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed. > > No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8271566 This pull request has now been integrated. Changeset: ea8d3c92 Author: Martin Balao URL: https://git.openjdk.java.net/jdk/commit/ea8d3c92c69c393cdbc6c62398f1e9c6adc708d3 Stats: 686 lines in 3 files changed: 379 ins; 118 del; 189 mod 8271566: DSA signature length value is not accurate in P11Signature Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/4961 From bchristi at openjdk.java.net Mon Dec 6 20:41:43 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 6 Dec 2021 20:41:43 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v4] In-Reply-To: References: Message-ID: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'master' into 8276447 - Merge branch 'master' into 8276447 - Merge branch 'master' into 8276447 - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - ... and 24 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...0a983d51 ------------- Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=03 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From valeriep at openjdk.java.net Mon Dec 6 21:39:16 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 6 Dec 2021 21:39:16 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 In-Reply-To: References:

Message-ID: On Sun, 5 Dec 2021 04:51:51 GMT, Weijun Wang wrote: >> PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE, it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not explicitly specified in config. In addition, PKCS#11 v3.0 defines a new API for cancelling session operations, so I've also updated various classes to call this new API if the PKCS#11 library version is 3.0. Otherwise, these classes will try to cancel by finishing off current operations as before. The support for the new C_LoginUser() has not been tested, so I commented it out for now. Given the current release schedule, support for other new PKCS#11 APIs (such as message-based ones and parameters structure) and options for C_GetInterface (if needed) will be handled later. >> >> I validated the current changes against different NSS releases (supports PKCS#11 v2.40 and v3..0 respectively) with existing regression tests. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java line 418: > >> 416: } >> 417: String word = st.sval; >> 418: switch (word) { > > Since every case has a break it's probably better to use the enhanced switch (`case "x" -> ...;`). It's safer and also saves quite some lines. An IDE can help you with the conversion. Sure, I can do that. I tend to use the "->" for switch with less items. ------------- PR: https://git.openjdk.java.net/jdk/pull/6655 From weijun at openjdk.java.net Mon Dec 6 22:30:24 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 6 Dec 2021 22:30:24 GMT Subject: RFR: 8277932: Subject:callAs() not throwing NPE when action is null Message-ID: Add null check. I must have thought the NPE will be thrown anyway but the `catch Exception` block swallows it. I added a noreg-trivial label. If you think differently can add one. ------------- Commit messages: - 8277932: Subject:callAs() not throwing NPE when action is null Changes: https://git.openjdk.java.net/jdk/pull/6728/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6728&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277932 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6728.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6728/head:pull/6728 PR: https://git.openjdk.java.net/jdk/pull/6728 From rriggs at openjdk.java.net Mon Dec 6 23:37:14 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 6 Dec 2021 23:37:14 GMT Subject: RFR: 8277932: Subject:callAs() not throwing NPE when action is null In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 22:22:14 GMT, Weijun Wang wrote: > Add null check. I must have thought the NPE will be thrown anyway but the `catch Exception` block swallows it. > > I added a noreg-trivial label. If you think differently can add one. Yes, the stack trace will be more useful with the explicit check, otherwise it would be buried inside other calls and it won't be so obvious that the argument passed to callAs is null. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6728 From valeriep at openjdk.java.net Tue Dec 7 00:11:17 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 7 Dec 2021 00:11:17 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 In-Reply-To: References:

Message-ID: On Sun, 5 Dec 2021 05:00:51 GMT, Weijun Wang wrote: >> PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE, it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not explicitly specified in config. In addition, PKCS#11 v3.0 defines a new API for cancelling session operations, so I've also updated various classes to call this new API if the PKCS#11 library version is 3.0. Otherwise, these classes will try to cancel by finishing off current operations as before. The support for the new C_LoginUser() has not been tested, so I commented it out for now. Given the current release schedule, support for other new PKCS#11 APIs (such as message-based ones and parameters structure) and options for C_GetInterface (if needed) will be handled later. >> >> I validated the current changes against different NSS releases (supports PKCS#11 v2.40 and v3..0 respectively) with existing regression tests. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 405: > >> 403: private void cancelOperation() { >> 404: // cancel operation by finishing it; avoid killSession as some >> 405: // hardware vendors may require re-login > > The new `cancelOperation()` methods seems identical everywhere. Is it possible to consolidate it to a helper method like `trySessionCancel(token, session, flags)`? It can return true if canceled successfully, false if needs a fallback, and can still throw a `ProviderException`. I assume you mean the if-() block of code? I can move the code into a helper method inside the P11Util class. ------------- PR: https://git.openjdk.java.net/jdk/pull/6655 From weijun at openjdk.java.net Tue Dec 7 01:41:18 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 7 Dec 2021 01:41:18 GMT Subject: Integrated: 8277932: Subject:callAs() not throwing NPE when action is null In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 22:22:14 GMT, Weijun Wang wrote: > Add null check. I must have thought the NPE will be thrown anyway but the `catch Exception` block swallows it. > > I added a noreg-trivial label. If you think differently can add one. This pull request has now been integrated. Changeset: 10db0e41 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/10db0e41634b62be5c1a931bd54ac4260108670d Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8277932: Subject:callAs() not throwing NPE when action is null Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/6728 From weijun at openjdk.java.net Tue Dec 7 01:49:10 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 7 Dec 2021 01:49:10 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 In-Reply-To: References:

Message-ID: On Tue, 7 Dec 2021 00:08:03 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 405: >> >>> 403: private void cancelOperation() { >>> 404: // cancel operation by finishing it; avoid killSession as some >>> 405: // hardware vendors may require re-login >> >> The new `cancelOperation()` methods seems identical everywhere. Is it possible to consolidate it to a helper method like `trySessionCancel(token, session, flags)`? It can return true if canceled successfully, false if needs a fallback, and can still throw a `ProviderException`. > > I assume you mean the if-() block of code? I can move the code into a helper method inside the P11Util class. Yes, just keep duplicated lines as few as possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/6655 From valeriep at openjdk.java.net Tue Dec 7 04:06:13 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 7 Dec 2021 04:06:13 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 In-Reply-To: References:

Message-ID: <47dMbCbzP87LE18e86vXKrnwgcw48UMLIOiHpJNm55s=.ad561798-7ba5-4f01-baf5-6cd00fb6b9ef@github.com> On Mon, 6 Dec 2021 17:24:44 GMT, Anthony Scarpino wrote: >> PKCS#11 v3.0 adds the support for several new APIs. For this particular RFE, it enhances SunPKCS11 provider to load PKCS#11 provider by first trying the C_GetInterface (new in 3.0) before the C_GetFunctionList assuming not explicitly specified in config. In addition, PKCS#11 v3.0 defines a new API for cancelling session operations, so I've also updated various classes to call this new API if the PKCS#11 library version is 3.0. Otherwise, these classes will try to cancel by finishing off current operations as before. The support for the new C_LoginUser() has not been tested, so I commented it out for now. Given the current release schedule, support for other new PKCS#11 APIs (such as message-based ones and parameters structure) and options for C_GetInterface (if needed) will be handled later. >> >> I validated the current changes against different NSS releases (supports PKCS#11 v2.40 and v3..0 respectively) with existing regression tests. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java line 275: > >> 273: >> 274: if (token.p11.getVersion().major == 3) { >> 275: long flags = (mode == M_SIGN? CKF_SIGN : CKF_VERIFY); > > I think this is a syntax nit with no space between M_SIGN and '?' Ok, will add the space. ------------- PR: https://git.openjdk.java.net/jdk/pull/6655 From valeriep at openjdk.java.net Tue Dec 7 04:14:15 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 7 Dec 2021 04:14:15 GMT Subject: RFR: 8255409: Support the new APIs in PKCS#11 v3.0 In-Reply-To: References:

Message-ID: On Mon, 6 Dec 2021 18:50:08 GMT, Anthony Scarpino wrote: > Should the NSS supporting 3.0 get added to the changeset for testing? Recall there was a bug filed for updating the artifactory NSS version. There was some window build issue, will follow up with the SQE RE again. > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 406: > >> 404: token.ensureValid(); >> 405: if (token.p11.getVersion().major == 3) { >> 406: long flags = (encrypt? CKF_ENCRYPT : CKF_DECRYPT); > > I think this is a syntax nit with no space between "encrypt" and '?' Ok. > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 449: > >> 447: token.ensureValid(); >> 448: if (token.p11.getVersion().major == 3) { >> 449: long flags = (encrypt? CKF_ENCRYPT : CKF_DECRYPT); > > I think this is a syntax nit with no space between "encrypt" and '?' Ok. > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyWrapCipher.java line 291: > >> 289: >> 290: if (token.p11.getVersion().major == 3) { >> 291: long flags = (opmode == Cipher.ENCRYPT_MODE? CKF_ENCRYPT : > > I think this is a syntax nit with no space between MODE and '?' Ok. > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java line 285: > >> 283: >> 284: if (token.p11.getVersion().major == 3) { >> 285: long flags = (mode == M_SIGN? CKF_SIGN : CKF_VERIFY); > > M_SIGN ? ... Ok. BTW, is there a central place for these syntax? I usually just pick up the convention used in the same file. ------------- PR: https://git.openjdk.java.net/jdk/pull/6655 From ssahoo at openjdk.java.net Tue Dec 7 05:14:17 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Tue, 7 Dec 2021 05:14:17 GMT Subject: Integrated: 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out In-Reply-To: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> References: <8GdNQIf2UfVcwE94T18PpgcgQNOYlRt03WllAYdR4JE=.3987d453-4669-40ff-b3da-828b4c17d602@github.com> Message-ID: On Wed, 1 Dec 2021 06:26:58 GMT, Sibabrata Sahoo wrote: > This Test gets timeout during low cpu availability. It is modified to support extended timeout period during JTREG execution. This pull request has now been integrated. Changeset: f22d157e Author: Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk/commit/f22d157e551fb28991e7713a45e63a0a8d9d2c4c Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8277353: java/security/MessageDigest/ThreadSafetyTest.java test times out Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/6626 From alanb at openjdk.java.net Tue Dec 7 07:18:16 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 7 Dec 2021 07:18:16 GMT Subject: RFR: 8277932: Subject:callAs() not throwing NPE when action is null In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 22:22:14 GMT, Weijun Wang wrote: > Add null check. I must have thought the NPE will be thrown anyway but the `catch Exception` block swallows it. > > I added a noreg-trivial label. If you think differently can add one. Is there a test for this? (I see noreg-trivial is added but a test should be easy to add). ------------- PR: https://git.openjdk.java.net/jdk/pull/6728 From alanb at openjdk.java.net Tue Dec 7 08:03:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 7 Dec 2021 08:03:21 GMT Subject: RFR: 8274809: Update java.base classes to use try-with-resources [v4] In-Reply-To: References:

Message-ID: On Wed, 6 Oct 2021 20:37:29 GMT, Andrey Turbanov wrote: >> 8274809: Update java.base classes to use try-with-resources > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274809: Update java.base classes to use try-with-resources > fix review comments Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/sun/net/NetProperties.java line 73: > 71: try (FileInputStream in = new FileInputStream(fname); > 72: BufferedInputStream bin = new BufferedInputStream(in)) > 73: { Style-wide I'd probably put the "{" at the end of L72. ------------- PR: https://git.openjdk.java.net/jdk/pull/5818 From dfuchs at openjdk.java.net Tue Dec 7 11:48:17 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 7 Dec 2021 11:48:17 GMT Subject: RFR: 8274809: Update java.base classes to use try-with-resources [v4] In-Reply-To: References:

Message-ID: On Wed, 6 Oct 2021 20:37:29 GMT, Andrey Turbanov wrote: >> 8274809: Update java.base classes to use try-with-resources > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274809: Update java.base classes to use try-with-resources > fix review comments The rest looks OK. src/java.base/share/classes/sun/net/www/MimeTable.java line 385: > 383: > 384: protected boolean saveAsProperties(File file) { > 385: try (FileOutputStream os = new FileOutputStream(file)) { This is not strictly equivalent as now an exception thrown during `close()` will be printed instead of being ignored. I have no idea whether it's a good thing or a bad thing, but that's a _different_ thing... So unless someone with more historical knowledge of this area can comment, maybe this change should be reverted. ------------- PR: https://git.openjdk.java.net/jdk/pull/5818 From weijun at openjdk.java.net Tue Dec 7 14:09:18 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 7 Dec 2021 14:09:18 GMT Subject: RFR: 8277932: Subject:callAs() not throwing NPE when action is null In-Reply-To: References:

Message-ID: On Tue, 7 Dec 2021 07:14:53 GMT, Alan Bateman wrote: > Is there a test for this? (I see noreg-trivial is added but a test should be easy to add). I can add one, just thought it's not necessary. I didn't say noreg-hard. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/6728 From duke at openjdk.java.net Tue Dec 7 14:28:18 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 7 Dec 2021 14:28:18 GMT Subject: RFR: 8274809: Update java.base classes to use try-with-resources [v4] In-Reply-To: References:

Message-ID: <6HwkNRRJdJHU0_LhA4KHZ0egZ3zd7mDMwARP1EnCdFk=.3f2e8083-6a74-4284-8f74-aae7cc0093ff@github.com> On Tue, 7 Dec 2021 11:41:12 GMT, Daniel Fuchs wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274809: Update java.base classes to use try-with-resources >> fix review comments > > src/java.base/share/classes/sun/net/www/MimeTable.java line 385: > >> 383: >> 384: protected boolean saveAsProperties(File file) { >> 385: try (FileOutputStream os = new FileOutputStream(file)) { > > This is not strictly equivalent as now an exception thrown during `close()` will be printed instead of being ignored. I have no idea whether it's a good thing or a bad thing, but that's a _different_ thing... > So unless someone with more historical knowledge of this area can comment, maybe this change should be reverted. I believe it's always good to have at least _some_ trace if we got Exception. If closing FileOutputStream failed - there is no guarantee, that all written content is actually stored to filesystem. BTW, this method `saveAsProperties` seems unused... ------------- PR: https://git.openjdk.java.net/jdk/pull/5818 From dfuchs at openjdk.java.net Tue Dec 7 14:51:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 7 Dec 2021 14:51:24 GMT Subject: RFR: 8274809: Update java.base classes to use try-with-resources [v4] In-Reply-To: References:

<6HwkNRRJdJHU0_LhA4KHZ0egZ3zd7mDMwARP1EnCdFk=.3f2e8083-6a74-4284-8f74-aae7cc0093ff@github.com> Message-ID: