On Fri, 14 Aug 2026 09:40:36 GMT, Francisco Ferrari Bihurriet <[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). > > 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). Properties.load/save is read/write and doesn't support round trip. The semantics here is a transformation that retains the comments and whitespace, allowing inline replace of values. It would requite significant refactor to provide this via a jdk.internal package exported to jdk.jlink. Not opposed to this but I think first explore if there a generally useful API for Properties to expose to allow programs do these types of transformations. As regards the processProperties loop then I think it will need to handle the 3 possible separators. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31884#discussion_r3804512555
