Fwd: Re "getting off the patch"

[Glenn Everhart <Everhart () gce com>]

If you have a system that is built well secured in the first place (existence proof: VMS)
then patches are comparatively rare.

However nobody goes to the trouble of designing a patch unless there is a known flaw or
flaws in software. The way I've seen it done is that pieces of the code get rewritten, and
then tested, and then retrofitted to the in-the-field software versions. (Doing it that way
ensures that the next versions don't have the problem.) Once there is a known problem, there
are enough ways to tickle it that it is senseless to leave the known flaws in place.

It is true that sometimes patches don't deal with the underlying causes of trouble, and in those
cases arguably some other method to put a band-aid on the cancer is as good as the patch. He
who does that, however, had better know as well as the software maintainers (if not better)
what the causes are. Unless that's true, again, it is safer to do the patch and maybe try your
Very Own Idea of how to fix more tickling cases.

The more paths of software interaction exist in your system, the more likely it is that some
ways may be found around your generic solutions to problems, so anything where you have a known
bug fixed is far safer dealt with.

This does not mean generic fixes are worthless: it just recalls the old parable of building on
sand that patches have become so common. Anyone who's been to many East Coast beaches will
realize what numerous and redundant measures get taken there too.
Glenn Everhart

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/