How to update or should we update Kerberos
Cy.Schubert at cschubert.com
Tue May 29 02:34:41 UTC 2018
In message <20180529003057.GB65175 at kduck.kaduk.org>, Benjamin Kaduk
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> On Mon, May 28, 2018 at 12:49:41PM -0600, Sean Bruno wrote:
> > https://github.com/heimdal/heimdal/releases
> > Since we haven't updated Kerberos for 6 years, I'm curious why we even
> cy has some WIP in projects/krb5, which at least initially was to
> switch to MIT krb5 in base (but now may be more ambitious and leave
> both Heimdal and MIT options).
Yes. The first phase, to make kerberos in base private, has been
committed to my project branch. It broke over 800 ports. I'm working on
cobbling a ports patch.
A private kerberos in base cleans up a lot of nasty issues in ports.
The next bit is messy. Originally my plan was to replace Heimdal with
MIT however one of our cluster admins objected. Though both Heimdal and
MIT use the same protocol, the kadmin protocol is incompatible. This is
a bit of a POLA violation.
IMO FreeBSD should ship with Kerberos client commands and private
libraries and allow the user to select one of the ports for their KDC.
A packaged base would make this a little more politically feasible.
With this in mind, the only viable option that would be acceptable to
everyone is a knob to allow building of one or another in base. In
other words Heimdal in base should probably also be updated.
> > have it floating around in base.
> > I'm ignorant as to what we need it for.
> It's a great way to simplify the bootstrap process when setting up
> new machines (in an existing realm environment), in particular, it
> is used in the FreeBSD cluster. Prior to pkgng's introduction of
> signed packages, it was the only way for me to securely integrate a
> new install that did not involve hand-transcribing key material or
> putting it on removable media. I think the signed-packages
> situation helps somewhat, but there are definitely still cases where
> it's useful to have.
When I was at $JOB-1, our script created a keytab and pushed keys
through an ssh session from each admin's Linux, FreeBSD, or Solaris
IMO, in today's environment, I'd be inclined to create a site-wide
meta-port with all required FreeBSD ports for the site as prereqs and a
port that configured kerberos. I know one person who does this using
site-wide Linux RPMs at a Linux shop. When the site-wide config changes
he updates his meta-ports and does yum update. This might be something
we might want to document in a howto doc for pkgng.
> On the other hand, it's also sometimes frustrating when it's
> 6-year-old code and I also want to be in an MIT krb5 environment.
> But I hope that cy will continue with the project branch and we'll
> get an update "soon".
I'm working through all 800 broken ports.
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
More information about the freebsd-arch