Building your own vs. deploying OS packaged version of MIT Kerberos?

[Robbie Harwood]

Tareq Alrashid <tareq at qerat.com> writes:

> The new world order seem to demand some adjustments to how we do
> things nowadays with on premise and cloud service deployment.  We know
> how many OS’es come with prebuilt versions Kerberos RHEL/OS X…etc.,
> and I am starting to ponder if efficiency could be optimized if we no
> longer built our own Kerberos binaries from downloaded MIT source, but
> rather just configure OS’s e.g. RHEL 7 version of krb5-1.13?  RedHat
> does release security patches with OS patches and that can save us
> some manual labor.

With my RHEL maintainer hat on, I would recommend starting from the krb5
packaging for the distro you're using.  For our krb5 specifically, we
patch in compatibility with distro-specific features that aren't
generally useful (selinux and debuginfo support come immediately to
mind for us, or HURD support for Debian).  For faster distros, the
version of krb5 present is usually "latest release + a couple patches";
for slower distros, it'll be "older release + a few more patches", if
that makes sense.

Now, whether that's building those packages from source or just
installing the binaries is up to you.  Building from source allows you
to be ready to patch if needed, as well as verifying build integrity
(most distros consider non-reproducible builds a bug these days).  On
the other hand, just installing the binary packages is less time
consuming and gets you basically the same thing.

What it comes down to really is who you want support from.  If you want
just upstream support, then build from MIT source; if you want distro
provider support (and the potential for upstream support sometimes,
you'd of course want to use the distro packages.

Hope that helps,
--Robbie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20160513/93cdda74/attachment.bin