Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default

On Mon, Jul 28, 2025 at 1:20 AM Konstantin Belousov <kostikbel@gmail.com> wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca.
>
> On Sun, Jul 27, 2025 at 08:26:03PM -0700, Rick Macklem wrote:
> > On Tue, Jul 22, 2025 at 9:00 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> > >
> > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca.
> > >
> > > In message <aH98iNXobigu39On@kib.kiev.ua>, Konstantin Belousov writes:
> > > > On Mon, Jul 21, 2025 at 07:46:45AM -0700, Cy Schubert wrote:
> > > > > In message <47C3CC37-6F32-4376-900A-B5387B9817D5@freebsd.org>, Jessica
> > > > > Clarke w
> > > > > rites:
> > > > > > On 21 Jul 2025, at 15:10, Cy Schubert <cy@freebsd.org> wrote:
> > > > > > >=20
> > > > > > > The branch main has been updated by cy:
> > > > > > >=20
> > > > > > > URL: =
> > > > > > https://cgit.FreeBSD.org/src/commit/?id=3Dc7da9fb90b0b6385e99bb7747476359
> > > > b=
> > > > > > 712993fa
> > > > > > >=20
> > > > > > > commit c7da9fb90b0b6385e99bb7747476359b712993fa
> > > > > > > Author:     Cy Schubert <cy@FreeBSD.org>
> > > > > > > AuthorDate: 2025-07-19 14:11:18 +0000
> > > > > > > Commit:     Cy Schubert <cy@FreeBSD.org>
> > > > > > > CommitDate: 2025-07-21 14:07:22 +0000
> > > > > > >=20
> > > > > > >    KRB5: Enable MIT KRB5 by default
> > > > > > >=20
> > > > > > >    Set WITH_MITKRB5=3Dyes as the default.
> > > > > > >=20
> > > > > > >    Rebuild all USES=3Dgssapi ports is recommended.
> > > > > > >=20
> > > > > > >    A clean buildworld is required.
> > > > > >
> > > > > > That=E2=80=99s going to be quite annoying and cause a lot of issues =
> > > > > > given
> > > > > > WITH_CLEAN is now the default. Can we do something in depend-cleanup.sh
> > > > > > to delete everything from the obj tree that needs to be rebuilt if we
> > > > > > detect the wrong kerberos implementation was previously built?
> > > > >
> > > > > All binaries that depend on any kerberos libraries must be rebuilt.
> > > > > WITHOUT_CLEAN will fail at various spots. Meta mode should take care of
> > > > > this for us.
> > > > Does the statement mean that ABI for the base libraries was broken?
> > > > If yes, and the new libs have the same name as the old, we must bump
> > > > dso versions.
> > >
> > > Three new libs have the same names. Most don't. The three with the same
> > > names are libkrb5, libgssapi_krb5 and libcom_err.
> > >
> > > libgssapi_krb5 is a merge of the Heimdal libgssapi_* files. For example,
> > > there is no libgssapi_spnego in MIT.
> > >
> > > The libcom_err contains the same but updated MIT functions.
> > >
> > > libkrb5 removes Heimdal-only functions.
> > >
> > > There is no libasn1 nor libroken in MIT.
> > >
> > > The differences are outlined at https://k5wiki.kerberos.org/wiki/Samba%27s_u
> > > se_of_Heimdal_symbols,_with_MIT_differences.
> > I know diddly about how libraries are handled, but is it possible to put the
> > old Heimdal 1.5.2 libraries somewhere (semi-private) under different names?
> >
> > I ask because it is going to be very difficult to port the gssd to the
> > new libraries.
> >
> > The problem is that the KGSSAPI code assumes some stuff very specific
> > to Heimdal. Take a look at sys/kgssapi/krb5/krb5_mech.c and you'll see
> > what I mean. (There's code that parses the keys etc out of the internally
> > generated tokens. I have no idea where to even find the information on
> > how/where the MIT code hides this stuff and it a large part of krb5_mech.c
> > looks like it will have to be re-written to work with the MIT libraries.)
>
> It might be better to extract the required bits and keep just them.
> Perhaps even moving that bits from vendor to FreeBSD-owned code area.
>
> I do not think that keeping large pieces of code in vendor without updates
> is a good plan.
I will work on it. I just cannot guarantee timing.

The next step to getting the gssd to work with MIT is finding the MIT
structure that gss_ctx_id_t refers to. If that structure isn't a lot
different than the Heimdal one, the conversion shouldn't be too bad.
(I'll start on that to-day.)

I understand that this does need to be upgraded.
It is unfortunate that the KGSSAPI code is wired specifically for
Heimdal. (Another approach would be to add a new upcall to the
gssd daemon to extract the keys and then, hopefully, a kerberos
library call could be used instead of having a "home rolled"
chunk of code in the kernel that has to be updated whenever
the structure returned by the library call changes.)

I didn't realize this existed until yesterday when I bumped
into it while debugging the kerberized NFS mount.

If you glance at krb5_import() in sys/kgssapi/krb5/krb5_mech.c,
you'll see how messy this could get.

rick