On Wed, 15 Apr 2026 08:45:29 GMT, Severin Gehwolf <[email protected]> wrote:
>>> In a jmod-less JDK, we can propagate the `java.security` changes by passing >>> `--ignore-modified-runtime` to `jlink`, getting a warning (expand to see an >>> example). >> >> Interesting - this option seems to be undocumented and not mentioned in JEP >> 493. Is there a reason? >> >> Your proposal seems more prone to make mistakes where you inadvertently >> include modifications from the configuration file in the JDK binary -- for >> example perhaps you were testing and made some temporary changes to the >> `java.security` file and forgot to change it back, unless you do a diff >> against the original you may not notice them. Using the `jlink >> --security-properties <filename>` option is a more specific action where >> nothing is happening behind the scenes w/o your knowledge, and there is a >> file that you can specifically audit to see the exact properties that are >> being modified. If you really want to do this, I think you need to modify >> the original source file and do your own build of the JDK. > >> > In a jmod-less JDK, we can propagate the `java.security` changes by >> > passing `--ignore-modified-runtime` to `jlink`, getting a warning (expand >> > to see an example). >> >> Interesting - this option seems to be undocumented and not mentioned in JEP >> 493. Is there a reason? > > Yes, as you say it's not recommended to use this option. It should stay that > way. Since it was not clear what kind of post-processing JDK vendors do ahead > of the JEP it's been a useful option. So far the proposal to support includes seems a reasonable compromise: --security-properties props=<filename>:include=/etc/crypto-policies/back-ends/java.config ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3085184031
