On Fri, 10 Apr 2026 19:44:37 GMT, Sean Mullan <[email protected]> wrote:
>> Just on the ">>" discussion. I think the downside is that the resulting >> java.security may have duplicate keys with different values. The files in >> $JAVA_HOME/conf are user editable so if someone were to edit java.security >> then they could easily change the value of the first key and the change >> would not be effective. > >> I meant the latter, the problem we observed with `cat props >> >> conf/security/java.security` is while linking a jmod-less image. The SHA-512 >> checksum of the original `conf/security/java.security` file is stored in the >> jimage file (`lib/modules`). So if we modify `conf/security/java.security` >> and run `jlink` (in a jmod-less JDK), we get `Error: >> .../conf/security/java.security has been modified`. > > Why don't you get the error in a jmod JDK? Just trying to understand the > distinction. > Just on the ">>" discussion. I think the downside is that the resulting > java.security may have duplicate keys with different values. The files in > $JAVA_HOME/conf are user editable so if someone were to edit java.security > then they could easily change the value of the first key and the change would > not be effective. Yes, that is a downside, and one that should not be taken lightly. In an actual deployment, in order for the include directive to be used, I think it must be included at least once in the `java.security` file (assuming you are not using `-Djava.security.properties`). Let's take 3 cases where it might be included: 1. at the beginning of the file. This doesn't make any sense as all properties after that would be overridden. It would have no impact. 2. at the end of the file. This is the easiest case, and one that could be supported equivalently by adding at the end. 3. somewhere in the middle. I don't know if this is common since the properties don't have any specific order, and we could change the order if we wanted. I think this would be more common in the included files themselves. Plus the include directive could also be somewhere in the beginning or middle of the properties file and that makes it more like how it is handled currently if specified with the `-Djava.security.properties` option. All in all, this becomes very complex to support all of these cases within the current implementation. And adding the whole file at the end has downsides as mentioned above. 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` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3066609280
