From owner-freebsd-security Wed Apr 11 10:52:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailhub.airlinksys.com (mailhub.airlinksys.com [216.70.12.6]) by hub.freebsd.org (Postfix) with ESMTP id CF63937B422 for ; Wed, 11 Apr 2001 10:52:17 -0700 (PDT) (envelope-from sjohn@airlinksys.com) Received: from ns2.airlinksys.com (ns2.airlinksys.com [216.70.12.3]) by mailhub.airlinksys.com (Postfix) with ESMTP id 2973053501 for ; Wed, 11 Apr 2001 12:52:08 -0500 (CDT) Received: by ns2.airlinksys.com (Postfix, from userid 1000) id CF53E5DD8; Wed, 11 Apr 2001 12:52:07 -0500 (CDT) Date: Wed, 11 Apr 2001 12:52:07 -0500 From: Scott Johnson To: freebsd-security@freebsd.org Subject: Re: Security Announcements Message-ID: <20010411125207.A95503@ns2.airlinksys.com> Reply-To: Scott Johnson Mail-Followup-To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There is a difference between security fixes and a 'more low-key and conservative set of changes intended for our next mainstream release'. I maintain a single source tree for all of my machines. That source tree is 4.2-RELEASE + security patches. Things break in -STABLE despite the care taken in merging from -CURRENT; if I don't need features found only in -STABLE, my preference is to trust more the long testing period of a -RELEASE. While I could test stable on a spare box, that would be time-consuming and error-prone, since that box would have to emulate the designated tasks of all my machines. On the other hand, maintaining a -STABLE source tree in addition to -RELEASE and selectively installing certain things like bind and ntp when the need arises may have problems because the -STABLE software is out of sync with the rest of the system. This also creates problems when building world with the -RELEASE tree, since some software should come from -STABLE. And when it comes down to it, I'd rather build just a kernel, or just a userspace program, and only when I have to, then rebuild everything on a semi-regular basis. I just want to add my voice as to how I use FreeBSD. Simply saying 'use -STABLE' to those of us running -RELEASE on production systems isn't appropriate, since I believe we have valid reasons for running -RELEASE on our systems. These security issues are not so frequent that providing patches for -RELEASE should be too burdensome. In fact, if -STABLE was fixed, the fix is already available and could be applied to -RELEASE with little or no modification. I've been pleased, actually, with how patches have been made available for -RELEASE until only recently, when both the bind and ntp vulnerabilities went by without patches. I thought, up till this discussion, that it was assumed that many run a -RELEASE, and that patches were supplied for that reason. I for one (and judging by the posts to this thread I'm not alone) use FreeBSD this way, and I ask that it be considered important to make security patches available for the latest -RELEASE. Quoth Roberto Nunnari on Wed, Apr 11, 2001 at 02:00:26PM +0200: > stable is not pre-beta. > http://www.freebsd.org/handbook/current-stable.html > > ...cut and paste from the above: > > 19.2.2. Staying Stable with FreeBSD > > If you are using FreeBSD in a production environment and want to make > sure you have the latest fixes from the -CURRENT branch, you want to be > running -STABLE. This is the tree that -RELEASEs are branched from when > we are putting together a new release. For example, if you have a copy > of 3.4-RELEASE, that is really just a ``snapshot'' from the -STABLE > branch that we put on CDROM. In order to get any changes merged into > -STABLE after the -RELEASE, you need to ``track'' the -STABLE branch. > 19.2.2.1. What is FreeBSD-STABLE? > > FreeBSD-STABLE is our development branch for a more low-key and > conservative set of changes intended for our next mainstream release. > Changes of an experimental or untested nature do not go into this branch > (see FreeBSD-CURRENT). -- Scott Johnson System/Network Administrator Airlink Systems To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message