On Mon, 13 Apr 2026 20:08:30 GMT, Francisco Ferrari Bihurriet <[email protected]> wrote:
>>> I don't want to support a whole java.security file replacement. That is too >>> fragile as any property you miss can end up having no value as the default. >> >> Makes sense. >> >>> I am not sure what you mean by your second sentence, what is a pass-through >>> option? >> >> 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. > >> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3080146383
