RFC: Remove Kerberos CLI tools from OpenJDK bin folder

[Wei-Jun Wang]

Hi Bruno,

I don’t quite understand the motivation. When you say "The presence of these CLI tools can cause conflicts with native versions provided by the operating system”, what is the operating system you are referring to? For example, many *nix systems come preinstalled with its own kinit, but JDK on those systems does not have kinit. The only platform where JDK has kinit is on Windows but as far as I know Windows does not have its own kinit. (Or does it have one now? Or, will there be one soon?)

Thanks,
Weijun

On Oct 9, 2024, at 14:51, Bruno Borges <Bruno.Borges at microsoft.com> wrote:

Hi folks,

I am writing to seek your feedback and opinions on a proposal to remove the Kerberos command-line tools (e.g., kinit, klist, etc.) from OpenJDK. The Kerberos CLI tools have traditionally been included in the JDK to facilitate the management of Kerberos tickets directly through the command line. However, I believe that these tools may no longer be necessary within JDK distributions.

The presence of these CLI tools can cause conflicts with native versions provided by the operating system. This is particularly evident with kinit, which may overshadow the system’s version, leading to ambiguity and potential issues with the PATH configuration. This surfaces more prominently on Windows where all JDK vendors equally document their Windows installation guide - and also configure their Windows installers - to prepend (at the beginning of) PATH with the JDK bin folder, causing the conflict.

Additionally, most modern environments provide native Kerberos tools that are well-integrated with the OS's Kerberos libraries and configurations. By relying on these tools, developers can ensure compatibility and make use of the most up-to-date Kerberos utilities provided by the system. By reducing the number of executable files bundled with the JDK, we can also limit potential vulnerabilities.

The proposal would only affect the Kerberos command-line tools; the underlying support in Java, such as the Krb5LoginModule, GSSAPI, and other Java APIs for Kerberos authentication, would remain unaffected. Java applications would continue to interact with Kerberos through these APIs without any disruption.

I would greatly appreciate the community’s input on this proposal:

- Do you see any scenarios where the removal of these tools might create challenges?
- Would making these tools optional or available as a separate package be a more suitable approach?
- Are there any specific use cases or environments where these CLI tools are still frequently used?

Thank you for your time, and I look forward to your insights.

Best regards,
Bruno Borges
Microsoft

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20241009/0bb974f0/attachment-0001.htm>