RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493

[Alan Bateman]

On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is hard-coded to `lib/tzdb.dat` and `lib/security/cacerts`. Only those two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. The upgrade needs to be opt-in. Similar to `--ignore-signing-information` for signed modular JARs. A user needs to add `--upgrade-files=<module>/<file-path>` for it to succeed.
> 
> `--upgrade-files` is a hidden `jlink` option since it only does anything for JEP 493 enabled builds. Users get a hint to apply the option if they so desire:
> 
> Example:
> 
> 
> $ ./bin/jlink --add-modules java.base --output java.base-jdk
> Error: [..]/lib/security/cacerts has been modified
> Hint: lib/security/cacerts is an upgradeable file. Add --upgrade-files=java.base/lib/security/cacerts to allow the upgrade.
> 
> 
> using the hint we get:
> 
> 
> $ ./bin/jlink --add-modules java.base --output java.base-jdk --upgrade-files=java.base/lib/security/cacerts
> $ ./java.base-jdk/bin/java --list-modules
> java.base at 25-internal
> $ sha512sum ./java.base-jdk/lib/security/cacerts 
> cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146  ./java.base-jdk/lib/security/cacerts
> $ sha512sum ./lib/security/cacerts 
> cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146  ./lib/security/cacerts
> 
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

Part of me is concerned that the hidden option is a bit of an attractive nuisance. What would you think about just having a fixed list in a properties file in the repo, thus a resource in the jlink module. This would avoid the list in JRTArchive too. It wouldn't rule out introducing something more in the future.

Right now the only examples we have are in java.base. In time it might be that some other modules might need something.

I've like to know more about cacerts. Are the distros swapping this to a link after the run-time image is created or is it that the sym link is there from the startup and the hashing has followed the link?

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

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2775120209