Linux Developers Patch Bugs Faster Than Microsoft, Apple, and Google, Study Shows (zdnet.com) 43
Linux programmers fixed bugs faster than anyone — in an average of just 25 days (improving from 32 days in 2019 to just 15 in 2021). That's the conclusion of Google's "Project Zero" security research team, which studied the speed of bug-fixing from January 2019 to December 2021.
ZDNet reports that Linux's competition "didn't do nearly as well." For instance, Apple, 69 days; Google, 44 days; and Mozilla, 46 days. Coming in at the bottom was Microsoft, 83 days, and Oracle, albeit with only a handful of security problems, with 109 days.
By Project Zero's count, others, which included primarily open-source organizations and companies such as Apache, Canonical, Github, and Kubernetes, came in with a respectable 44 days.
Generally, everyone's getting faster at fixing security bugs. In 2021, vendors took an average of 52 days to fix reported security vulnerabilities. Only three years ago the average was 80 days. In particular, the Project Zero crew noted that Microsoft, Apple, and Linux all significantly reduced their time to fix over the last two years.
As for mobile operating systems, Apple iOS with an average of 70 days is a nose better than Android with its 72 days. On the other hand, iOS had far more bugs, 72, than Android with its 10 problems.
Browsers problems are also being fixed at a faster pace. Chrome fixed its 40 problems with an average of just under 30 days. Mozilla Firefox, with a mere 8 security holes, patched them in an average of 37.8 days. Webkit, Apple's web browser engine, which is primarily used by Safari, has a much poorer track record. Webkit's programmers take an average of over 72 days to fix bugs.
ZDNet reports that Linux's competition "didn't do nearly as well." For instance, Apple, 69 days; Google, 44 days; and Mozilla, 46 days. Coming in at the bottom was Microsoft, 83 days, and Oracle, albeit with only a handful of security problems, with 109 days.
By Project Zero's count, others, which included primarily open-source organizations and companies such as Apache, Canonical, Github, and Kubernetes, came in with a respectable 44 days.
Generally, everyone's getting faster at fixing security bugs. In 2021, vendors took an average of 52 days to fix reported security vulnerabilities. Only three years ago the average was 80 days. In particular, the Project Zero crew noted that Microsoft, Apple, and Linux all significantly reduced their time to fix over the last two years.
As for mobile operating systems, Apple iOS with an average of 70 days is a nose better than Android with its 72 days. On the other hand, iOS had far more bugs, 72, than Android with its 10 problems.
Browsers problems are also being fixed at a faster pace. Chrome fixed its 40 problems with an average of just under 30 days. Mozilla Firefox, with a mere 8 security holes, patched them in an average of 37.8 days. Webkit, Apple's web browser engine, which is primarily used by Safari, has a much poorer track record. Webkit's programmers take an average of over 72 days to fix bugs.
everyone's getting faster at fixing security bugs? (Score:2, Insightful)
It doesn't seem to do much for the number of current bugs being exploited.
Apparently everyone's getting faster at making new ones, too.
Re:everyone's getting faster at fixing security bu (Score:4, Insightful)
It doesn't seem to do much for the number of current bugs being exploited.
Apparently everyone's getting faster at making new ones, too.
The challenge is that fixing one bug can result in another, especially if there is pressure to release it fast, while not having a suitable testing or QA setup.
That's the "eyes" thing that many misunderstand (Score:5, Informative)
Every month I do two in-person presentations and a YouTube video covering the new vulnerabilities and patches for the month. Then I answer questions about them. I've been tracking vulnerabilities as part of my job for several years now and I've noticed some patterns.
A pattern with Microsoft is that each series of related vulnerabilities lasts 3-9 months. For example right now we're hopefully finishing up the print spooler vulnerabilities - that started seven months ago. Each month we have new patches to try to get the print spooler fixed. Overlapping with that was the Exchange issues. Every month Microsoft's QFE team tries again to fix the vulnerabilities with Exchange. That's to be expected because often they are only seeing the current attack, the current symptom. They don't always have a deep understanding of the underlying cause of the problem.
My experience with shellshock was very different, and typical of important Linux vulnerabilities.
With shellshock, just on one mailing list alone there were just over 100 of us looking at the codes looking at the issue, and trying to find the best fix over the next couple of days. Within just a few hours, Florian Weimer of Red Hat posted a fix, and said that was pretty much the only way to fix it. It was a broad fix, pretty much getting rid of the little-used feature that had the vulnerability. Others tried to come up with a smaller, more specific fix.
About half a dozen more tailored fixes were proposed and each time someone else pointed out how attackers would get around it. Florian said that no "fix" to the feature could ever work - that little-used feature HAD to be removed. All the ways people were trying to stop the exploits were essentially trying to allow an untrusted user to run code, without allowing them to run code, Florian said.
Over the next 48 hours or so, as narrow fixes were proposed and shot down, we all started to see what Florian had seen immediately. We started to understand the deeper issue. What has been immediately obvious to Florian became clear to everyone else over the period of two days or so. Florian's fix was then deployed, and it held. It was right fix.
That's the phenomenon ESR was talking about when he wrote:
--
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, "Given enough eyeballs, all bugs are shallow." I dub this: "Linusâ(TM)s Law". ...
My original formulation was that every problem "will be transparent to somebody". Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. "Somebody finds the problem," he says, "and somebody else understands it.
--
Notice he didn'r say "all bugs are not exist".
Anybody who thinks ESR (or anyone) ever claimed "all bugs are not exist" simply doesn't understand the point being made, and certainly hasn't read the paper.
He said that almost all will be *shallow* to someone - that someone will intuitively understand the true nature of the problem, and the fix will be obvious to someone. You can get to the right fix a lot quicker when you show the problem to enough people so someone clearly sees the right fix, right away. Like Florian did with shellshock.
That's been my experience. With 100 people looking at the problem in the code, you get the right solution much faster than with just one or two people.
Re: (Score:3)
No, that's Oracle. They're unbreakable [cnet.com].
sudo / polkit (Score:1, Insightful)
sudo root escalation existed for years?
polkit root escalation existed for years?
while they may be measuring smaller things that get "fixed fast", the most critical bugs of them all exist for an extraordinarily long time.
maybe they're measuring time from DISCOVERY of the bug to its fix, not time from its introduction!? yup, looks like it!
Comment removed (Score:4, Informative)
Re: (Score:3)
Now, now, he's enjoying his rant - don't go spoiling it for him with logic.
Re: (Score:1)
I'm not sure what point you're trying to make, or how many strokes the morons who moderated you positively have had, but I think that's really the only interesting part of your post.
I, personally, look forward to the day where we know about bugs before anyone even classifies them, but sadly static code analysis isn't quite that good yet. Maybe we'll have a NN for that eventually.
Re: (Score:2)
Its easy to fix things when the impact to the population is low because of a low adoption rate. Sorry not sorry
Well, there's a silly-statement-of-the-week square filled in on my bingo card. Give me a few more and I'll win the entire kitty in short order.
Re:Correct, cause no one uses it (Score:4, Insightful)
Welcome to 2022, time traveler from 2000!
Here in the future, Linux has a dominant marketshare among servers (sometimes known as "the cloud"), supercomputers, embedded devices connected to the internet (we call this the "Internet of Things", or IoT), as well as an incredibly popular new class of all-purpose portable computing devices known as "smartphones". Of course, as you surmised, Linux is still clinging to a few percentage points among die-hards on the desktop, which still accounts for millions of computers by itself.
Re: (Score:2)
Sorry not sorry
You shouldn't be sorry for taking a cheap shot, you should be sorry because you're wrong.
Re: (Score:2, Insightful)
Linux is the most ubiquitous operating system on the planet by an overwhelmingly staggering amount.
Anyone in a technical position should know this. You strike me as some dipshit who thinks desktop computers are the world of computers, and that little magical fairies make the interwebs teleport into your magical web browser.
100% of the world's top 500 supercomputers run Linux.
96.3% of the 1 million top-trafficked web servers are running Linux.
Almost all new deployed control plan
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's bizarre, because he's otherwise pretty damn intelligent. Bit of a douche-bag, but intelligent. My style, really.
But when it comes to Linux, his reaction is predictably virulent, every time. I can only conclude that Linux touched him in the bad place as a child.
"Linux" (Score:5, Insightful)
Do they just mean the kernel itself? If we assume that's the case then it makes sense as that is a much more tightly controlled piece of an OS compared to entire distro. Also the fact the kernel has strong leadership from Linus himself still to this day, he doesn't seem the type to tolerate bugs.
Sampling (Score:2)
This is the kind of social science where the results wil change dramatically depending on one's very subjective definition of “Linux developer” and who is included in the sample, — not much differently than research that pertains to, say, so-called “race”.
Re: (Score:3)
Re: (Score:2)
That's one definition, not the one this researched used, and not what how the term is often used and what many have in mind when they see it.
On top of that, it isn't clear whether your definition would only mean patching bugs inside of Linux, or also patching in other projects they participate in, and of course: does one still count as “Linux developer” if the last time one developed for it was 20 years back?
All these issues aren't particularly clear.
Re: (Score:2)
I patch a bug at Microsoft I keep my job barely (Score:4, Informative)
Not the best summary, in my opinion (Score:5, Informative)
They're really looking at bugs Project Zero submitted to various organizations, and how often these reported bugs get fixed within Project Zero's supposed 90-day grace window. So, the takeaway metric is what percentage of these reported bugs are patched in under 90 days.
The article has a table which I think better represents the information Project Zero is really trying to get out there:
Vendor / Total bugs / Fixed by day 90
Apple / 84 / 73 (87%)
Microsoft / 80 / 61 (76%)
Google / 56 / 53 (95%)
Linux / 25 / 24 (96%)
Adobe / 19 / 15 (79%)
Mozilla / 10 / 9 (90%)
Samsung / 10 / 8 (80%)
Oracle / 7 / 3 (43%)
Others* / 55 / 48 (87%)
Re: (Score:2)
I would also think that the number of people who work on Linux is far greater than the OS teams at either Microsoft or Apple.
Microsoft and Apple are the only ones that work on their OSes, and even though they may have hundreds or thousands of people on it, most of them aren't working on the core OS itself. A bug in the Windows kernel is probably down to a handful of people who own that piece of work - there will be similar teams for other features. One big department might be working on say, block devices,
Re: (Score:2)
To add on, I will not be surprised if the developers in Microsoft or Apple, and other propritary software companies can't view the code to all the components, etc which goes into their OS/software, and may only have access to the areas they are working in.
If there is a bug which involves multiple components in the software, that may hinder fixing it if everyone has a restricted view of the code.
Not saying thats how it's done there, but will not be surprised if it is, due to security, etc.
83 days my ass (Score:1)
Re: (Score:2)
Was that a security hole? I believe this was focused on security issues, not bugs generally.
One more reason (Score:3)
This is just one of the reasons I have avoided Windows and Apple since the mid-1990s and have only Linux systems in my house. It's also noteworthy that Linux systems let you apply fixes at your convenience, and not when they demand it. How many times have you been in a hurry to leave, shut your PC down, and been told: Do not power your computer off! Upgrading! And then this is usually followed by a threat that your operating system will never work again if you interrupt the update before it completes. You must watch the thing for 15 or 20 minutes as it slowly downloads stuff and reboots itself a couple of times. Not me, brother.
pkexec vulnerability (Score:1)
Not Surprised At All (Score:2)
It's not a coincidence that the projects with the best response times are open source. While the "many eyes" theory of open source has been debunked, the fac
Re: (Score:2)
While the "many eyes" theory of open source has been debunked
This theory?
"Given a large enough beta tester and codeveloper base, almost every problem will be characterized quickly and the fix will be obvious to someone."
That doesn't state that there won't be bugs, or there won't be security bugs, or there won't be severe security bugs, or there won't be severe security bugs that lurk in the code for a long time. Note that it doesn't say problems will be found quickly, but that they will be characterized quickly. So what has been debunked?
Re: (Score:2)
So what has been debunked?
I'd say that it was merely the assumption that "many eyes" are always looking at the source. Always, and without a compelling reason for doing so.
Re: (Score:2)
That's not what it means though. It says WITH many eyes, bugs are shallow. It doesn't say anything about whether there will actually be many eyes.
What defines linux? (Score:2)
What are the quality of the patches? Do the break as much as the fix?
Many eyes (Score:2)
Context matters. You're not intelligent for taking a phrase and spinning it beyond what was intended.
The fact is openness means that people, IN PRINCIPLE, have the ability to look for and fix things, and that everyone else also benefits from the openness, even if they themselves do not have the expertise to fix things. And the fact
No surprise (Score:2)
At a big company, you have to ask permission first. That requires meetings to determine how to CYA.
With Linux, the developer just does it if he feels like it. Right, he.
Economies_of_scale (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org] works for Linux