Date: 18 Apr 2002 12:24:31 -0700 From: Ken McGlothlen <mcglk@artlogix.com> To: Brett Glass <brett@lariat.org> Cc: nate@yogotech.com (Nate Williams), Christopher Schulte <schulte+freebsd@nospam.schulte.org>, security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip Message-ID: <87it6oajyo.fsf@ralf.artlogix.com> In-Reply-To: <4.3.2.7.2.20020418114304.00dccf00@nospam.lariat.org> References: <4.3.2.7.2.20020418095356.024354c0@nospam.lariat.org> <4.3.2.7.2.20020417230144.032ad390@nospam.lariat.org> <200204171923.g3HJNga58899@freefall.freebsd.org> <4.3.2.7.2.20020418095356.024354c0@nospam.lariat.org> <4.3.2.7.2.20020418114304.00dccf00@nospam.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass <brett@lariat.org> writes:
| Many people are suggesting that one CVSup every night.
Which isn't an onerous thing to do, provided you're only doing it on one
reference machine. I suspect most people only do the cvsup on demand, or
weekly, or monthly, or whatever else.
| How does one know that there isn't a system-crashing bug in some other part
| of the tree for the same date?
Well, that's certainly a possibility. However, patches made to -STABLE are
tested pretty well prior to inclusion (which is why it's called -STABLE). In
-CURRENT, you're kind of on your own, but a production shop shouldn't be
running -CURRENT.
Even well-funded organizations such as Microsoft can't possibly test all
combinations of hardware; Microsoft has occasionally released system updates
that have caused widespread problems. The same can conceivably happen with
FreeBSD, or any other operating system, for that matter. The absolute best way
to head off potential problems is this:
* Have all your machines running absolutely identical hardware.
* Designate one machine to be the FreeBSD -STABLE source reference.
* CVSup that one daily, nightly, weekly, whatever you like.
* Designate another machine to be the test box.
* Before installing a new version of FreeBSD or any kernels on a
production machine, test it on your test box until you're reasonably
sure that it will work on the production machine.
Now, this gets kind of expensive, because you have to make hardware upgrades
across the entire range of machines at once (say, if a part croaks and it turns
out they don't make that model anymore). But it's the only sure-fire way.
A more reasonable approach is to be aware that changes to the -STABLE branch
are properly and reasonably pretested, widely installed, and any potential
problems will be squished as soon as humanly possible. Pay attention to and
evaluate all the security advisories on an individual basis, and try to run the
same build across all the machines.
I should point out that I've been running FreeBSD since . . . uh . . . 1994 or
1995, and I've *never* had -STABLE produce a non-running system. Ever. I've
developed a lot of faith in the -STABLE tree, and in the people in charge of
it. You might want to relax a little. :)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87it6oajyo.fsf>