On Mon, 13 Jul 2026 15:19:17 GMT, Sean Mullan <[email protected]> wrote:
> Alternate implementation - this version only contains one argument - the name > of the properties file. If an include statement is needed, it should be > inserted in the properties file and it will always be added as the last line > of the the conf/security/java.security configuration file.. > > See https://github.com/openjdk/jdk/pull/30635 for the other implementation. > > This is a new jlink plugin which allows the user to specify values of > security properties it wants to override in the conf/security/java.security > configuration file in a custom runtime image. This enhancement, along with > https://github.com/openjdk/jdk/pull/29700 allow users to more easily create > runtimes that address the specific security requirements of their > applications. > > The command-line syntax takes a file containing properties that the user > wants to override. The file can also contain an include statement which will > be added as the last line of the conf/security/java.security configuration > file. > > For example: > > jlink --security-properties props.security > > where props.security is a file containing one more more properties in the > java.security file syntax. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Hi @seanjmullan, I agree with @jerboaa and I prefer this alternative. I'm leaving an additional comment that applies to both alternatives. I will be on PTO the next two weeks. So I appreciate if the comment is addressed at some level, but please do not consider it a blocker. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SecurityPropertiesPlugin.java line 123: > 121: // assume "=" used as delimiter > 122: int index = line.indexOf('='); > 123: if (index != -1) { @seanjmullan: assuming `=` would likely discard any `include` or unusual property in the original build-time `java.security` file. Perhaps you have already ruled out the following for some reason, but ideally we should reuse the properties file parsing logic, automatically supporting everything documented in [java.util.Properties::load(java.io.Reader)](https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)). We could decuple the parsing logic from the `Hashtable`, so we can have a version that preserves the order. For example, move `java.util.Properties.LineReader` and a modified version of `java.util.Properties::load0` to a common place. The modified version allows line 459 to be customized with a callback: https://github.com/openjdk/jdk/blob/79aa0d7af1264737d1724cee039f4f02315aee70/src/java.base/share/classes/java/util/Properties.java#L413-L461 The new `java.util.Properties::load0` passes `(key, value) -> put(key, value)` as the callback, while the _security properties jlink plugin_ uses a callback with the logic of replacing the value if present in the user-provided file, loaded in `Map<String, String> props`. --- An intermediary step would be at least using `java.util.Properties.LineReader` for a unified line continuation parser. --- If you dislike the idea, shouldn't we document this behavior somewhere? Developers modifying `java.security` in the future could introduce properties using a different (documented) separator. We also prefer the space separator for `include` directives, as shown in the [Security Properties File guide](https://docs.oracle.com/en/java/javase/26/security/security-properties-file.html#GUID-FF09EB34-CD27-4D1B-B55B-A4A4E6A0F039) examples. The same applies to downstream projects modifying `java.security` before building (not a problem for Red Hat, but perhaps for other vendors). ------------- PR Review: https://git.openjdk.org/jdk/pull/31884#pullrequestreview-4935970880 PR Review Comment: https://git.openjdk.org/jdk/pull/31884#discussion_r3782662282
