From owner-freebsd-stable@FreeBSD.ORG Mon May 22 06:49:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D28116A542; Mon, 22 May 2006 06:49:45 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A83B43D81; Mon, 22 May 2006 06:49:19 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.6) with ESMTP id k4M6oSvm079391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 May 2006 02:50:34 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-stable@freebsd.org Date: Mon, 22 May 2006 02:49:34 -0400 User-Agent: KMail/1.9.1 References: <4471361B.5060208@freebsd.org> <20060521231657.O6063@abigail.angeltread.org> <44714FBB.4000603@samsco.org> In-Reply-To: <44714FBB.4000603@samsco.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2431212.cZZkS9eTYF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605220249.50328.mistry.7@osu.edu> X-Spam-Status: No, score=-7.9 required=5.0 tests=ALL_TRUSTED,BAYES_50, J_CHICKENPOX_53,MYFREEBSD2,MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88.2/1474/Sun May 21 09:18:22 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd security , Colin Percival , Brent Casavant Subject: Re: FreeBSD Security Survey X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2006 06:49:46 -0000 --nextPart2431212.cZZkS9eTYF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 22 May 2006 01:44, Scott Long wrote: > Brent Casavant wrote: > > On Sun, 21 May 2006, Colin Percival wrote: > >>In order to better understand > >>which FreeBSD versions are in use, how people are (or aren't) > >> keeping them updated, and why it seems so many systems are not > >> being updated, I have put together a short survey of 12 > >> questions. > > > > I applaud this survey, however question 9 missed an important > > point, at least to me. I was torn between answering "less than > > once a month" and "I never update". > > > > While I find ports to be the single most useful feature of the > > FreeBSD experience, and can't thank contributors enough for the > > efforts, I on the other hand find updating my installed ports > > collection (for security reasons or otherwise) to be quite > > painful. I typically use portupgrade to perform this task. On > > several occasions I got "bit" by doing a portupgrade which wasn't > > able to completely upgrade all dependencies (particularly when X, > > GUI's, and desktops are in the mix -- though I always follow the > > special Gnome upgrade methods when appropriate). > > > > I can't rule out some form of pilot error, but the end result was > > pain. > > > > After several instances of unsatisfactory portupgrades (mostly in > > the 5.2 through early 5.4 timeframe), I adopted the practice of > > either not upgrading ports at all for the life of a particular > > installation on a machine (typically about one year), or when > > necessary by removing *all* ports from the machine, cvsup'ing, > > and reinstalling. This has served me quite well, particularly > > considering the minimal threat profile these particularly systems > > face. > > > > So, in short, that's why *I* rarely update ports for security > > reasons. > > > > There are steps that could be taken at the port maintenance level > > that would work well for my particular case, however that's > > beyond the scope of the survey. Thanks for taking the time put > > the survey together, I certainly hope it proves useful. > > > > Thank you, > > Brent Casavant > > I share this frustration with you. I was once told that the pain > in upgrading is due largely to a somewhat invisible difference > between installing a pre-compiled package, and building+installing > a port. In theory, if you stick to one method or the other, things > will stay mostly consistent. But if you mix them, and particularly > if you update the ports tree in the process, the end result is a > bit more undefined. One thing that I wish for is that the ports > tree would branch for releases, and that those branches would get > security updates. I know that this would involve an exponentially > larger amount of effort from the ports team, and I don't fault them > for not doing it. Still, it would be nice to have. More ports seem to be separating out their different version into=20 portname20, portname, portname21, etc. This takes out quite a bit of=20 the updating woes without causing too much overhead for the=20 maintainers. Since maintaining a security branch for releases would=20 require too much overhead it might be nice to have mechanism to track=20 the "release version" of the installed software. eg. =46or 6.0 release I installed lang/lua which is lua-5.0 Then when I cvsup next time the maintainer has created a lang/lua50=20 port for the old version and lang/lua is now version 5.1. It would=20 be nice to have a mapping that I can say "Stay with version 5.0.x"=20 and when I do a portupgrade it will see that lua-5.0 is installed so=20 use lang/lua50 instead of lang/lua. As a port maintainer, I could probably live with that extra mapping. Though currently I try to keep a few jails configured on my desktop=20 that match customer's configurations and perform updates in the jail=20 first. Just to see it there will be any hiccups before actually=20 performing the updates on a customer's system. I only have 3 basic=20 configurations that I use so it's not that big of a deal for me. My biggest grip about updating the base system is the mergemaster=20 step, but once mergemaster -U is cut into a release it should fix=20 that annoyance. =2D-=20 Anish Mistry --nextPart2431212.cZZkS9eTYF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEcV8OxqA5ziudZT0RApAxAJ0W62osv7XrsQiI8zsUBH/zJavyoACfbeeS oy5w1KdkFigb4p/HAP6Zwvc= =iEHD -----END PGP SIGNATURE----- --nextPart2431212.cZZkS9eTYF--