RFC: Remove Kerberos CLI tools from OpenJDK bin folder

[Bruno Borges]

Perhaps a simpler solution is not to remove them, but to rename these tools so they remain available but without conflicting with potentially system-available tools.

Any thoughts in renaming them to:

  *
jkinit.exe
  *
jklist.exe
  *
jktab.exe

________________________________
From: security-dev <security-dev-retn at openjdk.org> on behalf of Bernd <ecki at zusammenkunft.net>
Sent: October 10, 2024 1:46 AM
To: security-dev at openjdk.org <security-dev at openjdk.org>
Subject: [EXTERNAL] Re: RFC: Remove Kerberos CLI tools from OpenJDK bin folder

You don't often get email from ecki at zusammenkunft.net. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hello,

I agree that this duplication is quite confusing (I tried to find out before why it’s shipped and if it is related to keycache format, since the native tools in Windows are a bit tricky to understand in that regard if I remember my struggles correctly).

So before removing it it (on windows) would maybe be a good thing to validate the native tool on windows supports the usecases (besides the native cache SSPI mode which does not use a cache file, right?). It might help troubleshooting if Java Klist.exe uses the api from JDK so we are more sure the entries are found/understood by any jgss code?

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: security-dev <security-dev-retn at openjdk.org> im Auftrag von Bruno Borges <Bruno.Borges at microsoft.com>
Gesendet: Mittwoch, Oktober 9, 2024 11:24 PM
An: security-dev at openjdk.org <security-dev at openjdk.org>
Betreff: Re: RFC: Remove Kerberos CLI tools from OpenJDK bin folder

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.wang at oracle.com>
Sent: October 9, 2024 1:18 PM
To: Bruno Borges <Bruno.Borges at microsoft.com>
Cc: security-dev at openjdk.org <security-dev at openjdk.org>
Subject: [EXTERNAL] Re: RFC: Remove Kerberos CLI tools from OpenJDK bin folder

You don't often get email from weijun.wang at 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.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



--
http://bernd.eckenfels.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20241010/8c999227/attachment-0001.htm>