Created attachment 249111 [details] Affected files Heimdal in base (1.5.2) is 12+ years old. It has problems with OpenSSL 3.x. Applications crash at runtime, e.g., bind's nsupdate recently and newly msktutil, kt5start (https://forums.freebsd.org/threads/ldap-issues-on-freebsd-14-0.91345/) and likely other Kerberos-enabled applications. I think it is about time to remove Heimdal base support from ports and force ports either to link to security/heimdal or security/krb5 or none at all. A non-exhaustive list of affected files/ports: (see attachment)
There is an ongoing work to switch base Kerberos from Heimdal to MIT. It would amend this issue.
(In reply to Gleb Popov from comment #1) This issue is a precursor to the switch. cy@ and me discussed this briefly and our understanding is that the GSS-API flavor in base should be only for base (private), not for the outside world.
I don't have enough expertise to judge whether this decision is good. Is there some sort of summary on pros and cons for making a base library private and switching non-base consumers to the ports version? We have private sqlite, AFAIK, but OpenSSL is still public. How do we decide on such things?
(In reply to Gleb Popov from comment #3) There is no public discussion -- yet. OpenSSL is special, it is fairly up to date, but looking at how many contrib stuff is in base it hard for src maintainers to keep them uptodate. I think every lib deserves a separate discussion.
Can you list output of uname -a, please? PR/272835 recently resolved a bug similar, if not the same as, this bug. It was MFCed to stable/14 but was not MFSed to releng/14.0. The patch will be in releng/14.1. work A workaround for 14.0-RELEASE users is to apply the workaround in comment #2 of PR/272835 until 14.1-RELEASE becomes GA. If you use 14.0-RELEASE, please try the patch in PR/272835. If you use 14-STABLE, update to the latest 14-STABLE. I've reset this bug from ports & packages to base system and taken the bug myself.
emaste@, should we MFS c7db2e15e404 and 17e941a0c88c to releng/14.0 and publish an errata?
(In reply to Cy Schubert from comment #6) > emaste@, should we MFS c7db2e15e404 and 17e941a0c88c to releng/14.0 and publish an errata? I think we should. I've added it to secteam's tracking list.
I'd also like to follow along and understand the decision to switch base kerberos to MIT; more specifically, why base kerberos is desirable at all. Is there ongoing discussion on the choice to continue including kerberos in base?How many users are depending on base kerberos as it stands, since base Heimdal is 12+ years old? For the applications that enable kerberos support (e.g. sshd, , why not force users to build those applications from ports and set the corresponding OPTIONS to enable GSSAPI/kerberos support? As I understand it, both Heimdal and MIT kerberos are third-party projects. This would also remove maintenance burden of vendor imports of newer kerberos versions in the future. I'm personally content with choosing my preferred vendor of kerberos through ports.
For me, SSHd w/o Kerberos is barely usable. Forcing users to not have something as vital as SSH w/o Kerberos is quite a blocker. I am open to better solutions in base w/o resorting to ports first.
(In reply to Michael Osipov from comment #9) Correct. This is the primary reason for Kerberos in base. In the beginning telnet and ftp were kerberized. Subsequently ssh. I for one do not use ssh keys within my network. I use Kerberos TGTs.
Then why not build security/openssh-portable from ports and set the GSSAPI option there? What are the clear advantages of having kerberos included in base and forcing GSSAPI support to be enabled in base-provided sshd? Additionally, aren't current users who depend on base-provided Kerberos subject to any possible CVEs that have affected Heimdal in base (or MIT krb5 once that gets hypothetically included into base) since 12 years ago? Heimdal and MIT krb5 are up-to-date in the ports collection right now. I agree that kerberos support in sshd is great, since I use it in my own servers as well. But since I build my own private poudriere repo, I'm able to quite easily select the latest (with all security patches included) GSSAPI provider from ports and use that to build ports-provided sshd with GSSAPI enabled.
(In reply to Siva Mahadevan from comment #11) This is a profound and complex question. This is best answered by Cy, but from my PoV for many it'd be quite unpleasant to rely on SSH from non-base since it is vital...
(In reply to Michael Osipov from comment #12) I still feel that this is a vague argument in favour of keeping it in base. For users that desire a kerberized sshd, here are the advantages of relying on openssh-portable from ports in my eyes: * users can simply 'pkg upgrade' to immediately get security and feature upgrades to openssh and kerberos at the cadence that they wish * sshd in base will potentially have a smaller attack surface if GSSAPI is disabled * Both currently-supported providers of kerberos are up-to-date in ports, along with their -devel counterparts for those who wish to use bleeding-edge providers. This is a big one, since Heimdal has been stuck on 7.8.0 for quite some time, but the upstream git project has seen recent active development and fixes. * The duplication of work for maintainers to update both base and ports kerberos providers is removed * Users can wish to link against port-provided OpenSSL as well The only disadvantage that I can see is that users will not be provided out-of-the-box with a default batteries-included environment that supports kerberized services like sshd or others.
(In reply to Michael Osipov from comment #12) Short answer is POLA. This is not something to be decided here. If people want to discuss this they should open a new topic on the freebsd-arch mailing list. This bug has been resolved by the last batch of FreeBSD-SA announcements.
(In reply to Siva Mahadevan from comment #8) Sorry, I'm coming late to this discussion... > (e.g. sshd, , why not force users to build those applications from ports > and set the corresponding OPTIONS to enable GSSAPI/kerberos support? Because when FreeBSD is installed. Users should have a reasonably complete system that MUST provide reasonably secure (encrypted) communication. This includes using encrypted channels to add to, or upgrade their system. (s)ftp,telnet, and ssh require this. Regardless of the outcome of this GSSAPI discussion here. The above must be guaranteed. I'm guessing the sec team wouldn't have it any other way. :)
(In reply to Cy Schubert from comment #14) I need respectfully to reopen because: a) this isn't a bug, but rather an improvement request/task for the future b) the actual issue hasn't been resolved in ports (removing GSSAPI_BASE) c) the mentioned issue were just an example which problems come with Heimdal from base d) no one should use such an old Heimdal version w/o knowning the consequences
(In reply to Siva Mahadevan from comment #8) Kerberos in base is required for Kerberized NFS, unless there's some way for the base gssd to use Kerberos from ports -- which i imagine would require rebuilding base from source with ports Kerberos installed, an un-ideal situation. it's unfortunate that the base Kerberos is so old (because, among other things, it's lacking support for newer cyphers), but the import of MIT Kerberos should solve that particular issue.
(In reply to Lexi Winter from comment #17) I am working on replacing our ancient Heimdal with MIT 1.21.2.
(In reply to Lexi Winter from comment #17) For some reason this has got into the wrong category. This is solely about ports, not base at all.
Michael, Cy -- yeah, i know (on both points), but since someone asked in comment 8 why Kerberos is in base at all, i just wanted to point out that, besides sshd, NFS also needs it :-)
Why is this assigned to portmgr? It this for an exp-run? (there is 0 patch attached) Also, was this discussed with clusteradm? ( GSSAPI_BASE is used in the FreeBSD cluster )
(In reply to Antoine Brodin from comment #21) I selected assign to default checkbox and this is what it did. Probably because michaelo@ changed the category from bin to ports framework. I can take this if this is a base system PR. If it's ports framework, I don't think I should handle this.
(In reply to Lexi Winter from comment #20) I would never dare to remove Kerberos from base for base because that would break way too much stuff.
(In reply to Cy Schubert from comment #22) I guess I have unfortunately selected the wrong option from begin with. Let me clarify: This PR does not intend to change the base system at all. It is solely about ports to to provide an option to link/reference GSS-API from base anymore because of the reasons mentioned earlier. I'd be will to provide such a back against the ports system if we agree that this is a reasonable step. After that, there should be only: none, mit, heimdal while mit being the default.
(In reply to Michael Osipov from comment #24) Did you discuss this with clusteradm? In the FreeBSD cluster, we do use some ports with GSSAPI_BASE.
(In reply to Antoine Brodin from comment #25) No, because I wanted to have public discussion. Added clusteradm@.