On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman <al...@openjdk.org> wrote:
>>> 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. >> >> I'm not entirely sure what you are suggesting. Is it keeping a list of >> "upgradeable" files in a properties file. Files listed in that properties >> file aren't checked for hash sums (i.e. even if it's not modified)? That is, >> the explicit opt-in is not needed? Fine by me, but it's a weaker check. If >> we don't need the explicit opt-in, the patch becomes simpler as well. >> >>> Right now the only examples we have are in java.base. In time it might be >>> that some other modules might need something. >> >> Sure. I've considered that. The `java.base` specific check can go away and >> it should work for any module as long as we have a list of what's considered >> an upgradable file (wherever it comes from). >> >>> 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? >> >> Yes, that's one case. For example Fedora/RHEL distros have a >> `ca-certificates` package which also provides a `cacerts` file consumable >> from the JDK (`/etc/pki/java/cacerts`). This can be a build-time option, or >> replaced with a symlink after the JDK has been built. >> >> Another use case is amending the cacerts store. For example with an >> enterprise internal CA, in a container. It's really not different to >> `tzdb.dat`. That too, can be a symlink to a system package or get updated >> with an external tool after a build. >> >> The option of not following symlinks, isn't an option, though, as certain >> distro packaging standards require one to install, say man pages - in a >> specific directory. To keep the JDK image whole, that is usually fixed by >> placing a symlink back in the JDK image directory. > >> I'm not entirely sure what you are suggesting. Is it keeping a list of >> "upgradeable" files in a properties file. Files listed in that properties >> file aren't checked for hash sums (i.e. even if it's not modified)? That is, >> the explicit opt-in is not needed? Fine by me, but it's a weaker check. If >> we don't need the explicit opt-in, the patch becomes simpler as well. > > Yes, I think keep simple. We always want to allow tzdb.dat be upgraded by the > TZ updater tool. I think treating cacerts the same way is okay. As you note, > it has to be kept up to date too. I was thinking keytool import and wasn't > sure if the Linux distros configure with `-with-cacerts-file` or did > something else. Thanks for the clarification on this point. > > Starting with a simple list of two files won't preclude us from re-visiting > it again in the future. @AlanBateman Any more thoughts on this? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2792010497
