On Tue, 14 Apr 2026 14:22:15 GMT, Sean Mullan <[email protected]> wrote:
>>> I think a possible middle ground is to have a separate option that adds a >>> single include directive to the end of the java.security file, and that's >>> _the only case that is supported_. Include directives in the properties >>> file are still treated as an error. I would have to experiment with this, >>> but something like: >>> >>> `jlink --security-properties >>> props=<filename>:include=/etc/crypto-policies/back-ends/java.config` >> >> While not fully convenient, this would probably also work for our use case, >> if we make some adjustments. The alternative from my previous comment would >> have the advantage of not dealing with the `include` directive at all. > >> An option that puts `conf/security/java.security` into the custom run-time >> created with `jlink` (even if the file was modified). The first names that >> come to mind are `--keep-security-properties-changes`, >> `--use-runtime-security-properties`, or `--security-properties >> runtime-conf`, probably not the best ones. >> >> For a jmod JDK, the option would mean using `conf/security/java.security` >> instead of the pristine copy from `jmods/java.base.jmod`. >> >> For a jmod-less JDK (which already uses `conf/security/java.security`), the >> option would mean skipping the integrity check. > > Just so I understand you, I think you want to modify > `conf/security/java.security` in the JDK binary that you use to run `jlink` > and have that preserved when using `jlink` to create the custom runtime? If I > am getting this wrong, can you explain in steps what you are trying to do? > Thanks. I think it's important to read the "Restrictions" section of JEP 493. This restriction is to avoid cloning insecure or ad hoc config. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3080201552
