Kerberos 5 (was Re: cvs commit: src/release ...)

[Jacques A. Vidrine]

On Wed, Apr 30, 2003 at 11:16:03AM -0700, Kris Kennaway wrote:
> Hmm, is it really a good idea to combine crypto and krb5?  krb5 is, I
> suspect, a rarely-used feature in the wild.

On Wed, Apr 30, 2003 at 01:00:09PM -0700, Kris Kennaway wrote:
> The bottom line here is that most people will never use kerberos, so
> installing it by default is an unnecessary security risk, and
> contributes to bloat.  I don't understand why this change needed to be
> made; everything seemed to work fine having k5 in a separate
> distribution (the makefile logic was all correct, etc).

On Wed, Apr 30, 2003 at 11:24:49PM +0300, Ruslan Ermilov wrote:
> Hmm, I'd expect some discussion prior to this change.  What
> was wrong with old good krb5?
> 
> You also probably meant the "crypto" distribution, not "secure".
> Now, how does one guess which telnet is installed?  The old
> crypto telnet, or the new crypto^Wkrb5 telnet?

On Wed, Apr 30, 2003 at 03:28:49PM -0700, Gordon Tetlow wrote:
> Please back this out, it doesn't make sense and violates POLA. As one
> of the users of krb5 in the base system, I'm quite happy with adding
> MAKE_KERBEROS5=yes into my /etc/make.conf.


As one of those who requested this change, I should speak up.

The punch line first:  As Security Officer and as Heimdal maintainer,
I want to eliminate the seperate `distributions'.  I also wish for
MAKE_KERBEROS5 to go away, to be replaced with NO_KRB5.  This general
plan was discussed on re at freebsd.org in early March, and met with
no objection.


Historically, we had these four overlapping distributions: `base',
crypto, krb4, and krb5.  If there was a bug in one of the bits
that was present in all of these distributions, I would have to do
regressions tests on 4 distributions * 2..4 branches.  This Really
Sucks.  It also makes it a little trickier to determine `who is
affected' by a particular bug, and is a hurdle to binary system
updates.

In reference to Ruslan's comments:  Yeah, how _do_ you know which
telnet is installed?  We're trying to reduce the possibilities here.

For some time, the default has been to install all these distributions
(it wasn't always so).  So, one had Kerberos IV and Kerberos 5
libraries and utilities on initial install.  Later, when one updated
the system with `make world', stale libraries and utilities were left
lying around because MAKE_KERBEROS4/MAKE_KERBEROS5 are not on by
default.

The removal of Kerberos IV took one distribution out of the equation.
Merging Kerberos 5 with the other crypto bits brings it down to two,
which is quite a blessing.  (I really wouldn't mind seeing base and
crypto merged either.)

Dropping MAKE_KERBEROS5 and using NO_KRB5 instead is the natural thing
to do if we are going to continue shipping the Kerberos 5 bits as
default in releases.



There are other pieces of the system that are used by less of our
userbase than is Kerberos 5, yet they remain.  There were other pieces
of the system that were used by more of our userbase than is Kerberos
5, yet they were removed.  Whether or not having Kerberos in the base
system is the Right Thing is not really the discussion now [but
obviously feel free to start that discussion].

5.1-RELEASE (and probably the rest of the 5.x series) will have
Kerberos 5 in the base system.  That being the case, please, let us
not have it as a seperate distribution, and let us have it built by
default.  This will make my life so much easier, and I believe it
will reduce release-building times; simplify security advisories, bug
reporting, and debugging; facilitate better Kerberos integration with
our libraries and utilities [1]; bring us in line with Apple, OpenBSD,
and NetBSD; and make your hair shinier.

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME      . FreeBSD UNIX       . Heimdal
nectar at celabo.org . jvidrine at verio.net . nectar at freebsd.org . nectar at kth.se

[1] I have a bunch of local patches enabling Kerberos support for
various libraries and utilities such as OpenSSL and CVS, but I will
not be committing them before 5.1-RELEASE freeze due to lack of time
at the moment to follow-up on any resulting issues.