Security Patch Creation at Microsoft 274
devonshire writes "Officials at the Microsoft Security Response Center have provided a detailed look at the process used to create security patches. From the time the first vulnerability data is received from grey hats to the time a bulletin is shipped, it's a pretty interesting look at how they handle the information flow and patch testing and why it takes so darn long to release an IE update."
Typical corporated programming (Score:5, Interesting)
UDP Floods (Score:4, Interesting)
Send a UDP flood to ANY of the services which are actively listening by default, problem solved. Where's the triage team on that one? I guess 99.9% resource consumption isn't a vulnerability in their eyes.
From the article: (Score:3, Interesting)
Re:Testing is only a priority on closed source app (Score:3, Interesting)
Remember what ESR wrote about this? "If you treat your users as if they were your most valuable resource, they will respond by becoming your most valuable resource."
In other words, I think this is all about community-building, and I grant you that this may be beyond what you can do as a single developer who simply shares some code with the world. Still, I have found ESR's statement to be quite true in my own projects, and it only takes a small effort to express this attitude in the e-mails you send to your bug reporters.
Re:Testing is only a priority on closed source app (Score:1, Interesting)
Oh give the man a break... (Score:3, Interesting)
The Internet wouldn't be broken as such, but I doubt the users would see it that way. To them, it doesn't matter if it is the browser, the connection or the servers (massive worm?) that is broken. They can't do what they want, hence it is broken. It is as simple as that.
Kjella
Re:Typical corporated programming (Score:5, Interesting)
Striking a balance is the trick, and non-technical managers will tend towards the extremely cautious end of the scale without their caution being necessarily grounded in a realistic appraisal of the problem. They don't realy understand it, so they go slowly and have accountability at every step.
Sounds like you might want a shorter chain of command, with technically knowledgable managers making the calls.
How you get that to happen, well, I really don't know. A new CEO might be a start (it's worked at my old company)
Re:Testing is only a priority on closed source app (Score:5, Interesting)
Rather, I want this project to be open and usable for all. To that end, I license it under the GPL and anyone is free to use it.
So my users are partners with me. They are not my guinea pigs. Though I maintain control over the project, there is no set-in-stone law that no one else may fork the project. In fact, they are encouraged to, if they feel it necessary.
I release the patches, and they accept them or reject them, depending on their own circumstances. I don't rule them with an iron fist. I consider them my Knights of the Round Table where they all have the right to say what they want and none is any greater than the other.
So maybe you think that users are passive slugs, but I'd rather give them the benefit of the doubt.
Re:Testing is only a priority on closed source app (Score:5, Interesting)
Besides which, a hell of a lot of corporates consider their intranet (extranet/web) apps 'critical'. IE (or other browser) is a major component in that mission-critical situation, wouldn't you say?
Re:Typical corporated programming (Score:5, Interesting)
Next is bug fixing. This is by far the most variable and unpredictible part, requiring the best of any programmer. It may take minutes or it may take weeks. Besides good programmers, good process can be of great help here.
Finally comes the release testing, which is what the article is talking about. This phase is essential: *never* trust a programmer if he says its "fixed and I tested it". Generally, programmers are simply incapable of testing their own stuff. I know as a programmer. Release-testing takes a considerable, but predictable amount of time, assuming the programmer did a good job. Skipping this phase will sooner or later lead to disasters like the recent Netscape 8 release.
Now I agree with your complaint on workload and lack of tech-savvy managers, but it's nonsense to say that the process as a whole sucks.
Re:From the article: (Score:3, Interesting)
You'd be surprised. Very surprised.
Things are far more screwed up than you'd think. An article on development of a new OS release would come in handy, but putting things shortly, somewhere between 60 and 80% down the way with the development of the new OS, the code is branched into "local versions" which are independently developed by corresponding local Microsoft divisions. Bugfixes, features etc are usually shared, but only "usually", and the final code base varies wildly. There's no simple way to "translate" a version of Windows, or port features from one to the other. That's why each language has separate service pack and the service packs for them show up at wildly varying intervals - each team has to roll their own. That's why e.g. people in Poland used german version of WinNT instead of polish one on mission-critical positions - because it's more stable. There's way more to "local versions" than plain "local language files". The design is consistent thorough the system, but the code behind it may be completely different, even if it's not really localization-related.
Re:Testing is only a priority on closed source app (Score:3, Interesting)
You can always release a patch to the patch if any problems are found with it
But seriously, it makes most sense to correct most bugs (that will be caught in the short-term) before a wide release, where there is a single copy of the source, rather than after release, where there are as many copies as there are users.
With open-source anybody is free to provide this service. If the author only has the time/motivation to do barely-tested releases, why reject his code? Someone else with the desire can do testing and make releases to a wider audience that are more stable, and users can choose between the two options (or more). These can even form without any direct arrangement between the various parties.
Grey hats?!? WTF (Score:2, Interesting)
Re:The Market Cycle (Score:4, Interesting)
I dit not spend my 4 Unviersity years learning how to rightly develop computer systems just to go out and be a seller... or a service provider.
I would had studied Economy or public relations.
Re:Hahaha. (Score:3, Interesting)
your logic is bullshit. (Score:2, Interesting)
Re:The Market Cycle (Score:2, Interesting)
2) Your "once upon a time" nonsense reads just like any other fairytale in that it is make-believe. The software industry was born when demand was created by the advent of PCs. It had nothing to do with a mythical band of hand-holding programmers. Keep selling your install services and numbing your mind. I'll keep selling software products.