Date: Mon, 22 May 2006 02:49:34 -0400 From: Anish Mistry <mistry.7@osu.edu> To: freebsd-stable@freebsd.org Cc: freebsd security <freebsd-security@freebsd.org>, Scott Long <scottl@samsco.org>, Colin Percival <cperciva@freebsd.org>, Brent Casavant <b.j.casavant@ieee.org> Subject: Re: FreeBSD Security Survey Message-ID: <200605220249.50328.mistry.7@osu.edu> In-Reply-To: <44714FBB.4000603@samsco.org> References: <4471361B.5060208@freebsd.org> <20060521231657.O6063@abigail.angeltread.org> <44714FBB.4000603@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605220249.50328.mistry.7>