Microsoft hits back after Google publicises Windows bug

[KeyboardDemon]

Difference in that argument is that MS were actually patching said security issue, they just weren't deploying it until the scheduled patch Tuesday (ie when companies expect the patches) a few days later, in this case Google waiting a couple of days wouldn't have hurt anyone except their attempt at getting one over MS, which it hasn't in my opinion, it's just lowered a lot of tech savvy people's opinion of google, because by announcing it before the patch they've only caused the end user potential issues.

Most of us don't mind the usual a versus b company 'fighting', just look at android/iOS or Apple/Samung, it's when the companies put the consumer at risk just to try and get one over another company that people don't appreciate the approach.

In the case of Moonpigs API security issue, making it public was necessary to get them to fix the issue, they didn't even attempt to patch it, MS were making the appropriate changes to fix the bug.

The logic is that companies that rely on Windows for their IT infrastructure will have timetabled their IT resources around being able to deploy new security updates on the first Tuesday of every month and therefore changing the release date would/could upset the apple cart etc..(maybe apple cart isn't the best analogy!)

But here's the part that confuses me, in what way would it change anything if those patches would have been made available on the Sunday? The staff that would be rolling out the patches on the Tuesday would still be able to do so, right?

[Saracen]

...

But here's the part that confuses me, in what way would it change anything if those patches would have been made available on the Sunday? The staff that would be rolling out the patches on the Tuesday would still be able to do so, right?

Now that is a good point.

My gut tells me there ought to be an answer, but I sure can't think of it.

[aidanjt]

What was wrong with pushing out the patch last Tuesday?

[LSG501]

quite a few big software companies all do it on 'patch Tuesday', so I suppose it's a semi official patch day for the industry... and I kind of like having a set day for updates rather than them just popping up (along with notifications) whenever.

As to why they couldn't get it out on a Sunday.... I wouldn't be surprised if they couldn't get it out any sooner than Tuesday, they'd already shaved a month off the expected completed date, not to mention xmas/new year delays, just to try and keep Google happy, they asked for an extension until next month... they 'accelerated' testing stages, meaning it likely wasn't as thoroughly tested as usual. Google's fixed 90 day period doesn't take into account holidays obviously, yet I'd bet they'd expect us to.

What was wrong with pushing out the patch last Tuesday?

because that would have been the first Tuesday of the month, not the second

[Yunali]

I think we are forgetting that Microsoft actually had two releases prior to this one, and they could maybe had urged.

[crossy]

I use Cyanogenmod KK on my S3 and it is very stable. Used Carbon before that which was good but not quite as stable. Much better than the official Samsung bloatware ever was, and since it is AOSP based there are other people who know what they're doing checking the code under the hood.

I hear good things about "SlimKat" for the S3 - and since I've given the S3 away to one of the kids (who is now complaining that it's slowed right down) maybe it's a good time to revisit the 3rd party bazaar.

[wasabi]

Now that is a good point.

My gut tells me there ought to be an answer, but I sure can't think of it.

Cuts down on the end-user perception of reboot hell if it only happens once a month.

[LSG501]

I think we are forgetting that Microsoft actually had two releases prior to this one, and they could maybe had urged.

um... the flaw links to underlying code of the os, ie not something that is going to take a few days to fix and then test.

Oh and I just noticed something... google reported on Monday the 13th of October, the second Monday of the month and a day before patch Tuesday, 90 days would ALWAYS come before Patch Tuesday so at best MS had 60 days to fix the bug to work with patch Tuesday, Google would know this too.

The cynic in me says this was the plan all the while, sod consumers safety etc, luckily it seems the security issue need pc access.

[aidanjt]

um... the flaw links to underlying code of the os, ie not something that is going to take a few days to fix and then test.

That's a meaningless phrase. 99% of code in modern software projects underlies some other code in some manner or another. It's no excuse for taking over 3 months to fix it, do your QA and deploy. Linux kernel developers commonly turn around security patches in a matter of hours after discovery.

[LSG501]

That's a meaningless phrase. 99% of code in modern software projects underlies some other code in some manner or another. It's no excuse for taking over 3 months to fix it, do your QA and deploy. Linux kernel developers commonly turn around security patches in a matter of hours after discovery.

Ok, I'll rephrase it then as you want to be pedantic, you know what I mean... it's core part of the os code, its relating to user accounts meaning if done wrong you won't be able to access your user account or use the computer.

You can't really compare linux and windows, they're completely different in their approach to coding the os.

[aidanjt]

Ok, I'll rephrase it then as you want to be pedantic, you know what I mean... it's core part of the os code, its relating to user accounts meaning if done wrong you won't be able to access your user account or use the computer.

How is that different to the Linux kernel?

You can't really compare linux and windows, they're completely different in their approach to coding the os.

Yes, the Linux kernel is much, much, much, much bigger, and much much much much more fragile than the NT kernel.

[LSG501]

How is that different to the Linux kernel?

you clearly are struggling to read my posts for some strange reason... I never said that they were different when it comes to having a user 'account'... pretty much all desktop class operating systems have support for multiple users, and I'm sure if done wrong Linux could have the exact same issue where you'd lose access to your user account. The difference here is that most linux users are quite happy to tinker with the code themselves if a problem arises, windows users don't usually want to do that.

Yes, the Linux kernel is much, much, much, much bigger, and much much much much more fragile than the NT kernel.

