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."
Testing is only a priority on closed source apps (Score:1, Insightful)
With Open Source, a patch can be released right away and users can compile in the new sources themselves. Any issues can be immediately identified and reported back to the maintainers, often with both the offending source code and potential fixes to the patch. Without the lengthy QA cycle, Open Source patches are much more immediate than any Closed Source shop could ever hope to achieve.
Re:Testing is only a priority on closed source app (Score:5, Insightful)
who's going to want to install it? when everyone is a guinea pig, a certain reluctance to jump in first may manifest itself.
Nice to know that... (Score:2, Insightful)
Re:From the article: (Score:3, Insightful)
Re:Testing is only a priority on closed source app (Score:2, Insightful)
Re:IE is the internet? (Score:3, Insightful)
Re:Testing is only a priority on closed source app (Score:3, Insightful)
Re:Testing is only a priority on closed source app (Score:2, Insightful)
If no one wanted to write it, OSS wouldn't even exist.
Re:From the article: (Score:2, Insightful)
Re:Testing is only a priority on closed source app (Score:3, Insightful)
The GP was only half-right by saying that 'a patch can be released right away and users can compile in the new sources themselves' is a strength of OSS. In reality only small numbers of users do this themselves, most simply get it through their distro's auto update feature after its been tested and qa'd by the distro maintainers.
Re:Testing is only a priority on closed source app (Score:5, Insightful)
So what's different about that compared to the pre-release testers employed by Microsoft? not a lot, it may seem. Besides, my reading of the OP's post didn't indicate this was the meaning at all.
The fact is, going back to the OP's harebrained scheme, that no-one is going to apply a patch to a critical environment unless it's been through major testing. Sure, your l33t box under your desk which you rebuild every week anyway? patch it with whatever you like, but a production database server pushing out data to thousands of clients? I want that bastard tested thoroughly before the patch ever hits the net.
Re:Testing is only a priority on closed source app (Score:5, Insightful)
Which is basically a fancy way of saying you're going to treat your user base as guinea pigs and let them test your patch for you.
Hopefully any "issues" they have will not have been fatal...
I'd say the difference is... (Score:5, Insightful)
Microsoft wants to give you one "bad news" per month. Predictable, patch time is "low" meaning the time between release and installation is low. It is easy for IT staff to work that way, you can schedule it.
OSS will give you a patch per issue, patch time is near instant, but they keep coming at you all the time, whenever you can't afford to waste time installing them. That is why you need a distro to keep you patched at all times.
The rest? Bullcrap. The security patches for Linux don't cause more regression issues than Windows. Like Microsoft, they do audits but instead of one "catch 'em all" release, they do several. In short, it is to make Windows look good.
Kjella
Re:Testing is only a priority on closed source app (Score:4, Insightful)
Even OSS developers do some testing before they release their code. At least for the larger (multi-developer) code bases. Quality is essential if you don't want to scare your users/co-developers away. And quality is only partially a result of programming skills.
Now you may point at the difference in emphasis between informal release-testing and formal QA in the legal sense. But it's just rediculous to assume that OSS solves everithing to the point where you just merge & release everthing you type and/or every patch submitted to you without even looking at it.
--
It is impossible to make anything foolproof because fools are so
ingenious.
Re:Testing is only a priority on closed source app (Score:3, Insightful)
If Debian isn't the epitome of an Open Source project that's overly obsessed with quality releases, at the expense of frequent releases, I don't know what is.
Re:Liars (Score:5, Insightful)
Nothing. However, I do believe that they owe the public, and their shareholders, the truth about how they handle security issues -- which, judging by my experience, they did not provide in the linked news article -- and I believe that they should take every opportunity available to improve their security, including working with the people who report security issues to them.
You are an academic nobody in their eyes, despite any delusions of grandeur you may possess.
Maybe; or maybe not. I'm not just an academic who happened to stumble across a security problem; I'm also a FreeBSD deputy security officer. I may not have quite as much experience at dealing with security issues as they have, but I don't think I'm a complete "nobody" in security circles either.
Re:Testing is only a priority on closed source app (Score:3, Insightful)
Thanks for posting that, I'd mod you up if I had points. Which, typically, I don't.
Open source doesn't eliminate the need for testing, but it can make it easier, and specifically make it easier for knowledgable users to fix bugs themselves and contribute back. As for the testing release issues, it wouldn't be much more trouble for closed-source systems to release nightly builds to the world to test, just less tempting to test.
The fact that users can fix bugs themselves, though, is not an excuse for releasing buggy software. By all means give users who want a bleeding-edge release access to your newest and greatest (but maybe not quite fully-tested) code, but don't go around releasing such code as your official version. Give it some time, test it a bit, before putting that out. Just because people can bug test and fix their own software doesn't mean that they should be made to.
OSS can make testing easier, but it does not, as you point out, remove the need for it. For anything above a "hobby" project, for things you actually expect people to use, it's just irresponsible not to undergo at least some testing. Overuse of "caveat emptor" just makes OSS look unprofessional -- which is fine, but it could cause problems when trying to break into more corporate grounds. The people who say both that companies should use more OSS, and that OSS doesn't need to be tested, really need to re-evaluate at least one of those viewpoints.
I sense I'm ranting, so I'll stop.
Re:Testing is only a priority on closed source app (Score:2, Insightful)
most users fall in the last category and they'll quickly jump ships if your stuff is too buggy/unusable and/or there's something better out there user-wise... case in point, firefox, where the majority of the 30+ million downloaders were not open-source contributers but rather software users that found something better.
but hey, if you're just interested in chucking untested code out there for your "partners" then more power to you... this "passive slug" will be supporting more serious projects.
Re:Testing is only a priority on closed source app (Score:5, Insightful)
Why would someone want to buy something he can download for free in other place?, if people tend to "download for free" something that they CAN NOT (by law) use for free??
Of course, now you will tell me that RedHat, Mandrake, etc etc are making buisness with OSS, but the truth is they are making buisness SELLING SERVICES, not the software.
Now, I am a programmer (well, I was a programmer before I started my PhD), I really like to program, when I was in the University I was a Linux advocate (although when I was in High School I was a FreeBSD advocate... can you imagine I bought FreeBSD without really knowing what was it... then when it arrived I spent like 3 weeks installing it, I was like 13 or something).
But, after I finished the University I had written some programs which I wanted to sell, hell I DO know how to program...
I put them like shareware on the internet, it was cool, but I also wanted to "contribute" to the OSS, in the "real world" (i.e. outside the net in my life) I was trying to get a job, As I lived in Mexico that was no easy task, so all my income was from my shareware programs and some money my parents gave me.
But I WANT to program for a living, and that is NOT possible with OSS, only people who have a name and are at the top position in this "OSS" power hierarchy can do it.
There where possibilites of open sourcing my programs and then proffiting with the "customer" services, of course the money I would get there was going to be a hell less than the money I won with my shareware (which was not a lot of course) and besides I DID NOT studied any kind of administration or client service degree I AM A FUCKING PROGRAMER and I want to program because THAT IS WHAT I KNOW HOW TO DO!!
So no, it is not possible to live selling OSS, it MAY be possible to live selling a service but not by pure development.
And of course it is possible to get hired in a company which develop open source as a branch (IBM, Sun, Mandrake, etc) and you could say that you earn your living with OSS... but the one that is paying you is the company.
Nowadays I am making my PhD outside Mexico (no, not in the US, in Europe). I have a wider view of this OSS, and althouh I understand it is great for acadamey (in fact I OSS it every day) It is NOT right for the commercial developer... And now as I have seen the Programming buisness is very crowded I have decided to enter the academy buisness, that way when I return to my country with a Europe degree I would be able to enter and teach somewhere at least...
And, I will be able to use and create OSS (of course as a side project JUST FOR FUN). At the end, that is why the OSS projects propsere, people do them JUST. FOR. FUN.
And this is why inux is liable to remain Geek-only (Score:5, Insightful)
I don't know about you, but I have things I actually want to _use_ my computer for - I don't want to have to review any code changes for patches/upgrades/new versions and check them before I do an install.
Not that I even have the technical know-how to do that for the vast numbers of programs out there.
Right (Score:2, Insightful)
I'm not trying to flame-bait here, either. These are the simple facts. Flame-baiting would be saying something like: Haven't they always boosted their value via PR and under-delivered? Or: Doesn't Microsoft lie like sacks enough for you to notice?
That would be flame-baiting. But I'm not flame-baiting.
The Market Cycle (Score:5, Insightful)
Then the record industry was born. Now a song could make a musician a steady stream of money, for many years. However, after decades of "success" the public saw through this sham and invented ways of putting the right perspective on the value of music and performance. And the musicians returned to being performers because the former era was over.
Actually, that's not how the story ends because the rich benefactors of the record industry used their money to create laws to enforce their way.
Once upon a time, computer programmers gathered in groups to share ideas and collaborate on projects -- just for fun. Often they would solve some incredible problem and get recognition for it. Sometimes they'd get paid hourly to solve a specific problem. Once in a while they'd get real funding.
Then the software industry was born. Now an application could make a programmer a steady stream of money. However, after decades of "success" the public saw through this sham and invented ways of putting the right perspective on the value of software and applications.
Actually, that's not how the story ends. It'll be a while before we get to the end.
I sell lots of open source software. Very little of this software have I written. It's easy for a software-savvy person to download and install OSS applications. It's difficult for the majority of the people on the planet to understand how to download and install any application. That's what I charge for.
You probably wouldn't believe how many times a week I'm asked to install CSS applications. These are packaged products that should be easy for anyone to install. Yet your average business owner and their entire staff are intimidated by the prospect of having to install any application (OSS or CSS) -- they'd rather visit the dentist.
Think about it: For CSS applications, the end user often pays twice.
Can a programmer with 20+ years of experience make good money with OSS? I do.
code != bloat (Score:3, Insightful)
In microsofts case everything has to be implemented upon layers of undocumented C++ classes to which the average microsoft employee [let alone third party developer] can't decode.
Tom
Re:The Market Cycle (Score:2, Insightful)
All I'm going to say is that if Brittany Spears latest album automated mowing the yard for me, I just might spend some money on it.
People spend money on software because the software accomplishes something. (Gaming industry aside, naturally.)
Re:Right (Score:3, Insightful)
And how, exactly, am I to be any better re-assured with Open Source? I can't read the code. I don't know anybody who can. And if I do find somebody who says, "There's a bug in application X", how do I know I can believe them? This whole "everybody can check out the code thing" is really just idealistic fluff to make people feel better, honestly.
'Quality' patches (Score:2, Insightful)
He's close, but not spot on; customers demand quality software, but are forced to deal with faulty programming and broken applications. Customers wait for 'quality' patches, and deal with the associated trouble of a system that's broken-in-the-meantime. But hey, we've got fade-out windows and drop shadows, and some really neat animated assistants, so I really shouldn't complain?
Re:Right (Score:5, Insightful)
Re:Right (Score:2, Insightful)
Re:Testing is only a priority on closed source app (Score:3, Insightful)
sigh. Why is it that when people can't figure out how something is done, they simply say "it CAN NOT be done"?
Firstly, let's get something clear: hardly anyone makes money simply selling software. A perfect example is databases -- for all but the high-end database projects, a free database works just as well (sometimes better) than a commercial, closed-source DB. Yet, people still buy MS-SQL server, and Oracle, and the like for even small projects. Why? They are buying the support of MS and Oracle: not just the telephone support but the "this large company has vetted my software" support. They are buying trust and service.
Now that that's clear, let me explain that I make money by selling OSS solutions, and that RedHat and Novell make money from my work. I contract as an OSS developer/integrator. I sell my development ability and support. But, my clients buy Linux from Novell or RedHat; they are getting support from me, so why would they buy these OS, when they can be had for free?
The answer is simple: people (and to a greater extent, corporations) see value in something they've paid for. If something happens to me, they know someone will stand behind the product. They know that someone they've paid is working on security patches and improvements. And, ultimately, they know the product is less likely to be abandoned.
So, when my clients buy Linux from RedHat, they are buying exactly the same thing as when they buy Windows from Microsoft: trust. Trust that the software has some degree of quality, trust that it will be patched and maintained, and trust that it will continue to be available. With OSS, however, they get the bonus of knowing that migration to another vendor will be relatively painless because the vendors of OSS software have access to each other's code.
It is possible to make money with OSS, but it is a lot harder to start your own OSS business. People don't like buying software (closed *or* open) from one-person organizations.
Re:Right (Score:3, Insightful)
Companies with buggy or poorly written software don't grow large in any of the two cases. Guess what, windows was as good on the desktop as any of its competitors at the time for most people.
Good code in a closed source company is still highly valued because your future depends on your ability to write good code. Getting fired is a lot worse than having your boss say "well, this hacked code you put together to grab weather data could be written better" and have a much more detrimental effect on your career(because of the value of past recommendations).
Open source software has no incentive to do any testing. In open source, you release code and hope others are kind enough to test out and search for the hard to find bugs. In open source, you have an incentive to release lower quality code because others can catch and fix your mistakes.
Saying that hiring someone to fix software is a possible recourse is just idiotic. How much do you think it would cost for me to go get someone to learn firefox to fix a bug in it I don't like? I hell of a lot more than I am willing to pay. Private people don't do this. Small companies almost never do this. Only the big boys can really afford that recourse.
So it seems open source isn't a holy grail. Worse yet, the more unpopular an open source project is, the worse it will end up being. None of the programmers have any reason to go above and beyond. But in closed source, there is a definite reason, its called hunger. And it has played out that way many times. It is usually the underdog that quickly innovates and releases a far superior product to earn market share.
And further, it doesn't matter how much you program for a living, if I give you the firefox code for the first time with a mediocre bug, I guarantee that without previous experience you would take a long time to hunt down this bug. It wouldn't be obvious, as you seem to think it is.
There are no holy grails in programming. And there aren't any in science either. Only basic science uses the peer review system ubiquitously.