On Mon, 13 Apr 2026 20:05:39 GMT, Francisco Ferrari Bihurriet <[email protected]> wrote:
>>> I think an alternative to point to a whole `java.security` replacement, or >>> an option to pass-trhough `conf/security/java.security` with its >>> modifications into the image would be great for our use-case. >> >> 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. >> I am not sure what you mean by your second sentence, what is a pass-through >> option? > >> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3075524613
