From owner-cvs-all@FreeBSD.ORG Wed Apr 30 17:22:12 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CC3E37B401; Wed, 30 Apr 2003 17:22:12 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id C07A143F85; Wed, 30 Apr 2003 17:22:08 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 076DE68; Wed, 30 Apr 2003 19:22:08 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 34C6F78C4A; Wed, 30 Apr 2003 19:22:07 -0500 (CDT) Date: Wed, 30 Apr 2003 19:22:06 -0500 From: "Jacques A. Vidrine" To: Kris Kennaway , Ruslan Ermilov , Gordon Tetlow Message-ID: <20030501002206.GA30097@madman.celabo.org> References: <200304301754.h3UHsJ21004574@repoman.freebsd.org> <20030430222849.GC14221@roark.gnf.org> <200304301754.h3UHsJ21004574@repoman.freebsd.org> <20030430202449.GA23953@sunbay.com> <20030430194402.GB84924@rot13.obsecurity.org> <200304301952.h3UJqiQL016860@grimreaper.grondar.org> <20030430200008.GA85160@rot13.obsecurity.org> <200304301754.h3UHsJ21004574@repoman.freebsd.org> <20030430181603.GD84302@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430222849.GC14221@roark.gnf.org> <20030430202449.GA23953@sunbay.com> <20030430200008.GA85160@rot13.obsecurity.org> <20030430181603.GD84302@rot13.obsecurity.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Mark Murray cc: Mark Murray cc: cvs-all@FreeBSD.org Subject: Kerberos 5 (was Re: cvs commit: src/release ...) X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 00:22:13 -0000 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@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@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@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.