On Fri, 10 Apr 2026 20:31:36 GMT, Sean Mullan <[email protected]> wrote:
>>> 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` > Why don't you get the error in a jmod JDK? Just trying to understand the > distinction. In a jmod JDK, the `lib/modules` image doesn't contain the checksums. Instead, `jlink` obtains a pristine `java.security` copy from `jmods/java.base.jmod`, ignoring any change to `conf/security/java.security`. So we don't get an error, but, as with a jmod-less JDK, there's no way to propagate the `conf/security/java.security` changes to the image. I think an alternative to point to a whole `java.security` replacement, or an option to pass-trhough `conf/security/java.security` with its modifications into the image would be great for our use-case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3067275393
