Re: FreeBSD Security Survey
--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--
討論串 (同標題文章)
完整討論串 (本文為第 11 之 41 篇)：