Surprise, when everyone knows, the patches come out quicker. It seems that the piece is intended to take a shot at Microsoft's patching process, and maybe it is, but there are some interesting things in there to talk about. First of all is the time lag.
Is this any different from any software vendor or even internal corporate software? If your boss knows, or the client knows, don't you work a little harder and a little quicker? Isn't it more critical and don't you rush things in addition to working harder when it's a "public" patch that is needed?
I'm sure we all do. And it's human nature to put more effort into something that's widely perceived as an issue and less effort if you know that you may have more time. We all do that and our work schedules, effort, and productivity change depending on a variety of things, including the importance of the work.
The piece also leaves open a number of questions and mentions this, noting that the analysis might be flawed. There's no mention of if the rushed (or delayed) patches had to be repatched later. There's concern over patches applying to one area, but other similar flaws found in other parts of the software remaining unpatched. That's something for sure that should be examined in looking for re-patches or whether things are rushed. There's also the lack of examination on what else was happening inside Microsoft, and whether people working on other projects had to be pulled off them. We all know that delays things as well. They take time to get their head back into code, they may be annoyed, a critical person could be out, etc.
Not to mention that the statistical methods might not be the best ones. I'll leave that to the mathematicians to figure out.
Patching is hard. As is finding bugs. I think Microsoft has done a much better job over the last 3-4 years and the quality of software, at least SQL Server, has improved. However there is still definitely room for improvement.
Follow me on Twitter: @way0utwestForum Etiquette: How to post data/code on a forum to get the best helpMy Blog: www.voiceofthedba.com
From my experience:
If a user reports a bug then the QA time would be right on it. If an in-house tester found a bug after release then we'd probably wait until the next scheduled release to fix it.
Of course, the severity of the bug is always taken into consideration: I assume Microsoft do the same. For example, when writing financial software, if a bug was found that caused figures to be incorrect, we'd patch that straight away. If the GUI was awry then we'd leave it until the next release.
I think severity should be the main consideration, and then you can take into account who knows about it. If it's non-severe and the user doesn't know, then why bother alerting them?
I begin my software development career using CPM to make machine control systems with the Motorola 6809 processor. I remember it taking 4 to 5 hours after identifying a minor problem in code, such as a timer change, to get the changes made, compiled and burned back into the EPROM's. Today, that kind of change would take minutes or seconds depending on the nature of the control system.
When DOS came along and I discovered how easy it was to write code and use real programs to make my work easier, I became a fan of Mr. Gates. Through the years the Microsoft team has amazed me with how they have met the competition and eventually chosen paths that for the most part, have helped the whole IT industry.
Please don't get me wrong, everyone needs competition to help them rethink bad decisions and I wish all MS competitors’ success as they help us all see new and better ways to use our computers for greater productivity. But, come on, give the big guy his due... It's a better world with MS than it ever was without it...
Patches, who uses stinking patches anyway???
I'm not surprised. When you think about it, it makes sense.
The risk of releasing patches without extensive testing is high. Of course, nobody expects patches and hotfixes to get the same amount of testing service packs do. But I'm sure that the people at Microsoft try to get as much as possible of the more important tests done before releasing anything.
If a potential security hazard has been identified in-house but is not public yet, the risk of customers being exploted by hackers is low. After all, they'll have to find the exploit first.
However, once a security hazard is known to the public, it's also known to the hackers. You can be sure that every hacker will try to use it as much as possible before MS releases a patch. The risk for customers to be exploited gets extremely high.
For patches to secure non-public security problems, the choice MS has is to release before finishing all tests (high risk) or postpone release (low risk). For patches to secure publicly known security problems, the choice MS has is to release before finishing all tests (high risk) or postpone release (extremely high risk). In both cases, MS will choose the option with the lowest possible risk.
I think the delay makes plenty of sense - in an ideal world (where the PR guys don't exist), things should be prioritised according to needs, not demands. As an old boss of mine was very fond of saying "You seem to have mistaken this place for a democracy!"
Here is a key point in the article:
Toulouse pointed to one particularly problematic patch that took the company 200 days to fix: a vulnerability in a component of Windows (and many other networking applications) known as ASN.1, at the time considered the largest vulnerability in the history of the Windows operating system. In the course of testing the patch for that flaw -- reported by security researchers at Aliso Viejo, Calif.-based eEye Digital Security -- Microsoft was forced to reset the process at least twice as internal developers found additional problems that were being masked by previously unknown glitches in the fix.
I would prefer that Microsoft (or any other software vendor) take the time to fully test the patch before releasing it. This can be a lengthy process but if the vulnerability has not be disclosed to the public then the software vendor responsible to take the time to make sure that the patch is not going to cause any problems with the software and, more importantly, not expose any additional vulnerabilities.
I would guess (or at least give the benefit of the doubt) that a good amount of the delay in patches for vulnerabilities that have not received "full disclosure" has to do with testing and the other patches pose a bit more risk to the users. Then again, I am fairly optimistic
I'm sorry, but I'm afraid that I can't buy into the "let he who is without sin cast the first stone" defense. When I slap down my several hundred dollars for a MS product I expect it to be secure and bug free. Of course, it never is. Am I surprised? No. Am I disappointed? Continually.
Continual hot fixes, patches and service packs are a sad testament to the quality of MS products, and delaying any such updates for any reason other than to assure quality is unethical.