The Perennial Problem with Patches

Printable View

February 5th, 2003, 08:18 AM
drag0nsfyre

The Perennial Problem with Patches

Hey,

Quote:

False Security

Patches cannot be relied upon to deliver effective front-line security, because they simply aren't applied in a consistent, effective and timely fashion. Indeed, many industry best practices preclude applying patches in an ad hoc manner: changes to production environments need to be tested and proved safe before deployment. This frequently leaves a large window of opportunity when a vulnerability can be maliciously exploited.

Moreover, it's all too easy for more important deadlines, issues or simply the crisis du jour to interfere, potentially pushing the fix forever to the bottom of the list and leaving your systems perpetually vulnerable.

Full story here

Just thought it would be of intrest and if anyone might have some thoughts
February 6th, 2003, 04:14 AM
ConsummatumEst

Why is it that liinux patches are so much less of a problem? I mean, surely they face the same issues too, but they just handle them better. Whenever I see a new patch released by RedHat, I don't have to stop and worry, "Will this cause my system to become unstable?" Why does Microsoft seem to have such a problem with this?
February 6th, 2003, 04:32 AM
phishphreek

Quote:

Whenever I see a new patch released by RedHat, I don't have to stop and worry, "Will this cause my system to become unstable?" Why does Microsoft seem to have such a problem with this?

Maybe because on linux, they are compiled on a per machine basis. With M$, its one program/patch for all machines? In my experience (which isn't too much...) If you compile a program directly on the machine, it will run better because it was compiled on the same hardware it is going to be run on. Rather than downloading a .exe or something which was compiled on a completely different machine.

This is kind of a guess and question. Can anybody confirm this or offer another explanation?
February 7th, 2003, 12:55 AM
ConsummatumEst

It's my understanding that RPM's contain precompiled binaries. That's why they have the i386, i586, i686, and athlon RPM's for the kernel. Most of the other rpm's, however, just say that they are for i386 and above which leads me to believe that all of the binaries are precompiles and are just installed to their correct locations. I suppose I could be wrong, but why would they need source RPM's if the programs are recompiled on a per machine basis?