On Wed, 15 Apr 2026 14:45:36 GMT, Alan Bateman <[email protected]> wrote:
>> I can try to make this more abstract I suppose, but it will make it a bit >> more unuser-friendly, because I would need to ask for the pathname to the >> keystore so as not to assume it is the cacerts keystore, right? I have to >> minimally assume it is a keystore though, since there is no other standard >> API to get the root certificates. > > We should probably create an issue in JBS to look at the keytool man page. We > might have missed that when moving to the run-time image in JDK 9. > > I think the `--cacerts` option name and having its values be a list of > aliases is okay. The plugin will use the resource in java.base.jmod so should > be no need to specify a file path. The most correct technical name for this would be "trust anchors", so I can consider changing the option name to --trust-anchors and changing wording to "the keystore containing trust anchors". However, keep in mind that developers have gotten used to the `cacerts` keystore name, so there may be some confusion. You do need to know what is already in the `cacerts` keystore to effectively use this option, at least with a JDK based on the OpenJDK source. As for `keytool`, I don't think we can or should change the `-cacerts` option name. My guess is you are concerned with the words "the `cacerts` keystore" in various places and the pathnames under the `-cacerts` option. It is kind of hard to word around this and make the docs easy to understand though. The `cacerts` keystore is an essential important part of developing and debugging secure Java applications. But I can file an issue to see if we can abstract this a bit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29700#discussion_r3087640673
