Results 1 to 4 of 4

Thread: The Perennial Problem with Patches

  1. February 5th, 2003, 08:18 AM #1
    drag0nsfyre
    drag0nsfyre is offline
    Member
    Join Date
    Jan 2003
    Posts
    73

    The Perennial Problem with Patches

    Hey,



    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
    Google: Dont surf the web without it
    http://www.AntiOnline.com/sig.php?imageid=276
    Reply With Quote Reply With Quote
  2. February 6th, 2003, 04:14 AM #2
    ConsummatumEst
    ConsummatumEst is offline
    Junior Member
    Join Date
    Feb 2003
    Posts
    19
    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?
    Reply With Quote Reply With Quote
  3. February 6th, 2003, 04:32 AM #3
    phishphreek
    phishphreek is offline
    AO übergeek phishphreek's Avatar
    Join Date
    Jan 2002
    Posts
    4,325
    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?
    Quitmzilla is a firefox extension that gives you stats on how long you have quit smoking, how much money you\'ve saved, how much you haven\'t smoked and recent milestones. Very helpful for people who quit smoking and used to smoke at their computers... Helps out with the urges.
    Reply With Quote Reply With Quote
  4. February 7th, 2003, 12:55 AM #4
    ConsummatumEst
    ConsummatumEst is offline
    Junior Member
    Join Date
    Feb 2003
    Posts
    19
    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?
    Reply With Quote Reply With Quote
« Previous Thread | Next Thread »

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Forum Rules