Date: Mon, 28 Jul 2025 15:04:46 -0700 From: Benjamin Kaduk <bjkfbsd@gmail.com> To: Rick Macklem <rick.macklem@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, 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: <CAJ5_RoBjpX_BoKgZTdOof5b83cdxjZyvn4iPM4m5voPHEr2SeQ@mail.gmail.com> In-Reply-To: <CAM5tNy6pAUS1HD4W1=rxLXvfctAs1Ms_fxwUWz1X3tFNuVTVZg@mail.gmail.com> 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> <CAM5tNy6pAUS1HD4W1=rxLXvfctAs1Ms_fxwUWz1X3tFNuVTVZg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Mon, Jul 28, 2025 at 7:04 AM Rick Macklem <rick.macklem@gmail.com> wrote: > 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. > > > > > > > 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 [-- Attachment #2 --] <div dir="ltr"><div dir="ltr">On Mon, Jul 28, 2025 at 7:04 AM Rick Macklem <<a href="mailto:rick.macklem@gmail.com">rick.macklem@gmail.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jul 28, 2025 at 1:20 AM Konstantin Belousov <<a href="mailto:kostikbel@gmail.com" target="_blank">kostikbel@gmail.com</a>> wrote:<br> ><br> > 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 <a href="mailto:IThelp@uoguelph.ca" target="_blank">IThelp@uoguelph.ca</a>.<br> ><br> > On Sun, Jul 27, 2025 at 08:26:03PM -0700, Rick Macklem wrote:<br> > > On Tue, Jul 22, 2025 at 9:00 AM Cy Schubert <<a href="mailto:Cy.Schubert@cschubert.com" target="_blank">Cy.Schubert@cschubert.com</a>> wrote:<br> > > ><br> > > > 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 <a href="mailto:IThelp@uoguelph.ca" target="_blank">IThelp@uoguelph.ca</a>.<br> > > ><br>> > I know diddly about how libraries are handled, but is it possible to put the<br> > > old Heimdal 1.5.2 libraries somewhere (semi-private) under different names?<br> > ><br> > > I ask because it is going to be very difficult to port the gssd to the<br> > > new libraries.<br> > ><br> > > The problem is that the KGSSAPI code assumes some stuff very specific<br> > > to Heimdal. Take a look at sys/kgssapi/krb5/krb5_mech.c and you'll see<br> > > what I mean. (There's code that parses the keys etc out of the internally<br> > > generated tokens. I have no idea where to even find the information on<br> > > how/where the MIT code hides this stuff and it a large part of krb5_mech.c<br> > > looks like it will have to be re-written to work with the MIT libraries.)<br> ><br> > It might be better to extract the required bits and keep just them.<br> > Perhaps even moving that bits from vendor to FreeBSD-owned code area.<br> The problem is that the code in sys/kgssapi/krb5/krb5_mech.c does contain<br> bits extracted from the Heimdal code. Basically, a detailed knowledge of an<br> internal structure that the keys are extracted from.<br> --> I am now thinking that adding an upcall to the gssd and letting it extract<br> the keys might be a better plan. (At least it moves the maintenance to<br> userland and, hopefully, library calls can replace the detailed knowledge<br> about the internals of the implementation.)<br> <br></blockquote><div><br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ><br> > I do not think that keeping large pieces of code in vendor without updates<br> > is a good plan.<br> Agreed. I'll work on it. (But no guarantees w.r.t. timeline.)<br> <br> Maybe doing a transition to Heimdal 7.8 (or 8.n) would be less painful?<br> (It looks like Heimdal is getting maintenance these days. I think Debian<br> is using it, which suggests it will get at least some TLC?)<br><br></blockquote><div><br></div><div>I think adapting this to the MIT krb5 code is feasible.</div><div>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).</div><div><br></div><div>-Ben </div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ5_RoBjpX_BoKgZTdOof5b83cdxjZyvn4iPM4m5voPHEr2SeQ>