On Mon, Jul 28, 2025 at 1:20 AM Konstantin Belousov <kostik...@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 > ith...@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.schub...@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 > > > ith...@uoguelph.ca. > > > > > > In message <ah98inxobigu3...@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-b5387b981...@freebsd.org>, Jessica > > > > > Clarke w > > > > > rites: > > > > > > On 21 Jul 2025, at 15:10, Cy Schubert <c...@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 <c...@freebsd.org> > > > > > > > AuthorDate: 2025-07-19 14:11:18 +0000 > > > > > > > Commit: Cy Schubert <c...@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. 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 extract the keys might be a better plan. (At least it moves the maintenance to userland and, hopefully, library calls can replace the detailed knowledge about the internals of the implementation.)
> > I do not think that keeping large pieces of code in vendor without updates > 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
