From owner-freebsd-security Mon Mar 18 15:49:51 2002 Delivered-To: freebsd-security@freebsd.org Received: from clink.schulte.org (clink.schulte.org [209.134.156.193]) by hub.freebsd.org (Postfix) with ESMTP id EC87B37B416 for ; Mon, 18 Mar 2002 15:49:45 -0800 (PST) Received: from schulte-laptop.nospam.schulte.org (nb-65.netbriefings.com [209.134.134.65]) by clink.schulte.org (Postfix) with ESMTP id D97F724491; Mon, 18 Mar 2002 17:49:43 -0600 (CST) Message-Id: <5.1.0.14.0.20020318173139.0537c438@pop3s.schulte.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Mar 2002 17:48:23 -0600 To: Steve Shorter , Brett Glass From: Christopher Schulte Subject: Re: FreeBSD Ports Security Advisory FreeBSD-SA-02:18.zlib Cc: security@FreeBSD.ORG In-Reply-To: <20020318181917.B66347@nomad.lets.net> References: <4.3.2.7.2.20020318140507.00e58dc0@nospam.lariat.org> <4.3.2.7.2.20020318140507.00e58dc0@nospam.lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 06:19 PM 3/18/2002 -0500, Steve Shorter wrote: > What is lacking inf FreeBSD is a 4.5-RELEASE with >security fixes AND bug fixes. > > -STABLE includes "new material" which can be unstable. >And -SECURITY only has "security fixes" but not bug fixes >in general, since the last RELEASE. RELENG_4_X was (still is) open to critical bug fixes, but generally it's used for critical *security* related bug fixes. The problem is (at least) two folded as I see it: 1) Because bug fixes are generally addressed in -STABLE with the forward looking goal of releasing a new -RELEASE snapshot some time in the future, to backport the same bug fix to a -RELEASE codebase (essentially what RELENG_4_X is) can be a lot of work depending on how much the RELENG_4_X branch differs from the current -STABLE. Kernel dependencies, lib changes, and the like can hinder the process and even introduce unforeseen bugs back into the system. 2) How to draw a line in the sand and decide what will be committed to RELENG_4_X as a fix, and what will require a tracking of -STABLE or the next -RELEASE. The last thing I want is a second -STABLE branch with lots of code updates, thus decreasing the overall stability. With this in mind, only security fixes and the ***most critical*** bugs should be addressed with RELENG_4_X. Minimize code change, maximize stability. > -steve -- Christopher Schulte http://www.schulte.org/ Do not un-munge my @nospam.schulte.org email address. This address is valid. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message