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

Ruslan Ermilov ru at FreeBSD.org
Thu May 1 02:13:28 PDT 2003


On Wed, Apr 30, 2003 at 07:22:06PM -0500, Jacques A. Vidrine wrote:
> 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.
> 
I think this was a mistake to discuss this in so limited environment.

> 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.
> 
This only affects telnet, AFAIK, and it's now built from the same
source.

> In reference to Ruslan's comments:  Yeah, how _do_ you know which
> telnet is installed?  We're trying to reduce the possibilities here.
> 
Heh, but we now build both "secure/" and "kerberos5/" telnets, in
the same distribution (crypto), and I really don't get it which
one is installed, I need to try first.  ;)

> 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.
> 
I don't even remember this being a case, that must have happened
long ago.

> 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.)
> 
I wouldn't either (for base and crypto), not so sure about krb5 and
crypto.

> 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.
> 
Heh, is that your plan?  It wasn't announced.  The thing that irritates
me most is that "make release" will (by default) install kerberos5
bits now, and "make world" will not.  Please make it NOKERBEROS5,
like the rest of NO knobs controlling top-level SUBDIR list in
Makefile.inc1.  Please also fix the DISTRIBUTION to "crypto"
in kerberos5/Makefile.inc.  This will address at least my concerns
(I personally use MAKE_KERBEROS5 on half of my machines).

> 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].
> 
Yes, this is a separate issue, and I personally would like to have
it in.

> 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.
> 
Okie, okie, just make it so both "make release" and "make world"
agree on this.

Folding krb5 into crypto also means the following thing: we
shouldn't build secure/ telnet during "make release", which
is not very good IMO.  I hope you see why it shouldn't be
built.  Currently^WPreviously, with three base, crypto, and
krb5 distributions, all base, secure/ and kerberos5/ versions
were compiled during "make release", and sysinstall took
care of ordering the kerberos5 after crypto of both were
selected.


Cheers,
-- 
Ruslan Ermilov		Sysadmin and DBA,
ru at sunbay.com		Sunbay Software AG,
ru at FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20030501/a35cb557/attachment.bin


More information about the cvs-src mailing list