Date: Mon, 28 Jul 2025 07:03:49 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Jessica Clarke <jrtc27@freebsd.org>, Cy Schubert <cy@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default Message-ID: <CAM5tNy6pAUS1HD4W1=rxLXvfctAs1Ms_fxwUWz1X3tFNuVTVZg@mail.gmail.com> In-Reply-To: <aIcyq6JuYngAm4Ko@kib.kiev.ua> References: <202507211410.56LEAD6J066633@gitrepo.freebsd.org> <47C3CC37-6F32-4376-900A-B5387B9817D5@freebsd.org> <20250721144645.3BA391BE@slippy.cwsent.com> <aH98iNXobigu39On@kib.kiev.ua> <20250722155941.AC7EB121@slippy.cwsent.com> <CAM5tNy63Ri73x3ByJUPFh7a0eCVjWPGW1hQwrkG0wz6pJ6-W3Q@mail.gmail.com> <aIcyq6JuYngAm4Ko@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 28, 2025 at 1:20=E2=80=AFAM Konstantin Belousov <kostikbel@gmai= l.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=E2=80=AFAM Cy Schubert <Cy.Schubert@cschub= ert.com> wrote: > > > > > > CAUTION: This email originated from outside of the University of Guel= ph. 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 ITh= elp@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>, Je= ssica > > > > > Clarke w > > > > > rites: > > > > > > On 21 Jul 2025, at 15:10, Cy Schubert <cy@freebsd.org> wrote: > > > > > > >=3D20 > > > > > > > The branch main has been updated by cy: > > > > > > >=3D20 > > > > > > > URL: =3D > > > > > > https://cgit.FreeBSD.org/src/commit/?id=3D3Dc7da9fb90b0b6385e99= bb7747476359 > > > > b=3D > > > > > > 712993fa > > > > > > >=3D20 > > > > > > > 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 > > > > > > >=3D20 > > > > > > > KRB5: Enable MIT KRB5 by default > > > > > > >=3D20 > > > > > > > Set WITH_MITKRB5=3D3Dyes as the default. > > > > > > >=3D20 > > > > > > > Rebuild all USES=3D3Dgssapi ports is recommended. > > > > > > >=3D20 > > > > > > > A clean buildworld is required. > > > > > > > > > > > > That=3DE2=3D80=3D99s going to be quite annoying and cause a lot= of issues =3D > > > > > > given > > > > > > WITH_CLEAN is now the default. Can we do something in depend-cl= eanup.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 rebuil= t. > > > > > WITHOUT_CLEAN will fail at various spots. Meta mode should take c= are 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 bum= p > > > > dso versions. > > > > > > Three new libs have the same names. Most don't. The three with the sa= me > > > names are libkrb5, libgssapi_krb5 and libcom_err. > > > > > > libgssapi_krb5 is a merge of the Heimdal libgssapi_* files. For examp= le, > > > 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/Samb= a%27s_u > > > se_of_Heimdal_symbols,_with_MIT_differences. > > I know diddly about how libraries are handled, but is it possible to pu= t the > > old Heimdal 1.5.2 libraries somewhere (semi-private) under different na= mes? > > > > 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 internal= ly > > 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_mec= h.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. The problem is that the code in sys/kgssapi/krb5/krb5_mech.c does contain bits extracted from the Heimdal code. Basically, a detailed knowledge of an internal structure that the keys are extracted from. --> I am now thinking that adding an upcall to the gssd and letting it extr= act the keys might be a better plan. (At least it moves the maintenance t= o userland and, hopefully, library calls can replace the detailed knowl= edge about the internals of the implementation.) > > I do not think that keeping large pieces of code in vendor without update= s > is a good plan. Agreed. I'll work on it. (But no guarantees w.r.t. timeline.) Maybe doing a transition to Heimdal 7.8 (or 8.n) would be less painful? (It looks like Heimdal is getting maintenance these days. I think Debian is using it, which suggests it will get at least some TLC?) rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy6pAUS1HD4W1=rxLXvfctAs1Ms_fxwUWz1X3tFNuVTVZg>