From xuelei at openjdk.org Mon Jan 2 03:07:55 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 2 Jan 2023 03:07:55 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v5] In-Reply-To: References:

Message-ID: <0DraNUgnD1sGBM7e3jj101i5Dso2znvuEU-z5GYDnPw=.8df7206e-9934-474d-b8c0-c3d87f628c79@github.com> On Fri, 23 Dec 2022 11:51:32 GMT, Volker Simonis wrote: >> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s. >> >> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads. >> >> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe. >> >> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues. >> >> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created: >> >> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000 >> 605: 1 32 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) >> >> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances: >> >> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000 >> 11: 1000 32000 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) >> >> With my proposed patch, the numbers goes back to two instances again: >> >> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000 >> 611: 2 64 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) >> >> >> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test. > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Use HandshakeContext's secure random for keygen in StatelessKey and improve initialization in SSLSessionContextImpl Looks good to me. Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.org/jdk/pull/11590 From duke at openjdk.org Tue Jan 3 00:59:57 2023 From: duke at openjdk.org (Xubo Zhang) Date: Tue, 3 Jan 2023 00:59:57 GMT Subject: RFR: 8296746: NativePRNG SecureRandom doesn't scale with threads [v2] In-Reply-To: References:

Message-ID: On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote: >> NativePRNG SecureRandom doesn?t scale with number of threads. The performance starts dropping as we increase the number of threads. Even going from 1 thread to 2 threads shows significant drop. The bottleneck is the singleton RandomIO instance. Making the RandomIO ThreadLocal helps in removing this bottleneck. >> >> Here are the jmh thrpt ops/s data for SecureRandomBench.nextBytes, algorithm=NativePRNGNonBlocking, datasize=64, notshared: >> >> > xmlns:o="urn:schemas-microsoft-com:office:office" >> xmlns:x="urn:schemas-microsoft-com:office:excel" >> xmlns="http://www.w3.org/TR/REC-html40"> >> >> >> >> >> >> > href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> >> > href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> >> >> >> >> >> >> >> >> >> >> #threads | singleton RandomIO | ThreadLocal RandomIO >> -- | -- | -- >> 1 | 1269133 | 1279088 >> 2 | 862923 | 1362066 >> 3 | 819734 | 1630522 >> 4 | 809128 | 1614500 >> 5 | 821514 | 1594965 >> 6 | 808795 | 1545045 >> 7 | 783050 | 1499388 >> 8 | 787236 | 1470004 >> >> >> >> >> >> > > Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/unix/classes/sun/security/provider/NativePRNG.java > > Co-authored-by: Andrey Turbanov need to rethink about the comments made by [Alan Bateman](https://github.com/AlanBateman) ------------- PR: https://git.openjdk.org/jdk/pull/11069 From duke at openjdk.org Tue Jan 3 00:59:58 2023 From: duke at openjdk.org (Xubo Zhang) Date: Tue, 3 Jan 2023 00:59:58 GMT Subject: Withdrawn: 8296746: NativePRNG SecureRandom doesn't scale with threads In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 20:15:57 GMT, Xubo Zhang wrote: > NativePRNG SecureRandom doesn?t scale with number of threads. The performance starts dropping as we increase the number of threads. Even going from 1 thread to 2 threads shows significant drop. The bottleneck is the singleton RandomIO instance. Making the RandomIO ThreadLocal helps in removing this bottleneck. > > Here are the jmh thrpt ops/s data for SecureRandomBench.nextBytes, algorithm=NativePRNGNonBlocking, datasize=64, notshared: > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> > href="file:///C:/Users/xbzhang/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> > > > > > > > > > > #threads | singleton RandomIO | ThreadLocal RandomIO > -- | -- | -- > 1 | 1269133 | 1279088 > 2 | 862923 | 1362066 > 3 | 819734 | 1630522 > 4 | 809128 | 1614500 > 5 | 821514 | 1594965 > 6 | 808795 | 1545045 > 7 | 783050 | 1499388 > 8 | 787236 | 1470004 > > > > > > This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11069 From duke at openjdk.org Tue Jan 3 08:35:27 2023 From: duke at openjdk.org (Ryan Wallace) Date: Tue, 3 Jan 2023 08:35:27 GMT Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no longer referenced [v4] In-Reply-To: References: Message-ID: > SubjectCodeSource is no longer used, Class should be deleted and all references updated Ryan Wallace has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge branch 'master' into 8294526 - Merge branch 'master' into 8294526 - Merge branch 'master' into 8294526 - Merge branch 'master' into 8294526 - Merge branch 'master' into 8294526 - Merge branch 'master' into 8294526 - Merge branch 'master' into 8294526 - Merge branch 'master' into 8294526 - 8294526: SubjectCodeSource is no longer referenced - Merge branch 'master' into 8294526 - ... and 7 more: https://git.openjdk.org/jdk/compare/549718e3...3139091b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10550/files - new: https://git.openjdk.org/jdk/pull/10550/files/64972419..3139091b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10550&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10550&range=02-03 Stats: 115761 lines in 2534 files changed: 59975 ins; 42548 del; 13238 mod Patch: https://git.openjdk.org/jdk/pull/10550.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10550/head:pull/10550 PR: https://git.openjdk.org/jdk/pull/10550 From duke at openjdk.org Tue Jan 3 11:34:55 2023 From: duke at openjdk.org (Ryan Wallace) Date: Tue, 3 Jan 2023 11:34:55 GMT Subject: RFR: 8294526: sun/security/provider/SubjectCodeSource.java no longer referenced [v3] In-Reply-To: References:

Message-ID: On Fri, 25 Nov 2022 06:08:30 GMT, Xue-Lei Andrew Fan wrote: >> Ryan Wallace 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 14 additional commits since the last revision: >> >> - Merge branch 'master' into 8294526 >> - Merge branch 'master' into 8294526 >> - Merge branch 'master' into 8294526 >> - Merge branch 'master' into 8294526 >> - Merge branch 'master' into 8294526 >> - 8294526: SubjectCodeSource is no longer referenced >> - Merge branch 'master' into 8294526 >> - Merge branch 'master' into 8294526 >> - Merge branch 'master' into 8294526 >> - Merge branch 'master' into 8294526 >> - ... and 4 more: https://git.openjdk.org/jdk/compare/01b03654...64972419 > > Looks good to me. Thanks! @XueleiFan / @wangweij Are you able to sponsor ? ------------- PR: https://git.openjdk.org/jdk/pull/10550 From duke at openjdk.org Tue Jan 3 13:55:56 2023 From: duke at openjdk.org (Ryan Wallace) Date: Tue, 3 Jan 2023 13:55:56 GMT Subject: Integrated: 8294526: sun/security/provider/SubjectCodeSource.java no longer referenced In-Reply-To: References: Message-ID: On Tue, 4 Oct 2022 08:25:10 GMT, Ryan Wallace wrote: > SubjectCodeSource is no longer used, Class should be deleted and all references updated This pull request has now been integrated. Changeset: 92dfc735 Author: Ryan Wallace Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/92dfc735f2297441a99b3e39464fb8f77a354d55 Stats: 822 lines in 5 files changed: 0 ins; 822 del; 0 mod 8294526: sun/security/provider/SubjectCodeSource.java no longer referenced Reviewed-by: weijun, xuelei ------------- PR: https://git.openjdk.org/jdk/pull/10550 From mullan at openjdk.org Tue Jan 3 15:33:58 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 3 Jan 2023 15:33:58 GMT Subject: [jdk20] RFR: JDK-8299235 broken link referencing missing id In-Reply-To: References: Message-ID: On Fri, 23 Dec 2022 21:22:00 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8299235 Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/77 From mpowers at openjdk.org Tue Jan 3 15:45:57 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 3 Jan 2023 15:45:57 GMT Subject: [jdk20] Integrated: JDK-8299235 broken link referencing missing id In-Reply-To: References: Message-ID: On Fri, 23 Dec 2022 21:22:00 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8299235 This pull request has now been integrated. Changeset: 3eb85d19 Author: Mark Powers Committer: Sean Mullan URL: https://git.openjdk.org/jdk20/commit/3eb85d19ec80105bcbc5ad5422d694c29a9029d2 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8299235: broken link referencing missing id Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk20/pull/77 From simonis at openjdk.org Tue Jan 3 17:45:12 2023 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 3 Jan 2023 17:45:12 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v6] In-Reply-To: References: Message-ID: > Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s. > > This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads. > > Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe. > > I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues. > > The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created: > > $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000 > 605: 1 32 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) > > The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances: > > $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000 > 11: 1000 32000 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) > > With my proposed patch, the numbers goes back to two instances again: > > $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000 > 611: 2 64 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) > > > I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test. Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: Updated copyright year to 2023 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11590/files - new: https://git.openjdk.org/jdk/pull/11590/files/68ed71dd..eb2d8e25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11590&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11590&range=04-05 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11590.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11590/head:pull/11590 PR: https://git.openjdk.org/jdk/pull/11590 From simonis at openjdk.org Tue Jan 3 17:46:57 2023 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 3 Jan 2023 17:46:57 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v5] In-Reply-To: <0DraNUgnD1sGBM7e3jj101i5Dso2znvuEU-z5GYDnPw=.8df7206e-9934-474d-b8c0-c3d87f628c79@github.com> References:

<0DraNUgnD1sGBM7e3jj101i5Dso2znvuEU-z5GYDnPw=.8df7206e-9934-474d-b8c0-c3d87f628c79@github.com> Message-ID: On Mon, 2 Jan 2023 03:05:27 GMT, Xue-Lei Andrew Fan wrote: > Looks good to me. Thanks! Thanks @XueleiFan! I've updated the copyright year to 2023 and will wait one or two more days just in case @ascarpino wants to take one more look as well. ------------- PR: https://git.openjdk.org/jdk/pull/11590 From jnimeh at openjdk.org Tue Jan 3 20:21:59 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 3 Jan 2023 20:21:59 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v5] In-Reply-To: References:

