1. 8

How MS handled an urgent security advisory. 2013 write up, though the events went down in 2003.

  1.  

  2. 4

    What I find curious about this is that 14 days is the “no test” option and a smoke test takes 21 days. I’ve been in the unfortunate position of herding more OpenBSD patches than I’d like.

    Barring unusual circumstances, even seven days is pretty long. 90% of the time the bug is something like this:

    memcpy(apple, banana, crazylen);
    

    And the obvious patch is:

    if (crazylen > toocrazy)
        return EOMGNOWAY;
    

    This takes like 30 seconds to manually review and verify. I will fairly regularly back port fixes from current to release branches without any testing at all. (Ok, so maybe that’s bad, but if it compiles on current, it has to work on stable, right?) Sometimes more esoteric bugs take a lot longer to fix, and if it involves a behavior change it can be hard to wrangle it all together, but my understanding is that most of the wormable Windows vulns were two liners like the above.

    The “patch Tuesday” schedule makes a lot of sense for big biz consumers, but I’m still a little confused why, if MS is informed of a bug on Monday morning, they can’t roll a fix the next day. AFAIK this hasn’t changed much since 2000, and it seems to reflect too much rigidity in testing process.