Doubling the deadline to 180 days is probably reasonable IMO.
I doubt the fix for this and testing takes 90 days, or even 45 days.
If that's the case, then either Microsoft forgot about them, or they carefully orchestrated a PR scandal against Google (wouldn't be the first time - like the time they built an unauthorized Youtube app that Google specifically told them not to build, and then notified the whole media about it, putting words in the reporters' mouths).
What I find interesting is that there are at least a couple of cases in which bugs were marked as being subject to the 90-day disclosure deadline, but not made publicly visible until days or weeks after the deadline had passed.
https://code.google.com/p/google-security-research/issues/de...
https://code.google.com/p/google-security-research/issues/de...
Microsoft informed us that a fix was planned for the January patches but has to be pulled due to compatibility issues. Therefore the fix is now expected in the February patches.
So, they met the deadline and fixed the vulnerability, but due to compatibility issues had to pull it before being released through Windows Update.
But this is bugfixing, not creating new programs. It shouldn't take this long.
If Microsoft says "100 days", saying "okay" instead of " no, 90" gives a timeline 100 days, not 101.
Often the size, scope and wealth of resources induces an increasingly slower response to such things.
Flat out 'more money to fix the problem' should never make things slower. Worst case you can ignore the money.
Even if it's too late to add people for project X, you should be able to use the money for something to improve productivity on project X+3.
If I'm wrong about something please explain.
I don't know how I can my my point more clear.
If a manager shoves in more workers and slows things down, they are failing at their job.
They are worse than useless.
Because someone useless would take the extra budget, not hire anyone, and not slow down the work. Perhaps they would waste it in vegas.
I am saying nothing that contradicts that book. Just two simple points:
1. More resources only slow down a project when they are misused. They are never inherently bad.
2. It's not even hard to speed up work on security bugs, because each bugfix is a different project and can have its own dedicated team.
Please actually point out something I said that was wrong, instead of making vague references.
Ignoring more money is pretty unlikely to be an option as a whole, and inefficiencies generally cascade down to some extent.
But even more important is that these outside slowdown effects are pretty minor. If this was software development then you might have no recourse and you'd be somewhat slower overall. But this is handling many many independent projects. You can hire more teams without having man-month problems, and then handle bugs efficiently.
>Ignoring more money is pretty unlikely to be an option as a whole, and inefficiencies generally cascade down to some extent.
Again, I blame management. A nice sturdy cardboard box as a manager is impervious to social effects from other departments, and it can soak up extra cash too.
I expect anyone being paid to manage to do a better job than a box. Not to go along with the flow uncritically.
The point is that Microsoft has the money to hire 100x more developers than the other guys, they should at least be well organized enough to deploy a part of that man power effectively.
Lets put it this way, there are 7 companies out there (at least) maintaining various different distributions of UNIX that can patch quickly, why can't Microsoft patch their 7 operating systems as quickly? From my view what you are saying is that because Microsoft is a monolithic company with 7 code bases it is somehow harder than 7 companies with 1 code base each? How does that track? Especially when Microsoft has a 100x more money than each of those other companies.
I'm not saying there is such a thing as a man-month. I'm saying there are ways to organize production, teams, and software so that people can provide more work than in poorly managed environments.
Maintaining code is not a trivially parallelizable function.
Yes, I know this, thank you.
But we are talking about billions of dollars vs. millions of dollars (for Linux / BSD). We are talking multiple orders of magnitude(!) more money. I realize there isn't a Silver Bullet, but the fact that what we have heard coming out of Microsoft about they're management practices year after year is ABYSMAL, it is not an excuse. Especially when people who are working for free, with no/little organizational support, can beat them at releasing security fixes.
> because of organizational overhead involved
So maybe they should fix it? How is their incompetence at running an organization a valid excuse? If it was a problem they cared about they would be researching how developers and teams of developers perform best, how best to organize code, etc. Instead they used stacked teams for years on end. I have no sympathy.
If it's as serious problem maybe they should stop making new operating system features and devote more resources to fixing, cleaning up, depreciating, etc. the ones they already have?
They are making business decisions, and their ineptitude at security is a result of them. There are no excuses of "they are the only one's doing X" for "they are bad at doing Y when they do X" when they are promising Y!
RedHat is POSIX compliant so why don't you just lump in every POSIX compliant device ever made? /s
The most recent one is somewhere in the User Profile Service, which is about as far away from the hardware as possible. Shellshock didn't need testing on every possible hardware combination it runs on either, did it?