You do realise you've just proven my point that they are completely different in their approach.... you could easily put your comment another way - the linux kernel is always a work in progress (or broken depending on your perspective) so it doesn't matter if the 'latest patch' breaks something else, because the developers will just fix that 'new bug' in another update. The testing on linux is done in a more of a live setting (part of the open source philosophy) than testing in house before being released like MS uses... which is better depends on what your usage needs are, I'd personally prefer it thoroughly tested before being released to the public.

[crossy]

aidanjt/lsg501, may I jump in here.

I think what you two esteemed colleagues are trying to get at is the same idea, but from different directions. Allow me to explain.

Linux, as Microsoft is oft fond of telling us, is a "mess" developed by a variety of development teams and individuals with little in the way of overall direction. Windows, on the other hand, is developed by a single large team with close direction. Put another way, Windows is a project, Linux is a graffiti wall.

The downside of this is that Windows is tightly-integrated, whereas Linux has had to take more of a "black box" approach with very well defined interfaces. So if a bug hits one of those black boxes then all you have to do is make sure that you get the same garbage out (grin) after you've done your patch. On the other hand, Windows reputedly has a spaghetti explosion of documented and undocumented interfaces. So it's pretty self-evident that it's going to take more testing to fix the latter properly.

By the way LSG501, I'll take issue with your comment that "most linux users are quite happy to tinker with the code themselves if a problem arises". This is - in my experience - not correct. Linux users can tinker if they so desire (because the source is available), Windows users do not tinker (because there is no source available). Being rude perhaps, but your comment sounds a bit like the old Microsoft FUD that Linux users are constantly "under the hood with a spanner". I can just see the reaction if I suggested to my current customer that I wanted to write my own patch to be deployed on their 300-400 Linux boxes! No, the SOP there is to report the issue to RedHat (or Suse, Canonical as appropriate) and let them deal with it - exactly the same as if I was talking to Microsoft (Windows), or Oracle (Solaris), or IBM (AIX) or HP (HPUX). Of course, if we're not talking about a commercial deployment then sure, knock yourself out and get out the compiler...

Your comment though, does make something occur to me. When I first got into Linux (way back in the early 90's) kernel patching was pretty much de rigeur, however these days it seems to be a rarity. Actually I can't remember the last time I did actually need to recompile a kernel to include a feature. Maybe that's an indicator of the way that Linux (and specifically the kernel) has evolved and solidified.

Aidanjt: your comment about the Linux kernel being larger and less resilient than Windows NT's one is interesting. Firstly shouldn't you be comparing like-for-like, so if it was actually NT's kernel then shouldn't you be looking at the time-equivalent setup of Linux? Secondly, if you weren't speaking about NT specifically, but all Windows's NT derivatives, like Windows8, then I'm doubtful, have you got any links on that (because you've piqued my curiousity!).

Thanks guys, interesting exchange, thought-provoking.

[TheAnimus]

I think there is a huge difference between some code in the Linux kernel, and something in the Windows one. For a start off automatic updates are widely used on Windows, where as on Linux there is often a 'erm yeah, you are going to have to change' attitude that simply isn't there on Windows. I can't simply fire up a 10 year old binary on the last Linux Kernel, for better or for worse, that's not like with like.

This is why QA regression takes so much longer on windows, they also support far more hardware platforms with that same release.

[aidanjt]

I can't simply fire up a 10 year old binary on the last Linux Kernel, for better or for worse, that's not like with like.

Nonsense. You can run a 20 year old Linux binary no problem at all. The Linux kernel never breaks userspace. If there's one golden rule the kernel developers have, it's that. Linus Torvolds has verbally eviscerated many a developer for submitting patches which break userspace. If you have problems running a 10 year old Linux binary, it's because its userspace dependencies aren't available.

[aidanjt]

Aidanjt: your comment about the Linux kernel being larger and less resilient than Windows NT's one is interesting. Firstly shouldn't you be comparing like-for-like, so if it was actually NT's kernel then shouldn't you be looking at the time-equivalent setup of Linux? Secondly, if you weren't speaking about NT specifically, but all Windows's NT derivatives, like Windows8, then I'm doubtful, have you got any links on that (because you've piqued my curiousity!).

I didn't say Linux isn't as resilient, only fragile. Because of its monolithic nature. If you go fiddling around with kernel libraries you can horribly break drivers, which can call any part of the kernel. There's no hardware abstraction library sitting between drivers and kernel services, which is part of why Linus doesn't like people calling Linux 'modular', because it isn't, its code is just pluggable. But when it's tested, compiled, running, and battered with QA, it's a solid kernel.

And that driver integration makes the whole project irreducibly larger. I mean, it's really, really, really big. Go to kernel.org, download the latest vanilla kernel source code, and unpack the archive, it's frigging huge, and that doesn't even come with any of the git metadata, a git clone of Linus' repository will weigh in at something more like 1.6GB.

NT kernel devs can keep their much more modular project much neater by being able to keep kernel services and drivers broken up into their own smaller projects which are way easier to manage. And of course, the vast vast vast majority of Windows drivers are managed by the hardware vendors. Which is good for a single company, because even Microsoft can only effectively throw so many human resources into squashing bugs.

No one approach is right or wrong, they both have advantages and problems. But the point is to dismiss the notion that Windows bug fixing is super duper hard, or that the QA process is way more difficult, while the competition isn't. It's nonsense. Linux kernel bug fixing isn't for the faint of heart at all, 'a pile of matches' scarcely does the task justice. And patch integrators (whether it's pushing them into mainline, or backporting to older kernels used by existing distro releases) still have to do an assload of QA to make sure they don't break anything on working (often enterprise server) machines, but they still manage to get patches out in a very timely manner.