On Tue, 14 Apr 2026 15:56:14 GMT, Francisco Ferrari Bihurriet <[email protected]> wrote:
>>> 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... > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3081952432
