Re: removing MK_GSSAPI

When I wrote libgssapi, it seemed possible that other mechanisms might be
useful but that didn't happen in the end. I did spend some effort in
writing half decent manpages for the library. It might be nice to keep
those if MIT kerberos doesn't have good manpages but otherwise, libgssapi
can be retired.

Doug.

On Tue, 12 Aug 2025 at 10:02, Brooks Davis <brooks@freebsd.org> wrote:

> On Mon, Aug 11, 2025 at 09:29:31AM -0700, Rick Macklem wrote:
> > On Mon, Aug 11, 2025 at 8:49???AM Cy Schubert <Cy.Schubert@cschubert.com>
> wrote:
> > >
> > > In message <aJoEZhS5_JQbjLRK@freefall.freebsd.org>, Lexi Winter
> writes:
> > > > hello,
> > > >
> > > > i've posted a review to remove the WITHOUT_GSSAPI src.conf knob in
> 15.0:
> > > > https://reviews.freebsd.org/D51859.  my rationale for this is that
> since
> > > > this is already a no-op for MIT Kerberos, there's no real need to
> keep
> > > > it around for legacy Heimdal and removing it simplifies the build
> logic
> > > > a little, since you either have Kerberos or you don't.
> > > >
> > > > Cy suggested that we might instead want to modify MIT Kerberos to
> make
> > > > WITHOUT_GSSAPI do something.  i'm not sure this is useful, because
> > > > without GSSAPI you can't really use Kerberos for anything even if you
> > > > build it; in particular, both ssh and gssd require GSSAPI.  in the
> past,
> > > > this knob might have made sense since base gssapi was separate from
> the
> > > > implementation (Heimdal), but with MIT Kerberos, this is no longer
> true.
> > > >
> > > > but, perhaps there's a reason to keep this knob around?
> > >
> > > My thoughts,
> > >
> > > lib/libgssapi uses Heimdal data structures. GSS apps will run into
> trouble
> > > when using MIT's GSSAPI with libgssapi.
> > >
> > > MIT's GSSAPI can replace our libgssapi. Installing it by itself is
> > > pointless.  I agree with removing MK_GSSAPI. There are people here with
> > > more history than I. I understand why we might want GSSAPI without
> > > Kerberos, there could be other GSS providers. Is this realistic?
> > Highly unlikely, I think. Once upon a time, GSSAPI was envisioned to
> > someday have a variety of mechanisms, with Kerberos being one possible
> > one. That has never happened, and since MIT sticks the GSSAPI in the
> > same library as the Kerberos mechanism glue, I cannot see a GSSAPI
> > that does not use Kerberos as ever likely to happen.
> >
> > The only mumbling about other mechanisms I've heard is for Oauth2
> > (or whatever that token stuff is called), but all that ever seemed to
> > happen is getting an OID for it. (It would actually be nice to have, I
> > think, but I'm not volunteered to write it.;-)
>
> In principal Globus GSI has a GSSAPI interface for federated login, but
> I'm not convinced it sees much use vs Oauth2 these days (it's still in
> Ubuntu and Red Hat repo though).  I wouldn't worry about this since it's
> had 20+ years to catch on and hasn't outside some niche environments.
>
> -- Brooks
>
>