On Wed, 15 Apr 2026 15:53:29 GMT, Alan Bateman <[email protected]> wrote:
>> 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. > > Just to be clear, I'm not not suggesting changing the keytool -cacerts > option, my comment was about the keytool man page. I initially thought the > man page referenced lib/security/cacerts but reading it again, it's the > security properties file. We may have forgotten to change the file paths to > conf/security. Just to conclude on this. I think the --cacerts option and have it take a list of aliases is fine. For the wording then it might be a bit clearer to say "with only the certificates ..." rather than putting "only" at the end. Part of also thinks that "<alias> is the name of an alias in the cacerts keystore" should say the cacerts keystore in the java.base module (as this is where jlink gets the certificates). Summary - useful feature when creating a run-time image for a specific application or usage. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29700#discussion_r3094531512
