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
--000000000000812483063b047b97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 28, 2025 at 7:04=E2=80=AFAM Rick Macklem <rick.macklem@gmail.co= m> wrote: > On Mon, Jul 28, 2025 at 1:20=E2=80=AFAM Konstantin Belousov <kostikbel@gm= ail.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 an= d > 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@csch= ubert.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 emai= ls > 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 th= e > > > 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 se= e > > > 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 o= n > > > 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 --000000000000812483063b047b97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 28, 2025 at 7:04=E2=80=AFAM R= ick Macklem <<a href=3D"mailto:rick.macklem@gmail.com">rick.macklem@gmai= l.com</a>> wrote:</div><div class=3D"gmail_quote gmail_quote_container">= <blockquote class=3D"gmail_quote" style=3D"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=E2=80=AFAM Konstantin Belousov <<a href=3D"mailto:kostikbel@gmail.co= m" target=3D"_blank">kostikbel@gmail.com</a>> wrote:<br> ><br> > CAUTION: This email originated from outside of the University of Guelp= h. Do not click links or open attachments unless you recognize the sender a= nd know the content is safe. If in doubt, forward suspicious emails to <a h= ref=3D"mailto:IThelp@uoguelph.ca" target=3D"_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=E2=80=AFAM Cy Schubert <<a href= =3D"mailto:Cy.Schubert@cschubert.com" target=3D"_blank">Cy.Schubert@cschube= rt.com</a>> wrote:<br> > > ><br> > > > CAUTION: This email originated from outside of the Universit= y of Guelph. Do not click links or open attachments unless you recognize th= e sender and know the content is safe. If in doubt, forward suspicious emai= ls to <a href=3D"mailto:IThelp@uoguelph.ca" target=3D"_blank">IThelp@uoguel= ph.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 differ= ent names?<br> > ><br> > > I ask because it is going to be very difficult to port the gssd t= o the<br> > > new libraries.<br> > ><br> > > The problem is that the KGSSAPI code assumes some stuff very spec= ific<br> > > to Heimdal. Take a look at sys/kgssapi/krb5/krb5_mech.c and you&#= 39;ll see<br> > > what I mean. (There's code that parses the keys etc out of th= e internally<br> > > generated tokens. I have no idea where to even find the informati= on on<br> > > how/where the MIT code hides this stuff and it a large part of kr= b5_mech.c<br> > > looks like it will have to be re-written to work with the MIT lib= raries.)<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<b= r> 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 e= xtract<br> =C2=A0 =C2=A0 =C2=A0 the keys might be a better plan. (At least it moves th= e maintenance to<br> =C2=A0 =C2=A0 =C2=A0 userland and, hopefully, library calls can replace the= detailed knowledge<br> =C2=A0 =C2=A0 =C2=A0 about the internals of the implementation.)<br> <br></blockquote><div><br></div><div><br></div><div>Note that MIT krb5 prov= ides the=C2=A0gss_krb5_export_lucid_sec_context() API that does a lot of th= e work of getting useful bits out of an established GSS security context.</= div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"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 upd= ates<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></blockq= uote><div><br></div><div>I think adapting this to the MIT krb5 code is feas= ible.</div><div>I think that kg_ctx_externalize() is where the actual expor= ted security context token is produced (no structure, just bashing bytes ou= t into the buffer).</div><div><br></div><div>-Ben=C2=A0</div></div></div> --000000000000812483063b047b97--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ5_RoBjpX_BoKgZTdOof5b83cdxjZyvn4iPM4m5voPHEr2SeQ>