<0DraNUgnD1sGBM7e3jj101i5Dso2znvuEU-z5GYDnPw=.8df7206e-9934-474d-b8c0-c3d87f628c79@github.com> Message-ID: On Tue, 3 Jan 2023 17:43:43 GMT, Volker Simonis wrote: >> Looks good to me. Thanks! > >> Looks good to me. Thanks! > > Thanks @XueleiFan! > > I've updated the copyright year to 2023 and will wait one or two more days just in case @ascarpino wants to take one more look as well. Hi @simonis, I am sorry for chiming in so late on this issue. I do think it might be worthwhile to make your proof-of-concept code into a jtreg test as you mentioned in your summary. I think it really comes down to how feasible the conversion would be. It's always better to have an automated test if we can, but it depends on if jtreg code can get access to reliable information about the session tickets via the session cache and know that things are behaving as intended. ------------- PR: https://git.openjdk.org/jdk/pull/11590 From jwilhelm at openjdk.org Wed Jan 4 14:34:19 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 4 Jan 2023 14:34:19 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8299476: PPC64 Zero build fails after JDK-8286302 - 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" - 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java - 8298324: Unable to run shell test with make - 8299235: broken link referencing missing id The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=11845&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11845&range=00.1 Changes: https://git.openjdk.org/jdk/pull/11845/files Stats: 299 lines in 28 files changed: 101 ins; 131 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/11845.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11845/head:pull/11845 PR: https://git.openjdk.org/jdk/pull/11845 From jwilhelm at openjdk.org Wed Jan 4 16:06:57 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 4 Jan 2023 16:06:57 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:25:12 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: df1caf90 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/df1caf90818558b897a6b8ab80757f2a03398c55 Stats: 299 lines in 28 files changed: 101 ins; 131 del; 67 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/11845 From duke at openjdk.org Thu Jan 5 17:58:27 2023 From: duke at openjdk.org (Matthew Donovan) Date: Thu, 5 Jan 2023 17:58:27 GMT Subject: RFR: 8298872: Update CheckStatus.java for changes to TLS implementation Message-ID: Updated the test for TLS 1.2 and removed from ProblemList.txt ------------- Commit messages: - removed extra whitespace - 8298872: Update CheckStatus.java for changes to TLS implementation Changes: https://git.openjdk.org/jdk/pull/11857/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298872 Stats: 319 lines in 3 files changed: 35 ins; 15 del; 269 mod Patch: https://git.openjdk.org/jdk/pull/11857.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11857/head:pull/11857 PR: https://git.openjdk.org/jdk/pull/11857 From duke at openjdk.org Thu Jan 5 20:17:20 2023 From: duke at openjdk.org (Matthew Donovan) Date: Thu, 5 Jan 2023 20:17:20 GMT Subject: RFR: 8298872: Update CheckStatus.java for changes to TLS implementation [v2] In-Reply-To: References: Message-ID: > Updated the test for TLS 1.2 and removed from ProblemList.txt Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision: - updated copyright to correct year - updated copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11857/files - new: https://git.openjdk.org/jdk/pull/11857/files/685eb448..6b2596ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11857&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11857&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11857.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11857/head:pull/11857 PR: https://git.openjdk.org/jdk/pull/11857 From duke at openjdk.org Fri Jan 6 02:45:18 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 02:45:18 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor Message-ID: This PR adds a new lint warning category `this-escape`. It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) * Some constructor `B()` of `B` invokes `A()` as its superclass constructor * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. **Patch Navigation Guide** * Non-trivial compiler changes: * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` * Javadoc additions of `@implNote`: * `src/java.base/share/classes/java/io/PipedReader.java` * `src/java.base/share/classes/java/io/PipedWriter.java` * `src/java.base/share/classes/java/lang/Throwable.java` * `src/java.base/share/classes/java/util/ArrayDeque.java` * `src/java.base/share/classes/java/util/EnumMap.java` * `src/java.base/share/classes/java/util/HashSet.java` * `src/java.base/share/classes/java/util/Hashtable.java` * `src/java.base/share/classes/java/util/LinkedList.java` * `src/java.base/share/classes/java/util/TreeMap.java` * `src/java.base/share/classes/java/util/TreeSet.java` * New unit tests * `test/langtools/tools/javac/warnings/ThisEscape/*.java` * **Everything else** is just adding `@SuppressWarnings("this-escape")` ------------- Commit messages: - Remove trailing whitespace. - Some documentation tweaks. - Treat method references like the equivalent lambda. - Fix bug where initializers could generate duplicate warnings. - Javadoc fix. - Add ThisEscape.html doc note and link the new @implNote's to it. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - ... and 38 more: https://git.openjdk.org/jdk/compare/c6588d5b...9c162283 Changes: https://git.openjdk.org/jdk/pull/11874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8015831 Stats: 4326 lines in 1285 files changed: 4259 ins; 3 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Fri Jan 6 04:51:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 6 Jan 2023 04:51:00 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Hi Archie, The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From alanb at openjdk.org Fri Jan 6 07:53:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 07:53:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` This looks like a very useful lint warning to have but this PR is unwieldy. If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 6 12:10:33 2023 From: duke at openjdk.org (Matthew Donovan) Date: Fri, 6 Jan 2023 12:10:33 GMT Subject: RFR: 8298869: Update ConnectionTest.java for changes to TLS implementation Message-ID: * Updated the test for changes to the TLS implementation * Test supports TLS 1.2 and 1.3 * Removed from ProblemList.txt * Refactored code a bit ------------- Commit messages: - removed extra whitespace - 8298869: Update ConnectionTest.java for changes to TLS implementation Changes: https://git.openjdk.org/jdk/pull/11871/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11871&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298869 Stats: 512 lines in 2 files changed: 93 ins; 172 del; 247 mod Patch: https://git.openjdk.org/jdk/pull/11871.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11871/head:pull/11871 PR: https://git.openjdk.org/jdk/pull/11871 From duke at openjdk.org Fri Jan 6 14:51:54 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 14:51:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References:

Message-ID: On Fri, 6 Jan 2023 04:48:27 GMT, David Holmes wrote: > The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? Hi @dholmes-ora, The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. > If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. Hi @AlanBateman, As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. > I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? If this is generally agreed as a better route then let me know and I'll update the patch. Thanks for both of your comments. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From alanb at openjdk.org Fri Jan 6 15:41:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 15:41:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References:

Message-ID: On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs wrote: > Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? > > If this is generally agreed as a better route then let me know and I'll update the patch. Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Fri Jan 6 15:57:50 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 6 Jan 2023 15:57:50 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References:

Message-ID: On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman wrote: >>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? >> >> Hi @dholmes-ora, >> >> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. >> >> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. >> >> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. >> >>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. >> >> Hi @AlanBateman, >> >> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. >> >>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. >> >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. >> >> Thanks for both of your comments. > >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. > > Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. I agree with @AlanBateman. When we introduced similar warnings in the past, we have enabled support in javac (with some test) in a separate PR, and then followed up with small dedicated PR for each of the various areas (enabling new warnings one by one). See this great umbrella JBS issue (created by @asotona) which has details on all the issues that were filed when we added an extra Lint warning for lossy conversions: https://bugs.openjdk.org/browse/JDK-8286374 They all refer to this: https://bugs.openjdk.org/browse/JDK-8244681 Which was submitted as a separate javac-only PR: https://github.com/openjdk/jdk/pull/8599 ------------- PR: https://git.openjdk.org/jdk/pull/11874 From weijun at openjdk.org Fri Jan 6 15:59:36 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 6 Jan 2023 15:59:36 GMT Subject: RFR: 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo Message-ID: Modern signature algorithms provided by a 3rd-party provider might not be recognized by JDK code yet. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/11883/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11883&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299746 Stats: 62 lines in 2 files changed: 60 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11883.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11883/head:pull/11883 PR: https://git.openjdk.org/jdk/pull/11883 From kdriver at openjdk.org Fri Jan 6 17:35:51 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 6 Jan 2023 17:35:51 GMT Subject: RFR: 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:52:03 GMT, Weijun Wang wrote: > Modern signature algorithms provided by a 3rd-party provider might not be recognized by JDK code yet. Marked as reviewed by kdriver (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11883 From ascarpino at openjdk.org Fri Jan 6 18:26:33 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 6 Jan 2023 18:26:33 GMT Subject: RFR: 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo In-Reply-To: References: Message-ID: <0UZheOlB3pfGygmciZpDrfafjEQQI-bX2QRwViIBtf8=.a18a0d42-9137-4236-b40f-6f883b912e19@github.com> On Fri, 6 Jan 2023 15:52:03 GMT, Weijun Wang wrote: > Modern signature algorithms provided by a 3rd-party provider might not be recognized by JDK code yet. looks good ------------- Marked as reviewed by ascarpino (Reviewer). PR: https://git.openjdk.org/jdk/pull/11883 From hchao at openjdk.org Fri Jan 6 18:32:57 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 6 Jan 2023 18:32:57 GMT Subject: RFR: 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:52:03 GMT, Weijun Wang wrote: > Modern signature algorithms provided by a 3rd-party provider might not be recognized by JDK code yet. Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/11883 From weijun at openjdk.org Fri Jan 6 18:52:03 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 6 Jan 2023 18:52:03 GMT Subject: Integrated: 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:52:03 GMT, Weijun Wang wrote: > Modern signature algorithms provided by a 3rd-party provider might not be recognized by JDK code yet. This pull request has now been integrated. Changeset: ba03f42a Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/ba03f42a50375c05400de9bd19d1d6d444f0a46d Stats: 62 lines in 2 files changed: 60 ins; 0 del; 2 mod 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo Reviewed-by: kdriver, ascarpino, hchao ------------- PR: https://git.openjdk.org/jdk/pull/11883 From xuelei at openjdk.org Fri Jan 6 18:52:01 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 6 Jan 2023 18:52:01 GMT Subject: RFR: 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:52:03 GMT, Weijun Wang wrote: > Modern signature algorithms provided by a 3rd-party provider might not be recognized by JDK code yet. src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 540: > 538: } > 539: if (keyAlg.equals("EC")) keyAlg = "ECDSA"; > 540: String sigAlg = digAlg + "with" + keyAlg; The line could be moved into the try block. ------------- PR: https://git.openjdk.org/jdk/pull/11883 From weijun at openjdk.org Fri Jan 6 21:45:02 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 6 Jan 2023 21:45:02 GMT Subject: RFR: 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo In-Reply-To: References:

Message-ID: On Fri, 6 Jan 2023 18:48:51 GMT, Xue-Lei Andrew Fan wrote: >> Modern signature algorithms provided by a 3rd-party provider might not be recognized by JDK code yet. > > src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 540: > >> 538: } >> 539: if (keyAlg.equals("EC")) keyAlg = "ECDSA"; >> 540: String sigAlg = digAlg + "with" + keyAlg; > > The line could be moved into the try block. You're right. Unfortunately the PR is already closed. I'll remember to fix it next time I touch this code. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11883 From duke at openjdk.org Fri Jan 6 23:13:09 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 23:13:09 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v2] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year for newly added files to 2023. - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/9c162283..f667cd56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00-01 Stats: 1935 lines in 1303 files changed: 60 ins; 1770 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 6 23:13:09 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 23:13:09 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References:

