On Mon, Jul 28, 2025 at 7:04 AM Rick Macklem <rick.mack...@gmail.com> wrote:
> 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. > > > > > > > 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.) > > Note that MIT krb5 provides the gss_krb5_export_lucid_sec_context() API that does a lot of the work of getting useful bits out of an established GSS security context. > > > > 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?) > > I think adapting this to the MIT krb5 code is feasible. I think that kg_ctx_externalize() is where the actual exported security context token is produced (no structure, just bashing bytes out into the buffer). -Ben
