On Tue, 5 May 2026 17:07:07 GMT, Sean Mullan <[email protected]> wrote:
>> So far the proposal to support includes seems a reasonable compromise: >> >> >> --security-properties >> props=<filename>:include=/etc/crypto-policies/back-ends/java.config > > I've been thinking more about this. The `include` option as specified above > always adds the `include` statement as the last line of the `java.security` > file. An equivalent way to support this would to be allow the `include` > statement to be specified in the property file of the `props` option, but > always add it at the end of the `java.security` file, thus making the > `include` option unnecessary. This would simplify the syntax and > implementation. Thoughts? > @seanjmullan one problem would be with the order of the property file passed > as the `props` option. For example, with `jlink --security-properties > props.security`: > > `props.security` contents: > > ```ini > include /path/to/other.properties > > # Stricter keystore checking > keystore.type.compat=false > ``` > > `/path/to/other.properties` might define `keystore.type.compat`, but its > value is overriden. > > However, the linked image would have the following `java.security`: > > ```ini > # [...] other properties from the runtime's java.security > keystore.type.compat=false > # [...] other properties from the runtime's java.security > include=/path/to/other.properties > ``` > > `/path/to/other.properties` might define (and now override) > `keystore.type.compat`. Right, but we previously discussed this and the consensus was that adding a single `include` at the end of the `java.security` file was sufficient. What I was proposing was just a simpler way to support adding an `include` statement at the end of the `java.security` file w/o having an additional option. So, two assumptions could be made: - order of properties is not preserved (this is already an assumption) - `include` statement is always added at end of file regardless of where it resides in the props file. If more than one `include` statement appears then either throw an exception, or last one wins. I could be ok with the current proposal, but as you will see (when I post an updated PR) it is a bit more complicated just to support an additional option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3190898866
