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. @seanjmullan > 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. Yes, just to make sure we are understanding each other, I refer to the following concrete examples: <details><summary>In a jmod-full JDK, we cannot propagate the <code>java.security</code> changes (expand to see an example).</summary> # Download Oracle JDK 26 (jmod-full) cd /tmp arch="$(uname -m | sed 's/x86_64/x64/;s/arm64/aarch64/')" curl -sSL "https://download.oracle.com/java/26/latest/jdk-26_linux-${arch}_bin.tar.gz"; | tar -xvz # Modify java.security cat <<'EOF' >>jdk-26/conf/security/java.security # Apply crypto-policies include /etc/crypto-policies/back-ends/java.config EOF # Create a new custom image jdk-26/bin/jlink --add-modules=java.base --output jdk-26-custom # Check if java.security changes are propagated to the image tail -4 jdk-26-custom/conf/security/java.security # Shows unmodified java.security # Cleanup rm -rf jdk-26* </details> <details><summary>In a jmod-less JDK, we can propagate the <code>java.security</code> changes by passing <code>--ignore-modified-runtime</code> to <code>jlink</code>, getting a warning (expand to see an example).</summary> # Download Adoptium Temurin JDK 25 (jmod-less) cd /tmp curl -qsSL "https://api.adoptium.net/v3/assets/latest/25/hotspot?image_type=jdk&os=linux&architecture=$(uname -m)" | python3 '-BIScimport sys,json;print(json.load(sys.stdin)[0]["binary"]["package"]["link"])' | xargs curl -sSL | tar -xvz # Modify java.security cat <<'EOF' >>jdk-25.*/conf/security/java.security # Apply crypto-policies include /etc/crypto-policies/back-ends/java.config EOF # Create a new custom image jdk-25.*/bin/jlink --add-modules=java.base --ignore-modified-runtime --output jdk-25-custom # Prints: Warning: /tmp/jdk-25.0.2+10/conf/security/java.security has been modified # Check if java.security changes are propagated to the image tail -4 jdk-25-custom/conf/security/java.security # Shows modified java.security with the include # Cleanup rm -rf jdk-25* </details> I'm proposing a `jlink` option like `--with-runtime-security-properties-modifications`, which means the user is explicitly asking to use the modified file, so: * In a jmod-full link, it uses `conf/security/java.security` instead of `jmods/java.base.jmod` * In a jmod-less link, it keeps using `conf/security/java.security`, but doesn't check its integrity * With `--ignore-modified-runtime`, it doesn't print a warning * Without `--ignore-modified-runtime`, it doesn't fail @AlanBateman > I think it's important to read the "Restrictions" section of JEP 493. This > restriction is to avoid cloning insecure or ad hoc config. Yes, I agree, please note I'm not suggesting to change any default. Just proposing an alternative way for the user to specify values of security properties: modify `java.security` and have an option for `jlink` to honor the changes. I don't see it as a security downgrade when compared with `--security-properties props.security`, because `props.security` could also contain insecure or ad hoc config. @seanjmullan: I hope the alternative is clearer now, if you prefer `--security-properties props=<filename>:include=/etc/crypto-policies/back-ends/java.config` is ok to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3080783250
