[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3AD1F04EDB516C4097168A9C08CFFEE60A8BFF6C@shawmail03.shaw.ca>
From: tremaine.lea at sjrb.ca (Tremaine Lea)
Subject: The new Microsoft math: 1 patch for 14 vul
nerabilities, MS04-011
> -----Original Message-----
> From: Tim [mailto:tim-security@...tinelchicken.org]
> Sent: Wednesday, April 14, 2004 9:38 AM
> To: Edward W. Ray
> Cc: full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] The new Microsoft math: 1
> patch for 14 vulnerabilities, MS04-011
<snip>
> Yeah, this is pretty disgusting.
> Seemingly harmless in application, but when you consider
> features often creep into patches in M$ software, it makes it
> extremely difficult to test a single mega-patch like this on
> a few thousand systems with different configurations and
> custom software installations. I can tell you first hand,
> that dealing with them in bunches severely slows the patch
> release process in enterprise environments.
>
> And I don't buy "its easier if it is all together". If your
> patch management system doesn't suck, any number of seperate
> patches can be applied just as easily as a subset of them.
>
> tim
This merely begs the question, why do they not then release the patches as
both? A single "patch'em all" one for single users and those who can afford
to implement patches this way, and a broken out set of the patch that can be
more thoroughly tested in larger scale environments where the big patch
solution doesn't work.
Tremaine
Powered by blists - more mailing lists