Message-ID: On Tue, 3 Jan 2023 17:45:12 GMT, Volker Simonis wrote: >> Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s. >> >> This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads. >> >> Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe. >> >> I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues. >> >> The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created: >> >> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000 >> 605: 1 32 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) >> >> The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances: >> >> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000 >> 11: 1000 32000 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) >> >> With my proposed patch, the numbers goes back to two instances again: >> >> $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000 >> 611: 2 64 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) >> >> >> I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test. > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright year to 2023 src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 199: > 197: it.remove(); > 198: try { > 199: k.key.destroy(); Is it safe to assume that "key.destroy()" is threadsafe? src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 209: > 207: // Package-private, used only from SessionTicketExtension.KeyState::getCurrentKey. > 208: SessionTicketExtension.StatelessKey getKey(HandshakeContext hc) { > 209: SessionTicketExtension.StatelessKey ssk = keyHashMap.get(currentKeyID); is it safe to assume that the "currentKeyID" initialized/updated before on a different thread can be correctly read here? src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 220: > 218: return ssk; > 219: } > 220: int newID = currentKeyID + 1; Do we actually want to support the whole range of ints here? Probably some limitations can be applied? ------------- PR: https://git.openjdk.org/jdk/pull/11590 From duke at openjdk.org Sat Jan 7 16:24:56 2023 From: duke at openjdk.org (ExE Boss) Date: Sat, 7 Jan 2023 16:24:56 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v2] In-Reply-To: References:

Message-ID: On Fri, 6 Jan 2023 23:13:09 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year for newly added files to 2023. > - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations. src/java.base/share/classes/java/lang/AssertionError.java line 75: > 73: */ > 74: @SuppressWarnings("this-escape") > 75: public AssertionError(Object detailMessage) { The?Javadoc of?this?constructor should?probably?mention that?it?calls `initCause(?)` when?`detailMessage` is?a?`Throwable`. src/java.base/share/classes/java/lang/BootstrapMethodError.java line 77: > 75: * Constructs a {@code BootstrapMethodError} with the specified > 76: * cause. > 77: * Suggestion: * * @implNote This constructor invokes {@link #initCause initCause()}; see * This Escape. * src/java.base/share/classes/java/lang/ExceptionInInitializerError.java line 54: > 52: * throwable object. > 53: * A detail message is a String that describes this particular exception. > 54: */ Suggestion: * * @implNote This constructor invokes {@link #initCause initCause()}; see * This Escape. */ ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Mon Jan 9 14:52:47 2023 From: duke at openjdk.org (Matthew Donovan) Date: Mon, 9 Jan 2023 14:52:47 GMT Subject: RFR: 8298868: Update EngineCloseOnAlert.java for changes to TLS implementation Message-ID: Refactored the code a little bit and updated the test for changes to the TLS state machine. ------------- Commit messages: - 8298868: Update EngineCloseOnAlert.java for changes to TLS implementation Changes: https://git.openjdk.org/jdk/pull/11903/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11903&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298868 Stats: 57 lines in 2 files changed: 16 ins; 9 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/11903.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11903/head:pull/11903 PR: https://git.openjdk.org/jdk/pull/11903 From simonis at openjdk.org Mon Jan 9 16:15:00 2023 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 9 Jan 2023 16:15:00 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v6] In-Reply-To: References:

Message-ID: On Sat, 7 Jan 2023 08:21:38 GMT, Sergey Bylokhov wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright year to 2023 > > src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 209: > >> 207: // Package-private, used only from SessionTicketExtension.KeyState::getCurrentKey. >> 208: SessionTicketExtension.StatelessKey getKey(HandshakeContext hc) { >> 209: SessionTicketExtension.StatelessKey ssk = keyHashMap.get(currentKeyID); > > is it safe to assume that the "currentKeyID" initialized/updated before on a different thread can be correctly read here? Yes, because `currentKeyID` is updated in a synchronized section *after* the corresponding key was added to `keyHashMap`. ------------- PR: https://git.openjdk.org/jdk/pull/11590 From simonis at openjdk.org Mon Jan 9 17:01:00 2023 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 9 Jan 2023 17:01:00 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v6] In-Reply-To: References:

Message-ID: On Sat, 7 Jan 2023 08:26:12 GMT, Sergey Bylokhov wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright year to 2023 > > src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 199: > >> 197: it.remove(); >> 198: try { >> 199: k.key.destroy(); > > Is it safe to assume that "key.destroy()" is threadsafe? First of all, this isn't a change with regards to the old implementation. But in general I don't think this is a problem because the current implementation is using "AES" keys which are generated by `AESKeyGenerator` and are actually plain `SecretKeySpec` keys. These keys don't even implement a `destroy()` method so they will throw `DestroyFailedException` anyway (that's the default implementation of `Destroyable::destroy()`). ------------- PR: https://git.openjdk.org/jdk/pull/11590 From simonis at openjdk.org Mon Jan 9 17:06:04 2023 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 9 Jan 2023 17:06:04 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v6] In-Reply-To: References:

Message-ID: On Sat, 7 Jan 2023 08:24:42 GMT, Sergey Bylokhov wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright year to 2023 > > src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 220: > >> 218: return ssk; >> 219: } >> 220: int newID = currentKeyID + 1; > > Do we actually want to support the whole range of ints here? Probably some limitations can be applied? Why, we used the full range before and with this change we will produce significantly less keys anyway. ------------- PR: https://git.openjdk.org/jdk/pull/11590 From simonis at openjdk.org Mon Jan 9 17:32:01 2023 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 9 Jan 2023 17:32:01 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v5] In-Reply-To: References:

<0DraNUgnD1sGBM7e3jj101i5Dso2znvuEU-z5GYDnPw=.8df7206e-9934-474d-b8c0-c3d87f628c79@github.com> Message-ID: <6eqKCkoL9tPM47hTpuY_gmmT4aI2HpjPvH6D2IpFlVE=.b1d8efd3-248f-4726-ba05-f5ee7478857f@github.com> On Tue, 3 Jan 2023 17:43:43 GMT, Volker Simonis wrote: >> Looks good to me. Thanks! > >> Looks good to me. Thanks! > > Thanks @XueleiFan! > > I've updated the copyright year to 2023 and will wait one or two more days just in case @ascarpino wants to take one more look as well. > Hi @simonis, I am sorry for chiming in so late on this issue. I do think it might be worthwhile to make your proof-of-concept code into a jtreg test as you mentioned in your summary. I think it really comes down to how feasible the conversion would be. It's always better to have an automated test if we can, but it depends on if jtreg code can get access to reliable information about the session tickets via the session cache and know that things are behaving as intended. I don't think the current reproducer can easily be converted into a cheap and stable jterg test. The current version is quite heavyweight because it calls `jcmd GC.class_histogram` and not really stable because it depends on the number of live `StatelessKey` objects in the heap. So for now I'd prefer to finally fix this issue even without an attached automatic test. ------------- PR: https://git.openjdk.org/jdk/pull/11590 From serb at openjdk.org Mon Jan 9 17:37:04 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 9 Jan 2023 17:37:04 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v6] In-Reply-To: References:

Message-ID: On Mon, 9 Jan 2023 16:12:18 GMT, Volker Simonis wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line 209: >> >>> 207: // Package-private, used only from SessionTicketExtension.KeyState::getCurrentKey. >>> 208: SessionTicketExtension.StatelessKey getKey(HandshakeContext hc) { >>> 209: SessionTicketExtension.StatelessKey ssk = keyHashMap.get(currentKeyID); >> >> is it safe to assume that the "currentKeyID" initialized/updated before on a different thread can be correctly read here? > > Yes, because `currentKeyID` is updated in a synchronized section *after* the corresponding key was added to `keyHashMap`. Please clarify that, if the field is updated on one thread under synchronized block, why we will read the correct "currentKeyID" here on another thread if no synchronization is used in this place? ------------- PR: https://git.openjdk.org/jdk/pull/11590 From simonis at openjdk.org Mon Jan 9 18:40:56 2023 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 9 Jan 2023 18:40:56 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v6] In-Reply-To: References:

Message-ID: On Mon, 9 Jan 2023 17:34:06 GMT, Sergey Bylokhov wrote: > Please clarify that, if the field is updated on one thread under synchronized block, why we will read the correct "currentKeyID" here on another thread if no synchronization is used in this place? I only said that if another thread reads the new value of `currentKeyID`, the corresponding key will already be in the `keyHashMap` because that happened before updating `currentKeyID`. If another thread will read the old value of `currentKeyID` that also will be no problem as discussed before in this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11590 From kdriver at openjdk.org Mon Jan 9 21:55:57 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Mon, 9 Jan 2023 21:55:57 GMT Subject: RFR: 8297972: Poly1305 Endianness on ByteBuffer not enforced In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 18:28:21 GMT, Volodymyr Paprotski wrote: > Per rfc7539 Section 2.5, "Read the block as a little-endian number." > > sun.security.util.math.intpoly.IntegerPolynomial1305 enforces this on input when input is provided as `[]byte` but not when input is in `ByteBuffer` > > Tested with `Poly1305IntrinsicFuzzTest.java` from https://github.com/openjdk/jdk/pull/11338 which compares Poly1305 MAC between `ByteBuffer` and `[]byte` ? ------------- PR: https://git.openjdk.org/jdk/pull/11463 From jamil.j.nimeh at oracle.com Tue Jan 10 14:44:36 2023 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 10 Jan 2023 06:44:36 -0800 Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response Message-ID: Hello all, This fixes an issue in OCSP where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. * JBS: https://bugs.openjdk.org/browse/JDK-8296343 https://github.com/openjdk/jdk/pull/11917 Thanks, --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpowers at openjdk.org Tue Jan 10 16:02:56 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 10 Jan 2023 16:02:56 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 06:02:29 GMT, Jamil Nimeh wrote: > This fixes an issue where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. > > - JBS: https://bugs.openjdk.org/browse/JDK-8296343 test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java line 58: > 56: > 57: // Turn on debugging > 58: static final boolean debug = true; Do you really mean to set `debug` to `true`? ------------- PR: https://git.openjdk.org/jdk/pull/11917 From jnimeh at openjdk.org Tue Jan 10 16:49:52 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 10 Jan 2023 16:49:52 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References:

Message-ID: On Tue, 10 Jan 2023 15:49:26 GMT, Mark Powers wrote: >> This fixes an issue where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. >> >> - JBS: https://bugs.openjdk.org/browse/JDK-8296343 > > test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java line 58: > >> 56: >> 57: // Turn on debugging >> 58: static final boolean debug = true; > > Do you really mean to set `debug` to `true`? The overall output is pretty small even with it on, but I'll switch it off. ------------- PR: https://git.openjdk.org/jdk/pull/11917 From xuelei at openjdk.org Tue Jan 10 17:33:00 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 10 Jan 2023 17:33:00 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 06:02:29 GMT, Jamil Nimeh wrote: > This fixes an issue where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. > > - JBS: https://bugs.openjdk.org/browse/JDK-8296343 src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 217: > 215: > 216: int contentLength = con.getContentLength(); > 217: return (contentLength == -1) ? con.getInputStream().readAllBytes() : For the returned OCSP bytes, what if the response code is not OK? ------------- PR: https://git.openjdk.org/jdk/pull/11917 From jnimeh at openjdk.org Tue Jan 10 17:52:56 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 10 Jan 2023 17:52:56 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References:

Message-ID: On Tue, 10 Jan 2023 17:30:08 GMT, Xue-Lei Andrew Fan wrote: >> This fixes an issue where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. >> >> - JBS: https://bugs.openjdk.org/browse/JDK-8296343 > > src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 217: > >> 215: >> 216: int contentLength = con.getContentLength(); >> 217: return (contentLength == -1) ? con.getInputStream().readAllBytes() : > > For the returned OCSP bytes, what if the response code is not OK? Well, in the case of a 404 what appears to happen is that HttpURLConnection would throw a FileNotFoundException. That ultimately would result in a CPVE if there were no other sources of revocation information (e.g. CRL) for that certificate. ------------- PR: https://git.openjdk.org/jdk/pull/11917 From xuelei at openjdk.org Tue Jan 10 18:29:53 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 10 Jan 2023 18:29:53 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References:

Message-ID: On Tue, 10 Jan 2023 17:50:23 GMT, Jamil Nimeh wrote: >> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 217: >> >>> 215: >>> 216: int contentLength = con.getContentLength(); >>> 217: return (contentLength == -1) ? con.getInputStream().readAllBytes() : >> >> For the returned OCSP bytes, what if the response code is not OK? > > Well, in the case of a 404 what appears to happen is that HttpURLConnection would throw a FileNotFoundException. That ultimately would result in a CPVE if there were no other sources of revocation information (e.g. CRL) for that certificate. It may be more effective/accuracy to stop read OCSP response bytes if response code is not OK. ------------- PR: https://git.openjdk.org/jdk/pull/11917 From jnimeh at openjdk.org Tue Jan 10 18:34:54 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 10 Jan 2023 18:34:54 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References:

Message-ID: On Tue, 10 Jan 2023 18:26:50 GMT, Xue-Lei Andrew Fan wrote: >> Well, in the case of a 404 what appears to happen is that HttpURLConnection would throw a FileNotFoundException. That ultimately would result in a CPVE if there were no other sources of revocation information (e.g. CRL) for that certificate. > > It may be more effective/accuracy to stop read OCSP response bytes if response code is not OK. Logging the error code and returning with no read and not throwing an exception I believe would still work since the revocation information would be missing. I'm wondering though if this needs to be a separate issue given that we're talking about a different use case, and one that involves the behavior of HttpURLConnection when dealing with different response codes. I'll also check to see if there are existing tests that make CPV checks against URIs that have non-200 response codes. ------------- PR: https://git.openjdk.org/jdk/pull/11917 From duke at openjdk.org Tue Jan 10 18:34:56 2023 From: duke at openjdk.org (Matthew Donovan) Date: Tue, 10 Jan 2023 18:34:56 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References:

Message-ID: On Tue, 10 Jan 2023 16:47:18 GMT, Jamil Nimeh wrote: >> test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java line 58: >> >>> 56: >>> 57: // Turn on debugging >>> 58: static final boolean debug = true; >> >> Do you really mean to set `debug` to `true`? > > The overall output is pretty small even with it on, but I'll switch it off. You could also use `Boolean.getBoolean("test.debug")` (or some other property name) so it can be set on the command line when the test is run. ------------- PR: https://git.openjdk.org/jdk/pull/11917 From duke at openjdk.org Tue Jan 10 18:34:58 2023 From: duke at openjdk.org (Matthew Donovan) Date: Tue, 10 Jan 2023 18:34:58 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 06:02:29 GMT, Jamil Nimeh wrote: > This fixes an issue where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. > > - JBS: https://bugs.openjdk.org/browse/JDK-8296343 test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java line 146: > 144: > 145: // Wait 5 seconds for server ready > 146: for (int i = 0; (i < 100 && !rootOcsp.isServerReady()); i++) { This pattern is repeated over 20 times in the code. Instead of spinning on a boolean, the SimpleOCSPServer class could use a CountdownLatch to signal when it's ready. Then, instead of having an `isServerReady()` method, it would just have a method e.g., `boolean waitForServer(long timeout, TimeUnit unit)` which just delegates to `CountdownLatch.await(long, TimeUnit)`. And to avoid changing 20+ other tests, just mark `isServerReady()` as deprecated. ------------- PR: https://git.openjdk.org/jdk/pull/11917 From jnimeh at openjdk.org Tue Jan 10 18:45:53 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 10 Jan 2023 18:45:53 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response In-Reply-To: References:

Message-ID: <34IDqy7bba43bqvs2KPBHn9QrxS7_CC8tLoPSE7WXbY=.45bd78e8-2a12-44bf-9da9-d345fecfce25@github.com> On Tue, 10 Jan 2023 18:32:08 GMT, Jamil Nimeh wrote: >> It may be more effective/accuracy to stop read OCSP response bytes if response code is not OK. > > Logging the error code and returning with no read and not throwing an exception I believe would still work since the revocation information would be missing. I'm wondering though if this needs to be a separate issue given that we're talking about a different use case, and one that involves the behavior of HttpURLConnection when dealing with different response codes. I'll also check to see if there are existing tests that make CPV checks against URIs that have non-200 response codes. Hmmm, I was not quite correct about the HttpURLConnection behavior - it's not the 404 that's causing the issue directly, it is indeed the getContentLength when the 404 happens. So forget a separate issue, I will deal with non-200 codes in this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11917 From duke at openjdk.org Tue Jan 10 19:07:43 2023 From: duke at openjdk.org (Matthew Donovan) Date: Tue, 10 Jan 2023 19:07:43 GMT Subject: RFR: 8299870: TLS record version check allows invalid records Message-ID: - Updated ProtocolVersion.isNegotiable() to check a bounded range of version numbers. - Removed IllegalRecordVersion.java from ProblemList.txt Tested with jdk_security and jdk_security3 test groups. ------------- Commit messages: - 8299870: TLS record version check allows invalid records Changes: https://git.openjdk.org/jdk/pull/11929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11929&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299870 Stats: 8 lines in 2 files changed: 5 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11929.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11929/head:pull/11929 PR: https://git.openjdk.org/jdk/pull/11929 From xuelei at openjdk.org Tue Jan 10 19:27:53 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 10 Jan 2023 19:27:53 GMT Subject: RFR: 8299870: TLS record version check allows invalid records In-Reply-To: References: Message-ID: <5Kw5Tu4OL_pC4mqLq5npJfETL_JXJY5uYLJXQX1fUtA=.46ee8d70-6a13-444d-bc3b-fb58ef83a6ef@github.com> On Tue, 10 Jan 2023 18:59:30 GMT, Matthew Donovan wrote: > - Updated ProtocolVersion.isNegotiable() to check a bounded range of version numbers. > - Removed IllegalRecordVersion.java from ProblemList.txt > > Tested with jdk_security and jdk_security3 test groups. This update will introduce version negotiation issues. Per TLS spec, version 105.106 should be allowed and the version could be negotiated properly. When TLS 1.4 is defined later in the future, the code update here will cause serious compatibility issues. This has been a well-known issue in some implementations. If you want to fix the javax/net/ssl/SSLEngine/IllegalRecordVersion.java issue, please refer to the JDK-8042449 patch details. ------------- Changes requested by xuelei (Reviewer). PR: https://git.openjdk.org/jdk/pull/11929 From duke at openjdk.org Tue Jan 10 20:18:55 2023 From: duke at openjdk.org (Matthew Donovan) Date: Tue, 10 Jan 2023 20:18:55 GMT Subject: RFR: 8299870: TLS record version check allows invalid records In-Reply-To: <5Kw5Tu4OL_pC4mqLq5npJfETL_JXJY5uYLJXQX1fUtA=.46ee8d70-6a13-444d-bc3b-fb58ef83a6ef@github.com> References: <5Kw5Tu4OL_pC4mqLq5npJfETL_JXJY5uYLJXQX1fUtA=.46ee8d70-6a13-444d-bc3b-fb58ef83a6ef@github.com> Message-ID: On Tue, 10 Jan 2023 19:25:32 GMT, Xue-Lei Andrew Fan wrote: > This update will introduce version negotiation issues. Per TLS spec, version 105.106 should be allowed and the version could be negotiated properly. When TLS 1.4 is defined later in the future, the code update here will cause serious compatibility issues. This has been a well-known issue in some implementations. I'm not sure what you mean here. Can you point me towards the spec that you're referring to? If we need to support later, currently undefined, versions then is IllegalRecordVersion a valid test? > > If you want to fix the javax/net/ssl/SSLEngine/IllegalRecordVersion.java issue, please refer to the JDK-8042449 patch details. I looked at that original patch and the code history after that. The original patch (JDK-8042449) created/updated `InputRecord.checkRecordVersion()` But then in this [commit](https://github.com/openjdk/jdk/commit/87c6761704ad5ae5f03c0cbc4de33a97ddb9317c#diff-0598abb15a2271a12c36131833ff938ab9d841b1ed69bc1b4eeabfcc460067d8) the `checkRecordVersion()` method was removed entirely and any version-checking was moved to `ProtocolVersion.isNegotiable()`. The original `checkRecordVersion()` is: if ((version.v < ProtocolVersion.MIN.v) || ((version.major & 0xFF) > (ProtocolVersion.MAX.major & 0xFF))) { // if it's not SSLv2, we're out of here. if (!allowSSL20Hello || (version.v != ProtocolVersion.SSL20Hello.v)) { throw new SSLException("Unsupported record version " + version); } } The logic is structured differently, but I'm pretty sure that it's has the same result. ------------- PR: https://git.openjdk.org/jdk/pull/11929 From xuelei at openjdk.org Tue Jan 10 20:38:53 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 10 Jan 2023 20:38:53 GMT Subject: RFR: 8299870: TLS record version check allows invalid records In-Reply-To: References: <5Kw5Tu4OL_pC4mqLq5npJfETL_JXJY5uYLJXQX1fUtA=.46ee8d70-6a13-444d-bc3b-fb58ef83a6ef@github.com> Message-ID: On Tue, 10 Jan 2023 20:16:02 GMT, Matthew Donovan wrote: > > This update will introduce version negotiation issues. Per TLS spec, version 105.106 should be allowed and the version could be negotiated properly. When TLS 1.4 is defined later in the future, the code update here will cause serious compatibility issues. This has been a well-known issue in some implementations. > > I'm not sure what you mean here. Can you point me towards the spec that you're referring to? > Please refer to ["Appendix E. Backward Compatibility"](https://www.rfc-editor.org/rfc/rfc5246#appendix-E) of RFC 5246. Let see an example, suppose TLS 1.4 is defined. If the server is only able to accept TLS 1.3, if the client is using TLS 1.4 format, the connection cannot be established. But TLS 1.3 should be negotiated. BTW, this filed has been deprecated and "MUST be ignored for all purposes" since TLS 1.3 (See RFC 8446). > If we need to support later, currently undefined, versions then is IllegalRecordVersion a valid test? That's the good question. It may worthy of further evaluation and the test case could be removed if it is not valid. ------------- PR: https://git.openjdk.org/jdk/pull/11929 From rhalade at openjdk.org Tue Jan 10 22:49:14 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 10 Jan 2023 22:49:14 GMT Subject: RFR: 8299870: TLS record version check allows invalid records In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 18:59:30 GMT, Matthew Donovan wrote: > - Updated ProtocolVersion.isNegotiable() to check a bounded range of version numbers. > - Removed IllegalRecordVersion.java from ProblemList.txt > > Tested with jdk_security and jdk_security3 test groups. test/jdk/ProblemList.txt line 590: > 588: > 589: javax/net/ssl/SSLEngine/TestAllSuites.java 8298874 generic-all > 590: javax/net/ssl/SSLEngine/IllegalRecordVersion.java 8298873 generic-all I have closed 8298873 as duplicate of this bug. Can you please update IllegalRecordVersion test to list 8299870 under `@bug`. ------------- PR: https://git.openjdk.org/jdk/pull/11929 From serb at openjdk.org Wed Jan 11 02:39:26 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jan 2023 02:39:26 GMT Subject: RFR: 8298381: Improve handling of session tickets for multiple SSLContexts [v6] In-Reply-To: References:

Message-ID: On Mon, 9 Jan 2023 18:38:33 GMT, Volker Simonis wrote: >> Please clarify that, if the field is updated on one thread under synchronized block, why we will read the correct "currentKeyID" here on another thread if no synchronization is used in this place? > >> Please clarify that, if the field is updated on one thread under synchronized block, why we will read the correct "currentKeyID" here on another thread if no synchronization is used in this place? > > I only said that if another thread reads the new value of `currentKeyID`, the corresponding key will already be in the `keyHashMap` because that happened before updating `currentKeyID`. If another thread will read the old value of `currentKeyID` that also will be no problem as discussed before in this PR. So it is possible to have a kind of race here, which is solved by the "synchronized" block below? - If one thread will update the `currentKeyID` and later when other threads will ask for the new key, they might get the old expired key, and to get the new one all those threads have to enter the "synchronized" block. Not sure if is it worth it to skip the volatile keyword or not to get some perf here. But if we cared about performance so much and skip volatile then why we cannot get rid of the `currentKeyID' completely and store the currentkey directly, to skip the map-lookup on a hotpath? The `currentKeyID` will be the id of the current key. The map will contain only expired keys. ------------- PR: https://git.openjdk.org/jdk/pull/11590 From simonis at openjdk.org Wed Jan 11 02:39:28 2023 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 11 Jan 2023 02:39:28 GMT Subject: Integrated: 8298381: Improve handling of session tickets for multiple SSLContexts In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 13:09:11 GMT, Volker Simonis wrote: > Currently, TLS session tickets introduced by [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e. `SessionTicketExtension$StatelessKey`) are generated in the class `SessionTicketExtension` and they use a single, global key ID (`currentKeyID`) for all `SSLContext`s. > > This is problematic if more than one `SSLContext` is used, because every context which requests a session ticket will increment the global id `currentKeyID` when it creates a ticket. This means that in turn all the other contexts won't be able to find a ticket under the new id in their `SSLContextImpl` and create a new one (again incrementing `currentKeyID`). In fact, every time a ticket is requested from a different context, this will transitively trigger a new ticket creation in all the other contexts. We've observed millions of session ticket accumulating for some workloads. > > Another issue with the curent implementation is that cleanup is racy because the underlying data structure (i.e. `keyHashMap` in `SSLContextImpl`) as well as the cleanup code itself are not threadsafe. > > I therefor propose to move `currentKeyID` into the `SSLContextImpl` to solve these issues. > > The following test program (contributed by Steven Collison (https://raycoll.com/)) can be used to demonstrate the current behaviour. It outputs the number of `StatelessKey` instances at the end of the program. Opening 1000 connections with a single `SSLContext` results in a single `StatelessKey` instance being created: > > $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 1 1000 > 605: 1 32 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) > > The same example with the 1000 connections being opened alternatively on thwo different contexts will instead create 1000 `StatelessKey` instances: > > $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000 > 11: 1000 32000 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) > > With my proposed patch, the numbers goes back to two instances again: > > $ java -XX:+UseSerialGC -Xmx16m -cp ~/Java/ SSLSocketServerMultipleSSLContext 9999 2 1000 > 611: 2 64 sun.security.ssl.SessionTicketExtension$StatelessKey (java.base at 20-internal) > > > I've attached the test program to the [JBS issue](https://bugs.openjdk.org/browse/JDK-8298381). If you think it makes sense, I can probably convert it into a JTreg test. This pull request has now been integrated. Changeset: debe5879 Author: Volker Simonis URL: https://git.openjdk.org/jdk/commit/debe5879aa7118a114ff6fcf8d15951757ae70a8 Stats: 143 lines in 3 files changed: 67 ins; 65 del; 11 mod 8298381: Improve handling of session tickets for multiple SSLContexts Reviewed-by: xuelei, ascarpino, serb ------------- PR: https://git.openjdk.org/jdk/pull/11590 From duke at openjdk.org Wed Jan 11 19:52:14 2023 From: duke at openjdk.org (Matthew Donovan) Date: Wed, 11 Jan 2023 19:52:14 GMT Subject: RFR: 8299870: TLS record version check allows invalid records In-Reply-To: References: <5Kw5Tu4OL_pC4mqLq5npJfETL_JXJY5uYLJXQX1fUtA=.46ee8d70-6a13-444d-bc3b-fb58ef83a6ef@github.com>

Message-ID: On Tue, 10 Jan 2023 20:34:49 GMT, Xue-Lei Andrew Fan wrote: > > If we need to support later, currently undefined, versions then is IllegalRecordVersion a valid test? > That's the good question. It may worthy of further evaluation and the test case could be removed if it is not valid. I reworked `IllegalRecordVersion.java` so that it creates a ClientHello with a bad value in that version field, continues the handshake to the end, and then verifies that a version was agreed upon. If that sounds legitimate, I can clean up the code a little and push it. ------------- PR: https://git.openjdk.org/jdk/pull/11929 From xuelei at openjdk.org Thu Jan 12 07:18:14 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 12 Jan 2023 07:18:14 GMT Subject: RFR: 8299870: TLS record version check allows invalid records In-Reply-To: References: <5Kw5Tu4OL_pC4mqLq5npJfETL_JXJY5uYLJXQX1fUtA=.46ee8d70-6a13-444d-bc3b-fb58ef83a6ef@github.com>

Message-ID: On Wed, 11 Jan 2023 19:49:14 GMT, Matthew Donovan wrote: > > > If we need to support later, currently undefined, versions then is IllegalRecordVersion a valid test? > > > That's the good question. It may worthy of further evaluation and the test case could be removed if it is not valid. > > I reworked `IllegalRecordVersion.java` so that it creates a ClientHello with a bad value in that version field, continues the handshake to the end, and then verifies that a version was agreed upon. > > If that sounds legitimate, I can clean up the code a little and push it. I'm fine for this approach. The file/class name could be revised. ------------- PR: https://git.openjdk.org/jdk/pull/11929 From jnimeh at openjdk.org Thu Jan 12 14:41:51 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 12 Jan 2023 14:41:51 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response [v2] In-Reply-To: References: Message-ID: > This fixes an issue where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. > > - JBS: https://bugs.openjdk.org/browse/JDK-8296343 Jamil Nimeh has updated the pull request incrementally with two additional commits since the last revision: - Throw exception directly from non 200 HTTP response codes - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11917/files - new: https://git.openjdk.org/jdk/pull/11917/files/16a60c85..36a0911c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11917&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11917&range=00-01 Stats: 151 lines in 9 files changed: 28 ins; 38 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/11917.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11917/head:pull/11917 PR: https://git.openjdk.org/jdk/pull/11917 From lucy at openjdk.org Thu Jan 12 14:44:35 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 12 Jan 2023 14:44:35 GMT Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls Message-ID: This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect. This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand. Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. **Reviews and comments are very much appreciated.** @backwaterred could you please run some "official" s390 tests? Thanks. ------------- Commit messages: - 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls Changes: https://git.openjdk.org/jdk/pull/11967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11967&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299817 Stats: 714 lines in 5 files changed: 513 ins; 61 del; 140 mod Patch: https://git.openjdk.org/jdk/pull/11967.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11967/head:pull/11967 PR: https://git.openjdk.org/jdk/pull/11967 From duke at openjdk.org Thu Jan 12 15:32:23 2023 From: duke at openjdk.org (Matthew Donovan) Date: Thu, 12 Jan 2023 15:32:23 GMT Subject: RFR: 8299870: TLS record version check allows invalid records [v2] In-Reply-To: References: Message-ID: > - Updated ProtocolVersion.isNegotiable() to check a bounded range of version numbers. > - Removed IllegalRecordVersion.java from ProblemList.txt > > Tested with jdk_security and jdk_security3 test groups. Matthew Donovan has updated the pull request incrementally with three additional commits since the last revision: - renamed IllegalRecordVersion to HandshakeWithInvalidRecordVersion - Updated IllegalRecordVersion - reverted change in ProtocolVersion, updated IllegalRecordVersion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11929/files - new: https://git.openjdk.org/jdk/pull/11929/files/8157cef3..01e0a60a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11929&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11929&range=00-01 Stats: 337 lines in 3 files changed: 258 ins; 79 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11929.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11929/head:pull/11929 PR: https://git.openjdk.org/jdk/pull/11929 From duke at openjdk.org Thu Jan 12 15:36:19 2023 From: duke at openjdk.org (Matthew Donovan) Date: Thu, 12 Jan 2023 15:36:19 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response [v2] In-Reply-To: References:

Message-ID: On Thu, 12 Jan 2023 14:41:51 GMT, Jamil Nimeh wrote: >> This fixes an issue where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. >> >> - JBS: https://bugs.openjdk.org/browse/JDK-8296343 > > Jamil Nimeh has updated the pull request incrementally with two additional commits since the last revision: > > - Throw exception directly from non 200 HTTP response codes > - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java line 154: > 152: // if (!rootOcsp.isServerReady()) { > 153: // throw new RuntimeException("Server not ready yet"); > 154: // } Lines 149-154 can be deleted ------------- PR: https://git.openjdk.org/jdk/pull/11917 From jnimeh at openjdk.org Thu Jan 12 15:46:46 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 12 Jan 2023 15:46:46 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response [v3] In-Reply-To: References: Message-ID: <4PA3y3TEQaFdMcfGKuOGPLW7vk1sMElsRnjYma1qVn4=.5a66c30e-4cfe-4174-a34b-300f785a64d5@github.com> > This fixes an issue where HTTP responses that do not have an explicit Content-Length are causing an EOFException which unravels into a CertPathValidatorException during validations that involve OCSP checks. > > - JBS: https://bugs.openjdk.org/browse/JDK-8296343 Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Remove dead commented code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11917/files - new: https://git.openjdk.org/jdk/pull/11917/files/36a0911c..ddcd124a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11917&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11917&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11917.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11917/head:pull/11917 PR: https://git.openjdk.org/jdk/pull/11917 From jnimeh at openjdk.org Thu Jan 12 15:46:47 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 12 Jan 2023 15:46:47 GMT Subject: RFR: 8296343: CPVE thrown on missing content-length in OCSP response [v2] In-Reply-To: References:

Message-ID: On Thu, 12 Jan 2023 15:31:30 GMT, Matthew Donovan wrote: >> Jamil Nimeh has updated the pull request incrementally with two additional commits since the last revision: >> >> - Throw exception directly from non 200 HTTP response codes >> - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests > > test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java line 154: > >> 152: // if (!rootOcsp.isServerReady()) { >> 153: // throw new RuntimeException("Server not ready yet"); >> 154: // } > > Lines 149-154 can be deleted I thought I caught all the dead comments, but I guess I missed this one. Good catch, will fix. ------------- PR: https://git.openjdk.org/jdk/pull/11917 From xuelei at openjdk.org Thu Jan 12 16:08:20 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 12 Jan 2023 16:08:20 GMT Subject: RFR: 8299870: TLS record version check allows invalid records [v2] In-Reply-To: References:

Message-ID: On Thu, 12 Jan 2023 15:32:23 GMT, Matthew Donovan wrote: >> - Updated ProtocolVersion.isNegotiable() to check a bounded range of version numbers. >> - Removed IllegalRecordVersion.java from ProblemList.txt >> >> Tested with jdk_security and jdk_security3 test groups. > > Matthew Donovan has updated the pull request incrementally with three additional commits since the last revision: > > - renamed IllegalRecordVersion to HandshakeWithInvalidRecordVersion > - Updated IllegalRecordVersion > - reverted change in ProtocolVersion, updated IllegalRecordVersion Would you please update the subject and description of JDK-8299870 so that it fit better with the purpose of the patch? src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java line 70: > 68: static final ProtocolVersion MAX_TLS_SUPPORTED = TLS13; > 69: static final ProtocolVersion MIN_TLS_SUPPORTED = SSL30; > 70: Would you mind restore the update for ProrocolVersion.java? test/jdk/javax/net/ssl/SSLEngine/HandshakeWithInvalidRecordVersion.java line 51: > 49: private static final String TRUSTSTORE_PATH = > 50: System.getProperty("test.src", "./") + "/" + PATH_TO_STORES + > 51: "/" + TRUSTSTORE_FILE; It would be nice to avoid to use binary files. Would you mind to check if test/jdk/javax/net/ssl/templates/SSLContextTemplate.java could be used for the generation of SSLContext (for example test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java)? ------------- PR: https://git.openjdk.org/jdk/pull/11929 From duke at openjdk.org Fri Jan 13 04:03:51 2023 From: duke at openjdk.org (Matthew Donovan) Date: Fri, 13 Jan 2023 04:03:51 GMT Subject: RFR: 8299870: TLS record version check allows invalid records [v3] In-Reply-To: References: Message-ID: <3N1LFwhJpVmWEo6RqVog2Erol7F_h69fcklCeGHgl3s=.54584cfc-e729-42f7-b93b-46a386945baf@github.com> > - Updated ProtocolVersion.isNegotiable() to check a bounded range of version numbers. > - Removed IllegalRecordVersion.java from ProblemList.txt > > Tested with jdk_security and jdk_security3 test groups. Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision: - revert one more chnage - reverted ProtocolVersion and changed to use SSLContextTemplate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11929/files - new: https://git.openjdk.org/jdk/pull/11929/files/01e0a60a..b67c9deb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11929&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11929&range=01-02 Stats: 40 lines in 2 files changed: 2 ins; 26 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11929.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11929/head:pull/11929 PR: https://git.openjdk.org/jdk/pull/11929 From rhalade at openjdk.org Fri Jan 13 04:03:53 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 13 Jan 2023 04:03:53 GMT Subject: RFR: 8299870: TLS record version check allows invalid records [v3] In-Reply-To: <3N1LFwhJpVmWEo6RqVog2Erol7F_h69fcklCeGHgl3s=.54584cfc-e729-42f7-b93b-46a386945baf@github.com> References: <3N1LFwhJpVmWEo6RqVog2Erol7F_h69fcklCeGHgl3s=.54584cfc-e729-42f7-b93b-46a386945baf@github.com> Message-ID: <0eq695H27ozQdlZCog6JZWUsf4N_q159ScujHwgI_Fs=.a5e15d15-85d4-4573-9924-472912437dfb@github.com> On Fri, 13 Jan 2023 00:28:32 GMT, Matthew Donovan wrote: >> - Updated ProtocolVersion.isNegotiable() to check a bounded range of version numbers. >> - Removed IllegalRecordVersion.java from ProblemList.txt >> >> Tested with jdk_security and jdk_security3 test groups. > > Matthew Donovan has updated the pull request incrementally with two additional commits since the last revision: > > - revert one more chnage > - reverted ProtocolVersion and changed to use SSLContextTemplate src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java line 410: > 408: return selectedVersion; > 409: } > 410: } revert this change as well. ------------- PR: https://git.openjdk.org/jdk/pull/11929 From Alan.Bateman at oracle.com Fri Jan 13 08:32:06 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Jan 2023 08:32:06 +0000 Subject: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories In-Reply-To: References: Message-ID: <018e02d9-4d16-65ca-a7b0-c085c01af67b@oracle.com> Forwarding to security-dev as that is where issues around signed JARs are usually discussed. -Alan. On 10/01/2023 17:00, Eirik Bj?rsn?s wrote: > Hi, > > ZipFile.isSignatureRelated currently returns true for paths such as > the following: > > META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA > > While this path does start?with "META-INF/" and ends with ".DSA", > the?file does not live in the META-INF/ directory _directly_, but > rather several directories below. > > This causes such .DSA files to be incorrectly (?) included in the > verification of META-INF/MANIFEST.MF in JarFile.initializeVerifier, > which then fails with: > > Exception in thread "main" java.lang.SecurityException: Invalid > signature file digest for Manifest main attributes > at > java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340) > at > java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282) > at > java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327) > at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239) > at > java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760) > at > java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058) > at > java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72) > at > java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883) > at > java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848) > at > java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760) > at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681) > at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639) > at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > > > A few questions: > > 1: Where Is the exact location of signature related files specified? > > 2: Is the current behaviour indeed incorrect? > > 3: Should ZipFile.isSignatureRelated be updated such that it only > matches signature related files which reside?exactly in "META-INF/" ? > > The context for this is that I'm making a fat jar Maven plugin which > embeds dependency jars by "unpacking" them into subdirectories of > META-INF/libraries/. > > Cheers, > Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Fri Jan 13 11:40:47 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 13 Jan 2023 12:40:47 +0100 Subject: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories In-Reply-To: <018e02d9-4d16-65ca-a7b0-c085c01af67b@oracle.com> References: <018e02d9-4d16-65ca-a7b0-c085c01af67b@oracle.com> Message-ID: Thanks for forwarding me to the right list, Alan For context, I posted a follow-up on the core-libs-dev thread yesterday showing that some other methods have the same problem: https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html And here's a draft PR for a fix, including a test which provokes the various code paths: https://github.com/openjdk/jdk/pull/11976 Cheers, Eirik. On Fri, Jan 13, 2023 at 9:32 AM Alan Bateman wrote: > > Forwarding to security-dev as that is where issues around signed JARs are > usually discussed. > > -Alan. > > > On 10/01/2023 17:00, Eirik Bj?rsn?s wrote: > > Hi, > > ZipFile.isSignatureRelated currently returns true for paths such as the > following: > > > META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA > > While this path does start with "META-INF/" and ends with ".DSA", the file > does not live in the META-INF/ directory _directly_, but rather several > directories below. > > This causes such .DSA files to be incorrectly (?) included in the > verification of META-INF/MANIFEST.MF in JarFile.initializeVerifier, which > then fails with: > > Exception in thread "main" java.lang.SecurityException: Invalid signature >> file digest for Manifest main attributes >> at >> java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340) >> at >> java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282) >> at java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327) >> at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239) >> at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760) >> at java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058) >> at >> java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72) >> at >> java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639) >> at >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > > > A few questions: > > 1: Where Is the exact location of signature related files specified? > > 2: Is the current behaviour indeed incorrect? > > 3: Should ZipFile.isSignatureRelated be updated such that it only matches > signature related files which reside exactly in "META-INF/" ? > > The context for this is that I'm making a fat jar Maven plugin which > embeds dependency jars by "unpacking" them into subdirectories of > META-INF/libraries/. > > Cheers, > Eirik. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jan 13 16:32:17 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 13 Jan 2023 16:32:17 GMT Subject: RFR: 8278349: JarSigner javadoc example uses SHA-1 Message-ID: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> Please review this trivial PR which updates javadoc sample code in jdk.security.jarsigner.JarSigner to use SHA-256, SHA256withRSA instead of the now considered weak algorithms SHA-1, SHA1withDSA. The sample code is also updated to use the new snippet syntax. ------------- Commit messages: - Replace use of weak algorithms SHA-1 and SHA1withDSA in JarSigner javadoc with SHA-256 and SHA256withRSA. Update to use @snippet syntax. Changes: https://git.openjdk.org/jdk/pull/11992/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11992&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278349 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11992.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11992/head:pull/11992 PR: https://git.openjdk.org/jdk/pull/11992 From weijun at openjdk.org Fri Jan 13 16:43:16 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 13 Jan 2023 16:43:16 GMT Subject: RFR: 8278349: JarSigner javadoc example uses SHA-1 In-Reply-To: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> References: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> Message-ID: On Fri, 13 Jan 2023 16:23:13 GMT, Eirik Bjorsnos wrote: > Please review this trivial PR which updates javadoc sample code in jdk.security.jarsigner.JarSigner to use SHA-256, SHA256withRSA instead of the now considered weak algorithms SHA-1, SHA1withDSA. > > The sample code is also updated to use the new snippet syntax. src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 88: > 86: * signer.sign(in, out); > 87: * } > 88: * } You can probably indent the code so that the last 2 lines do not look strange. ------------- PR: https://git.openjdk.org/jdk/pull/11992 From mullan at openjdk.org Fri Jan 13 17:00:15 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 13 Jan 2023 17:00:15 GMT Subject: RFR: 8278349: JarSigner javadoc example uses SHA-1 In-Reply-To: References: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> Message-ID: On Fri, 13 Jan 2023 16:40:03 GMT, Weijun Wang wrote: >> Please review this trivial PR which updates javadoc sample code in jdk.security.jarsigner.JarSigner to use SHA-256, SHA256withRSA instead of the now considered weak algorithms SHA-1, SHA1withDSA. >> >> The sample code is also updated to use the new snippet syntax. > > src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 88: > >> 86: * signer.sign(in, out); >> 87: * } >> 88: * } > > You can probably indent the code so that the last 2 lines do not look strange. This might also be a good opportunity to use the new javadoc @snippet tag (see [JEP 413](url)) which I think has some features to handle the indentation in a consistent manner. ------------- PR: https://git.openjdk.org/jdk/pull/11992 From mullan at openjdk.org Fri Jan 13 17:11:20 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 13 Jan 2023 17:11:20 GMT Subject: RFR: 8278349: JarSigner javadoc example uses SHA-1 In-Reply-To: References: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com>

Message-ID: On Fri, 13 Jan 2023 16:57:36 GMT, Sean Mullan wrote: >> src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 88: >> >>> 86: * signer.sign(in, out); >>> 87: * } >>> 88: * } >> >> You can probably indent the code so that the last 2 lines do not look strange. > > This might also be a good opportunity to use the new javadoc @snippet tag (see [JEP 413](url)) which I think has some features to handle the indentation in a consistent manner. Oh, cool, missed that. Eirik, this issue is currently assigned to @haimaychao, but we can still accept your contribution. Have you or your company signed the OCA? ------------- PR: https://git.openjdk.org/jdk/pull/11992 From sean.mullan at oracle.com Fri Jan 13 17:17:18 2023 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jan 2023 12:17:18 -0500 Subject: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories In-Reply-To: References: <018e02d9-4d16-65ca-a7b0-c085c01af67b@oracle.com> Message-ID: <2a2cebb7-00a6-8401-1e92-ae9cb11a3d62@oracle.com> Off hand it seems like a bug to me, can you file one? The jar specification says that the SF file resides in the META-INF directory and says nothing about subdirectories. --Sean On 1/13/23 6:40 AM, Eirik Bj?rsn?s wrote: > Thanks for forwarding me to the right list, Alan > > For context, I posted a follow-up on the core-libs-dev thread yesterday > showing that some other methods have the same problem: > > https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html > > And here's a draft PR for a fix, including a test which provokes the > various code paths: > > https://github.com/openjdk/jdk/pull/11976 > > > Cheers, > Eirik. > > > On Fri, Jan 13, 2023 at 9:32 AM Alan Bateman > wrote: > > > Forwarding to security-dev as that is where issues around signed > JARs are usually discussed. > > -Alan. > > > On 10/01/2023 17:00, Eirik Bj?rsn?s wrote: >> Hi, >> >> ZipFile.isSignatureRelated currently returns true for paths such >> as the following: >> >> META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA >> >> While this path does start?with "META-INF/" and ends with ".DSA", >> the?file does not live in the META-INF/ directory _directly_, but >> rather several directories below. >> >> This causes such .DSA files to be incorrectly (?) included in the >> verification of META-INF/MANIFEST.MF in >> JarFile.initializeVerifier, which then fails with: >> >> Exception in thread "main" java.lang.SecurityException: >> Invalid signature file digest for Manifest main attributes >> at >> java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340) >> at >> java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282) >> at >> java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327) >> at >> java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239) >> at >> java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760) >> at >> java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058) >> at >> java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72) >> at >> java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681) >> at >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639) >> at >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) >> at >> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> >> >> A few questions: >> >> 1: Where Is the exact location of signature related files specified? >> >> 2: Is the current behaviour indeed incorrect? >> >> 3: Should ZipFile.isSignatureRelated be updated such that it only >> matches signature related files which reside?exactly in "META-INF/" ? >> >> The context for this is that I'm making a fat jar Maven plugin >> which embeds dependency jars by "unpacking" them into >> subdirectories of META-INF/libraries/. >> >> Cheers, >> Eirik. > From duke at openjdk.org Fri Jan 13 17:18:41 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 13 Jan 2023 17:18:41 GMT Subject: RFR: 8278349: JarSigner javadoc example uses SHA-1 [v2] In-Reply-To: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> References: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> Message-ID: > Please review this trivial PR which updates javadoc sample code in jdk.security.jarsigner.JarSigner to use SHA-256, SHA256withRSA instead of the now considered weak algorithms SHA-1, SHA1withDSA. > > The sample code is also updated to use the new snippet syntax. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Indent the javadoc code snippet to make it easier to separate from the snippet syntax ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11992/files - new: https://git.openjdk.org/jdk/pull/11992/files/b288d1fd..56079e31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11992&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11992&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11992.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11992/head:pull/11992 PR: https://git.openjdk.org/jdk/pull/11992 From duke at openjdk.org Fri Jan 13 17:18:44 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 13 Jan 2023 17:18:44 GMT Subject: RFR: 8278349: JarSigner javadoc example uses SHA-1 [v2] In-Reply-To: References: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com>

Message-ID: On Fri, 13 Jan 2023 17:08:01 GMT, Sean Mullan wrote: >> This might also be a good opportunity to use the new javadoc @snippet tag (see [JEP 413](url)) which I think has some features to handle the indentation in a consistent manner. > > Oh, cool, missed that. > > Eirik, this issue is currently assigned to @haimaychao, but we can still accept your contribution. Have you or your company signed the OCA? @seanjmullan I'm already an OCA sigantory, yes. As a contributor, I have no access to JBS so I'll need with that part. Can you sponsor? ------------- PR: https://git.openjdk.org/jdk/pull/11992 From eirbjo at gmail.com Fri Jan 13 17:22:27 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 13 Jan 2023 18:22:27 +0100 Subject: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories In-Reply-To: <2a2cebb7-00a6-8401-1e92-ae9cb11a3d62@oracle.com> References: <018e02d9-4d16-65ca-a7b0-c085c01af67b@oracle.com> <2a2cebb7-00a6-8401-1e92-ae9cb11a3d62@oracle.com> Message-ID: Sean, I'm not an Author (yet! :), so I can't log in to JBS and create issues. I guess the title and description of the draft PR could serve as a starting point for a bug. Note that the Jar File Specification does explicitly say: "Note that if such files are located in META-INF subdirectories, they are not considered signature-related" Thanks, Eirik. On Fri, Jan 13, 2023 at 6:17 PM Sean Mullan wrote: > Off hand it seems like a bug to me, can you file one? The jar > specification says that the SF file resides in the META-INF directory > and says nothing about subdirectories. > > --Sean > > On 1/13/23 6:40 AM, Eirik Bj?rsn?s wrote: > > Thanks for forwarding me to the right list, Alan > > > > For context, I posted a follow-up on the core-libs-dev thread yesterday > > showing that some other methods have the same problem: > > > > > https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html > > > > > > And here's a draft PR for a fix, including a test which provokes the > > various code paths: > > > > https://github.com/openjdk/jdk/pull/11976 > > > > > > Cheers, > > Eirik. > > > > > > On Fri, Jan 13, 2023 at 9:32 AM Alan Bateman > > wrote: > > > > > > Forwarding to security-dev as that is where issues around signed > > JARs are usually discussed. > > > > -Alan. > > > > > > On 10/01/2023 17:00, Eirik Bj?rsn?s wrote: > >> Hi, > >> > >> ZipFile.isSignatureRelated currently returns true for paths such > >> as the following: > >> > >> > META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA > >> > >> While this path does start with "META-INF/" and ends with ".DSA", > >> the file does not live in the META-INF/ directory _directly_, but > >> rather several directories below. > >> > >> This causes such .DSA files to be incorrectly (?) included in the > >> verification of META-INF/MANIFEST.MF in > >> JarFile.initializeVerifier, which then fails with: > >> > >> Exception in thread "main" java.lang.SecurityException: > >> Invalid signature file digest for Manifest main attributes > >> at > >> > java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340) > >> at > >> > java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282) > >> at > >> > java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327) > >> at > >> java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239) > >> at > >> > java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760) > >> at > >> > java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058) > >> at > >> > java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72) > >> at > >> > java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883) > >> at > >> > java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848) > >> at > >> > java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760) > >> at > >> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681) > >> at > >> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639) > >> at > >> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) > >> at > >> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >> > >> > >> A few questions: > >> > >> 1: Where Is the exact location of signature related files specified? > >> > >> 2: Is the current behaviour indeed incorrect? > >> > >> 3: Should ZipFile.isSignatureRelated be updated such that it only > >> matches signature related files which reside exactly in "META-INF/" > ? > >> > >> The context for this is that I'm making a fat jar Maven plugin > >> which embeds dependency jars by "unpacking" them into > >> subdirectories of META-INF/libraries/. > >> > >> Cheers, > >> Eirik. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.org Fri Jan 13 17:47:13 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 13 Jan 2023 17:47:13 GMT Subject: RFR: 8278349: JarSigner javadoc example uses SHA-1 [v2] In-Reply-To: References: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> Message-ID: <9gxbzvi0VHbxBSSMZcQ1u8QGo4_YEX3CKoHgTZbRkXc=.743dbaae-6d37-4c17-8f91-3b6c9828b72d@github.com> On Fri, 13 Jan 2023 17:18:41 GMT, Eirik Bjorsnos wrote: >> Please review this trivial PR which updates javadoc sample code in jdk.security.jarsigner.JarSigner to use SHA-256, SHA256withRSA instead of the now considered weak algorithms SHA-1, SHA1withDSA. >> >> The sample code is also updated to use the new snippet syntax. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Indent the javadoc code snippet to make it easier to separate from the snippet syntax @eirbjo, you can now type `/integrate` and I'll type `/sponsor`. Thanks for the fix! ------------- PR: https://git.openjdk.org/jdk/pull/11992 From duke at openjdk.org Fri Jan 13 17:58:38 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 13 Jan 2023 17:58:38 GMT Subject: Integrated: 8278349: JarSigner javadoc example uses SHA-1 In-Reply-To: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> References: <9uGCpt-jvZ-pEeMr9nByvFAKuoxUnhFJ6wkH0Si2mVE=.51622afc-2747-47ed-b0c5-6d57c0eb6fb7@github.com> Message-ID: On Fri, 13 Jan 2023 16:23:13 GMT, Eirik Bjorsnos wrote: > Please review this trivial PR which updates javadoc sample code in jdk.security.jarsigner.JarSigner to use SHA-256, SHA256withRSA instead of the now considered weak algorithms SHA-1, SHA1withDSA. > > The sample code is also updated to use the new snippet syntax. This pull request has now been integrated. Changeset: 4ec36598 Author: Eirik Bjorsnos Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/4ec3659845486ee9f9227cdfb3f8b47f19462b19 Stats: 11 lines in 1 file changed: 1 ins; 1 del; 9 mod 8278349: JarSigner javadoc example uses SHA-1 Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/11992 From eirbjo at gmail.com Fri Jan 13 20:24:25 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 13 Jan 2023 21:24:25 +0100 Subject: JarWithOneNonDisabledDigestAlg could be made easier to follow Message-ID: Hi, While reviewing the JarWithOneNonDisabledDigestAlg test, I found that the code could perhaps be easier to follow if some updates would be made in the choice of keystore naming and choice of algorithms. I also found potential for some more general code cleanups, and also a way to move expectations of signing counts out of checkThatJarIsSigned method. Knowing well that this fixes no bug, I wanted to hear what people think about the usefulness of such changes before I go the JBS route with a proper PR. Here's a draft PR with my proposed changes: https://github.com/openjdk/jdk/pull/11997 Cheers, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jan 13 20:42:47 2023 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jan 2023 15:42:47 -0500 Subject: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories In-Reply-To: References: <018e02d9-4d16-65ca-a7b0-c085c01af67b@oracle.com> <2a2cebb7-00a6-8401-1e92-ae9cb11a3d62@oracle.com> Message-ID: <21a016bd-da35-c099-a09a-5ea7e7006f3e@oracle.com> Sure, no problem. I filed https://bugs.openjdk.org/browse/JDK-8300140 for this issue. Thanks, Sean On 1/13/23 12:22 PM, Eirik Bj?rsn?s wrote: > Sean, > > I'm not an Author (yet! :), so I can't log in to JBS and create issues. > > I guess the title and description of the draft PR could serve as a > starting?point for a bug. > > Note that the Jar File Specification does explicitly say: > > "Note that if such files are located in META-INF subdirectories, they > are not considered signature-related" > > Thanks, > Eirik. > > On Fri, Jan 13, 2023 at 6:17 PM Sean Mullan > wrote: > > Off hand it seems like a bug to me, can you file one? The jar > specification says that the SF file resides in the META-INF directory > and says nothing about subdirectories. > > --Sean > > On 1/13/23 6:40 AM, Eirik Bj?rsn?s wrote: > > Thanks for forwarding me to the right list, Alan > > > > For context, I posted a follow-up on the core-libs-dev thread > yesterday > > showing that some other methods have the same problem: > > > > > https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html > > > > > And here's a draft PR for a fix, including a test which provokes the > > various code paths: > > > > https://github.com/openjdk/jdk/pull/11976 > > > > > > > > Cheers, > > Eirik. > > > > > > On Fri, Jan 13, 2023 at 9:32 AM Alan Bateman > > > >> wrote: > > > > > >? ? ?Forwarding to security-dev as that is where issues around signed > >? ? ?JARs are usually discussed. > > > >? ? ?-Alan. > > > > > >? ? ?On 10/01/2023 17:00, Eirik Bj?rsn?s wrote: > >>? ? ?Hi, > >> > >>? ? ?ZipFile.isSignatureRelated currently returns true for paths such > >>? ? ?as the following: > >> > >> > ?META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA > >> > >>? ? ?While this path does start?with "META-INF/" and ends with > ".DSA", > >>? ? ?the?file does not live in the META-INF/ directory > _directly_, but > >>? ? ?rather several directories below. > >> > >>? ? ?This causes such .DSA files to be incorrectly (?) included > in the > >>? ? ?verification of META-INF/MANIFEST.MF in > >>? ? ?JarFile.initializeVerifier, which then fails with: > >> > >>? ? ? ? ?Exception in thread "main" java.lang.SecurityException: > >>? ? ? ? ?Invalid signature file digest for Manifest main attributes > >>? ? ? ? ?at > >> > ?java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340) > >>? ? ? ? ?at > >> > ?java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282) > >>? ? ? ? ?at > >> > ?java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327) > >>? ? ? ? ?at > >> > ?java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239) > >>? ? ? ? ?at > >> > ?java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760) > >>? ? ? ? ?at > >> > ?java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058) > >>? ? ? ? ?at > >> > ?java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72) > >>? ? ? ? ?at > >> > ?java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883) > >>? ? ? ? ?at > >> > ?java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848) > >>? ? ? ? ?at > >> > ?java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760) > >>? ? ? ? ?at > >> > ?java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681) > >>? ? ? ? ?at > >> > ?java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639) > >>? ? ? ? ?at > >> > ?java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) > >>? ? ? ? ?at > >> > ?java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >> > >> > >>? ? ?A few questions: > >> > >>? ? ?1: Where Is the exact location of signature related files > specified? > >> > >>? ? ?2: Is the current behaviour indeed incorrect? > >> > >>? ? ?3: Should ZipFile.isSignatureRelated be updated such that it > only > >>? ? ?matches signature related files which reside?exactly in > "META-INF/" ? > >> > >>? ? ?The context for this is that I'm making a fat jar Maven plugin > >>? ? ?which embeds dependency jars by "unpacking" them into > >>? ? ?subdirectories of META-INF/libraries/. > >> > >>? ? ?Cheers, > >>? ? ?Eirik. > > > From duke at openjdk.org Fri Jan 13 20:56:19 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 13 Jan 2023 20:56:19 GMT Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories Message-ID: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF. The mentioned call sites needs updates to check and ignore such files. A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored. ------------- Commit messages: - Merge branch 'master' into signature-related-subdirs - Files residing in subdirectories of META-INF/ should not be treated as signature related Changes: https://git.openjdk.org/jdk/pull/11976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300140 Stats: 235 lines in 5 files changed: 227 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11976.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976 PR: https://git.openjdk.org/jdk/pull/11976 From darcy at openjdk.org Fri Jan 13 21:52:55 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 13 Jan 2023 21:52:55 GMT Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs Message-ID: With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base. ------------- Commit messages: - JDK-8300133: Use generalized see and link tags in core libs Changes: https://git.openjdk.org/jdk/pull/12000/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12000&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300133 Stats: 107 lines in 10 files changed: 0 ins; 19 del; 88 mod Patch: https://git.openjdk.org/jdk/pull/12000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12000/head:pull/12000 PR: https://git.openjdk.org/jdk/pull/12000 From jjg at openjdk.org Fri Jan 13 22:33:13 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 13 Jan 2023 22:33:13 GMT Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 21:30:06 GMT, Joe Darcy wrote: > With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base. Nice to see all those ` References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com> Message-ID: On Thu, 12 Jan 2023 18:44:26 GMT, Eirik Bjorsnos wrote: > Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF. > > The mentioned call sites needs updates to check and ignore such files. > > A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored. Just some comments before the end of week. src/java.base/share/classes/java/util/zip/ZipFile.java line 1748: > 1746: .isBlockOrSF(new String(name, off, len, UTF_8.INSTANCE) > 1747: .toUpperCase(Locale.ENGLISH))); > 1748: How about updating `SignatureFileVerifier.isBlockOrSF` so that it only returns true for files inside `META-INF/`. This way it's consistent to this method. src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 980: > 978: * Returns true iff the entry resides directly in the META-INF/ directory > 979: */ > 980: private boolean isInMetaInf(ZipEntry ze) { Maybe move this method and the one in `JarVerifier` to a common place like `sun.security.util.SignatureFileVerifier`? test/jdk/java/util/jar/JarFile/VerifyUnrelatedSignatureFiles.java line 61: > 59: File j = createJarFile(); > 60: File s = signJarFile(j, "signed"); > 61: File m = moveSignatureRelated(s); Try sign it again to a different file. Let's see if the moved files are also signed. ------------- PR: https://git.openjdk.org/jdk/pull/11976 From naoto at openjdk.org Fri Jan 13 22:41:12 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 13 Jan 2023 22:41:12 GMT Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 21:30:06 GMT, Joe Darcy wrote: > With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base. src/java.base/share/classes/java/util/ResourceBundle.java line 270: > 268: * are packaged in a JAR file. Resource bundle only JAR file can be readily > 269: * deployed as an {@linkplain java.lang.module.ModuleFinder##automatic-modules > 270: * automatic module1}. For example, if the JAR file contains the Typo: extra `1` ------------- PR: https://git.openjdk.org/jdk/pull/12000 From mchung at openjdk.org Fri Jan 13 22:46:10 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 13 Jan 2023 22:46:10 GMT Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 21:30:06 GMT, Joe Darcy wrote: > With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base. src/java.base/share/classes/java/util/ResourceBundle.java line 270: > 268: * are packaged in a JAR file. Resource bundle only JAR file can be readily > 269: * deployed as an {@linkplain java.lang.module.ModuleFinder##automatic-modules > 270: * automatic module1}. For example, if the JAR file contains the typo : `module1`? ------------- PR: https://git.openjdk.org/jdk/pull/12000 From darcy at openjdk.org Fri Jan 13 22:54:47 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 13 Jan 2023 22:54:47 GMT Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs [v2] In-Reply-To: References: Message-ID: > With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo found in code review. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12000/files - new: https://git.openjdk.org/jdk/pull/12000/files/aa623f2a..0e4d4e4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12000&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12000&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12000.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12000/head:pull/12000 PR: https://git.openjdk.org/jdk/pull/12000 From mchung at openjdk.org Fri Jan 13 22:54:47 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 13 Jan 2023 22:54:47 GMT Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs [v2] In-Reply-To: References:

Message-ID: <1y-NxkBIqDQ4RlBuXC7czlGB-jsPd3m8jNrPD9-wzUk=.9eb0f9d7-a9cc-4791-88c8-b3253ea97607@github.com> On Fri, 13 Jan 2023 22:50:53 GMT, Joe Darcy wrote: >> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo found in code review. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12000 From naoto at openjdk.org Fri Jan 13 22:54:47 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 13 Jan 2023 22:54:47 GMT Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs [v2] In-Reply-To: References: