FreeBSD Security Survey

[Anish Mistry]

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 
portname20, portname, portname21, etc.  This takes out quite a bit of 
the updating woes without causing too much overhead for the 
maintainers.  Since maintaining a security branch for releases would 
require too much overhead it might be nice to have mechanism to track 
the "release version" of the installed software.
eg.
For 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 
port for the old version and lang/lua is now version 5.1.  It would 
be nice to have a mapping that I can say "Stay with version 5.0.x" 
and when I do a portupgrade it will see that lua-5.0 is installed so 
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 
that match customer's configurations and perform updates in the jail 
first.  Just to see it there will be any hiccups before actually 
performing the updates on a customer's system.  I only have 3 basic 
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 
step, but once mergemaster -U is cut into a release it should fix 
that annoyance.

-- 
Anish Mistry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060522/8d3ae4e5/attachment.pgp