In message <CAM5tNy63Ri73x3ByJUPFh7a0eCVjWPGW1hQwrkG0wz6pJ6-W3Q@mail.gmail.c om> , Rick Macklem writes: > On Tue, Jul 22, 2025 at 9:00=E2=80=AFAM 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 <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>, Jessic= > a > > > > Clarke w > > > > rites: > > > > > On 21 Jul 2025, at 15:10, Cy Schubert <c...@freebsd.org> wrote: > > > > > >=3D20 > > > > > > The branch main has been updated by cy: > > > > > >=3D20 > > > > > > URL: =3D > > > > > https://cgit.FreeBSD.org/src/commit/?id=3D3Dc7da9fb90b0b6385e99bb77= > 47476359 > > > b=3D > > > > > 712993fa > > > > > >=3D20 > > > > > > 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 > > > > > >=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-cleanu= > p.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%27= > s_u > > se_of_Heimdal_symbols,_with_MIT_differences. > I know diddly about how libraries are handled, but is it possible to put th= > e > 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.
I can take a look at it. However any app that issues GSSAPI calls will eventually call the MIT library as defined in /etc/gss/mech. The 1.2.840.113554.1.2.2 OID will point to the MIT gssapi_krb5.so instead of the Heimdal gssapi_krb5. > > 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.) Unfortunately some apps make use of private data that Kerberos does not share. As gssd issues GSSAPI calls through libgssapi which in turn calls lilbgssapi_krb5 supplied by the installed Kerberos (MIT or Heimdal) an alternate libgssapi will also be needed. I cannot guarantee this will work because of potential prebuild conflicts. But it's certainly worth a try. Another option may be to revert WITH_MITKRB5 until 16 to give us more time to solve this without the Heimdal libraries. Short answer, I'm certainly willing to try to have Heimdal and MIT libraries coexist. I think the show stopper could be conflicting header files in prebuild, though I think I can put those in /usr/include/heimdal or some place like it. Libraries would need to be named libheim*. This would work well with our build system. I'm not sure how this might affect pkgbase. It would probably be best for WITH_MITKRB5 to be disabled while working on this. As some here who I've intimated to, a life thing happened here that has complicated things. > > rick > > > > > > > -- > > Cheers, > > Cy Schubert <cy.schub...@cschubert.com> > > FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org > > NTP: <c...@nwtime.org> Web: https://nwtime.org > > > > e**(i*pi)+1=3D0 > > > > -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e**(i*pi)+1=0
