Windows does ship its own klist.exe file on C:\Windows\System32. This started with Windows Vista. I was not aware that these were not shipped in non-Windows JDK builds, thanks for the update.
An alternative for developers to continue interacting with Kerberos, is by using 3rd-party solutions such as MIT Kerberos [1]. But for the JDK, it is now odd that it ships a kinit while Windows has its own. [1] https://web.mit.edu/kerberos/dist/index.html ________________________________ From: Wei-Jun Wang <weijun.w...@oracle.com> Sent: October 9, 2024 1:18 PM To: Bruno Borges <bruno.bor...@microsoft.com> Cc: security-dev@openjdk.org <security-dev@openjdk.org> Subject: [EXTERNAL] Re: RFC: Remove Kerberos CLI tools from OpenJDK bin folder You don't often get email from weijun.w...@oracle.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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.bor...@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
