[Full-disclosure] Fwd: Re "getting off the patch"

[Glenn Everhart <Everhart@xxxxxxx>]

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/