Slashdot Mirror

← Back to Domains

Domain: rucus.net

Stories and comments across the archive that link to rucus.net.

Comments · 7

  1. Re:So much for security... by Morphine007 · · Score: 1 · on Thunderbird 2.0 Alpha 1, Firefox 1.5.0.5 Available

    But that's what people give MS shit for, finding and fixing security holes.

    No, people give MS shit because it can take them in excess of 6 months to release a patch after someone else finds the holes for them.... though if you look at the graph for 2005, it would appear that they are getting better at patching faster.... but your average linux program gets patched within days of a published vulnerability.

  2. Re:Which Big Cat? by mbourgon · · Score: 1 · on Mystery Australian Big Cat Shot

    And how can I thank you for giving me a link that includes the infamous "Puma BJ" poster?

    http://radbrad.rucus.net/gallery/albums/funnies/pu ma.sized.jpg
    (From the first page of the google image search)

  3. Re:What about updates? by Anonymous Coward · · Score: 0 · on Getting Open Source to the Dialup Masses

    I am doing my MSc thesis on patching and have actually just written a paper on this entitled 'Patching for low bandwidth communities'. It is focused on South Africa as that is were I live.

    It discusses a few methods, namely:
    1) Making patches smaller
    2) Reducing the number of patches
    3) Increasing bandwith

    There are a few ideas under each heading a quick summary of some of them can be found here. Binary patching is definately a good idea and is already being used effectivley in FreeBSD and Windows.

    Although, running some variant of stable and just getting security patches doesn't require much bandwidth. My Debian sarge/stable distro requires smallish updates about twice a week.

  4. Re:What about updates? by Anonymous Coward · · Score: 0 · on Getting Open Source to the Dialup Masses

    I am doing my MSc thesis on patching and have actually just written a paper on this entitled 'Patching for low bandwidth communities'. It is focused on South Africa as that is were I live.

    It discusses a few methods, namely:
    1) Making patches smaller
    2) Reducing the number of patches
    3) Increasing bandwith

    There are a few ideas under each heading a quick summary of some of them can be found here. Binary patching is definately a good idea and is already being used effectivley in FreeBSD and Windows.

    Although, running some variant of stable and just getting security patches doesn't require much bandwidth. My Debian sarge/stable distro requires smallish updates about twice a week.

  5. Re:Creative Commons would probably more appropriat by grokster · · Score: 2, Informative · on Open Source Gets Its Own TV Show

    Yes, looks like it is going to be available for download under Creative Commons at some point!

  6. Re:Fixing vulnerabilities is GOOD! by singelet · · Score: 1 · on Is Finding Security Holes a Good Idea?
    This whole thread on automated patching is making one fatal assumtion. Testing must be part of the process and works very well in conjunction with an automated solution. If you have automated the patch deployment proccess then automate the deployment to a test lab (or VMware box), if things don't break then mark the patch as ok and let it be automatically distributed to the rest of the organisation. In the meantime some IDS signatures coupled with the firewall can help prevent exploitation during testing.

    Read more here. Warning I am currently writing a paper on automated patching, this is an academic advert.

  7. Re:Missing a big part of the conclusion by singelet · · Score: 1 · on Is Finding Security Holes a Good Idea?
    Hear, hear. Patching is where the benefits of vulnerability discovery are reaped. I don't think you can view the two in isolation. Vulnerability disclosure without a patch just benefits the Black Hats by providing an attack vector. Given that patching is a nightmare at the moment with hundreds of patches being announced each week and no guarantee that they won't break things, testing has to be performed. This still gives black hats the time benefit.

    Patching is proving both a volume and a process problem, we need to fix this. In a blatant attempt to whore my thesis I have come to two conclusions. First the patching needs to be better: better reporting and automated. Second there needs to be stop-gap measures, IDS signatures distributed with a patch could provide a way for firewalls to block the exploit in the short term while the patch is being tested. I am in the beginning stages of research and will be presenting a paper on this at a conference next month. I also hope to do some development work on an automated solution.