Skip site navigation (1)Skip section navigation (2)
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>, 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>