RFR: 8312434: SPECjvm2008/xml.transform with CDS fails with "can't seal package nu.xom"

[Ioi Lam]

On Fri, 18 Aug 2023 04:57:52 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Problem:
> A jar file containing classes in a sealed package and is signed with a "disabled" algorithm as indicated in the  `jdk.jar.disabledAlgorithms` security property. Some of the classes are stored in a CDS archive. During runtime, if a class is loaded from the archive followed by loading a class from the jar file, resulting in sealing violation.
> 
> Cause:
> During dump time, CDS considers the jar file as signed although it should be treated as unsigned due to the algorithm used is in the "disabled" list. Currently, CDS doesn't store the manifest of a signed jar in the archive since CDS doesn't support signed classes. During runtime, since there's no manifest info, when a class is loaded from the archive, a package entry is created without sealing information. When a subsequent class from the same package is loaded from the jar, an attempt to create a package entry with sealing information would fail.
> 
> Fix:
> It is difficult in the hotspot code to determine if an algorithm for signing the jar is considered "disabled". The fix is to always store the jar manifest in the CDS archive.
> 
> Testing:
> Passed tiers 1 - 4 (including the new test).

Looks good to me with a small nit for the test case.

Also, can we remove the `SharedClassPathEntry::is_signed()` API as well?

test/hotspot/jtreg/runtime/cds/appcds/JarBuilder.java line 265:

> 263:     static final String jarSigner = JDKToolFinder.getJDKTool("jarsigner");
> 264: 
> 265:     public static void signJarWithDisabledAlg(String jarName) throws Exception {

I would suggest using full spelling of `signJarWithDisabledAlgorithm`

-------------

PR Review: https://git.openjdk.org/jdk/pull/15339#pullrequestreview-1587644943
PR Review Comment: https://git.openjdk.org/jdk/pull/15339#discussion_r1300508298