Hacker News Reader

Comment by simion314 | Hacker News Reader

Does anybody know how many days it would take from when a critical security bug is discovered in Windows and assuming that the fix is just a few lines of code and not a component rewrite and marketing is not in the way, I am wondering how many steps are from when a fix is created until is released.(I imagine that there may some QA and some managers that need to approve it but I have no idea)

View on HN

Disclosure: I work at MS but not on the kernel or anything related to this security bug. Opinions are my own.

I've seen one-line bug fixes introduce many other bugs.

Adding a null check is always suspicious. Is the system in an invalid state? Should it fail fast instead of swallowing the error?

Maybe the code wasn't touched in several years. Maybe the person that wrote it no longer works there. Maybe the code in question doesn't have good test coverage or documentation. There are so many variables to consider when assessing risk of code changes.

Maybe the person that wrote it no longer works there. Maybe the code in question doesn't have good test coverage or documentation

These are not valid excuses for a company the size of Microsoft.

These are the kind of consideration only companies the size of Microsoft are likely to have.

Touché!

There is an interesting (and very amusing) article about the general concept:

    https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb

it doesn't directly answer the question, but things are far more complicated than they look.

URLs auto link as long as you don't indent them.

It depends. Some bugs can be fixed easily and some might be too complicate to fix even though it looks simple. Usually all critical bugs are attended as soon as they are created (few hours delay). But the actual fix depends on the bug and there is no general formula for that

>assuming that the fix is just a few lines of code

Even assuming that, there could be a massive testing load to ensure that those few lines of code don't mess up something tangentially related, or cause new security issues of their own.

Microsoft fired it's QA department so that doesn't seem to be a reasonable explanation either.

http://www.computerworld.com/article/2878026/microsoft-to-bu...

Assuming you just need to add a check for null pointer and that this bug is very critical like hackers are exploiting it, assume engineers create a fix and are 100% it is safe, hopefully there was no other component that was depending on the broken code , how much it will take to fix it, maybe there is somewhere a history of critical bugs , with the date of when it was found and when it was fixed then we can find the time interval.

The Windows kernel is one of the most mission critical pieces of software in the world. And is easily the most important piece of IP for MS. I'd argue there's no such thing as a "simple fix". I have no doubt even the most trivial of changes has to be very thoroughly vetted.

I've worked on software where without fail every new release would go through more than a week of soak testing.

They could have a solution out the door in less than 24h but it may be a mitigation (ie, disable the service) rather than a proper fix. But that's pretty easy. In fact, it's usually the first thing an engineer does when verifying a bug report - "Ok I've reproduced it, now let's shut off the service and make sure the problem goes away."

Release a patch that disables the vulnerable service and give people a way to bypass that and turn it back on once they've taken proper internal measures. (Read the CVE, block ports, etc...)

Reply on news.ycombinator.com