Slashdot Mirror
With So Many Eyeballs, Is Open Source Security Better? (esecurityplanet.com)
Sean Michael Kerner, writing for eSecurity Planet: Back in 1999, Eric Raymond coined the term "Linus' Law," which stipulates that given enough eyeballs, all bugs are shallow. Linus' Law, named in honor of Linux creator Linus Torvalds, has for nearly two decades been used by some as a doctrine to explain why open source software should have better security. In recent years, open source projects and code have experienced multiple security issues, but does that mean Linus' Law isn't valid?
According to Dirk Hohndel, VP and Chief Open Source Officer at VMware, Linus' Law still works, but there are larger software development issues that impact both open source as well as closed source code that are of equal or greater importance. "I think that in every development model, security is always a challenge," Hohndel said. Hohndel said developers are typically motivated by innovation and figuring out how to make something work, and security isn't always the priority that it should be. "I think security is not something we should think of as an open source versus closed source concept, but as an industry," Hohndel said.
According to Dirk Hohndel, VP and Chief Open Source Officer at VMware, Linus' Law still works, but there are larger software development issues that impact both open source as well as closed source code that are of equal or greater importance. "I think that in every development model, security is always a challenge," Hohndel said. Hohndel said developers are typically motivated by innovation and figuring out how to make something work, and security isn't always the priority that it should be. "I think security is not something we should think of as an open source versus closed source concept, but as an industry," Hohndel said.
A: Other people
More is better when it comes to bugs that are mostly obvious to the typical person, but doesn't benefit complex code that whooshes over the head of 99.9% of people. My co-workers tell me I have an attention to detail. Some code will get 3-5 people looking at it and testing it over a period of a month or two, then the'll ask me to take a look. Many times I will find several bugs in 10-15 minutes by just reading the code, then I'll have questions about the code and ask them to run some tests that will further find some more bugs.
I do not trust normal humans to anything technical right. I would prefer languages that work better with static analysis, more free tools to provide quality static analysis, and more fuzz testing.
When software doesn't have visible source code, the legitimate users have no assurances regarding what it's doing, other than those imposed by the operating system (which they might not have complete source for either).
However, the bad guys still take the trouble to disassemble the code and find its vulnerabilities.
With many eyes, you still might not find all bugs, but you can, and can do so without the unreasonable investment of disassembling the code and reading disassembly - which is not like reading the real source code.
The larger issue is that we need publicly-disclosed source code for some things, to assure the public good, whether it is proprietary or Open Source. For example the emission control code in automobiles, which it turns out multiple manufacturers have defrauded.
Bruce Perens.
It depends. FOSS software often lacks QA, unit testing, code static/dynamic analysis and regression testing. Compared to a FOSS software with a similar QA process - I would say yes, more eyeballs make it better. Compared to a commercial software with a strict QA process - no.
Back in 1999, Eric Raymond coined the term "Linus' Law," which stipulates that given enough eyeballs, all bugs are shallow.
That's only true if those eyeballs are actually looking for bugs and organized enough to do something about them. Even then it's more like a principle than an actual truth. Some bugs are much harder to find than others no matter how many people are looking.
Linus is right... but note that he talked about eyeballs, not open vs closed source. If an open source project is obscure, or if the code is too hard to read, it may not get any scrutiny. On the other hand, closed source code from companies that care about security enough to pay security firms to scrutinize their code, or to hire security-knowledgeable developers and have them look at it carefully, can get a lot of eyeballs.
In the normal course of events, though, open source code almost always gets more attention than closed source, just because anyone who wants to look, can.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
If the "Many eyes makes all bugs shallow" theory were true, Heartbleed never could have happened.
The problem since the first toy computers came out in the 1970s is that everybody thinks he's a developer.
Most people employed as developers today should not be allowed behind a keyboard. And that includes the majority of people coding open sore software.
Get a job, you bums.
As Linux has dumbed things down and tried to be portable uberalles without any regard to security and as people use the idiot UNIX model of one piece of software doing only one things, the reliance on shitty, insecure middleware has brought us to the point there is usually only one project doing any particular thing. So when there's a CVE it affects all the free software victims including companies looking to save money by use open office space and free (haha) software.
No, this is all wrong. And it's going to get worse before people can admit the Linuxperor has no clothes. Damn communists turned the world upside down.
You wanted a handout? You got it. Now live with it, ya humps.
It's not a matter of eyes, it's a matter of eyes that are actually looking. Just because a million people uses OpenSSH every day doesn't mean that it's more secure, unless someone sits down and audits it, it could as well be closed source.
The difference is that if you WANT to audit it, you CAN. Without first reading more NDAs than you'll eventually get to read code.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I found no flaws in the code. Then again I nothing of coding, so there's that.
But I looked it over...
Open source has the potential for more eyes. It can be fixed after official support ends. It can be audited by anyone. Tampering with the code of open source may be more likely to be noticed. Tampering with closed source code can be more difficult. Commercial closed source developers may be more likely to be held accountable for vulnerabilities and thus can be more motivated to provide a secure solution. Commercial closed source may be more likely to be reviewed by a security expert because of there is not a security expert on the team, one can be hired, whereas for non commercial closed source, this may not be as likely an option. Closed source has security by obscurity, which can make some vulnerabilities somewhat harder to find by malicious actors.
My sig doesn't address Anons, sigs aren't visible to them.
While the "many eyes" can be theoretically a better model, practice has shown very few actually look at Open Source software with security in mind.
Even critically important projects like OpenSSL.
Security review takes time. Time is money (even in OSS world). Security audits require money. They don't get done, unless commercial entity (using OSS) commissions them.
The "many eyes" is a really bad security model in practice.
Tens of millions of loonix/openssl users didn't find heartbleed.
Linus' law only sort of applies to bugs on the codepaths most trod.
Believing it as a tenet open-source dogma WILL give you a false sense of security. Most users, and even most developers, aren't in a position to hunt down serious bugs that aren't apparent with normal use of the software. They just expect their tools to work. And when they do, they don't stop to look for security bugs, they just keep on with their business.
The larger issue is that we need publicly-disclosed source code for some things, to assure the public good, whether it is proprietary or Open Source.
There is a famous saying with elections that it's not the people who vote that count, it's the people who count the votes. Similarly having some source code to audit is great but it's meaningless if the company doesn't actually utilize that exact code or finds some sneaky way to circumvent it.
That said I do agree with your point.
Isn't it all down to the fact that there is at least an opportunity to investigate, review, patch and so on. Considering there's even competitions to hide malicious code in plain sight the quality of the review of open source does really depends on people's understanding of what they are investigating and the arms race of intelligence is healthier with open source.
The fact is that there aren't many eyes on most parts of the code, and of the ones that are, very few of them are qualified to find the problems.
I use some software. It's in debian (and ubuntu) but hasn't been updated in years. It's not the sort of thing that needs to be updated. But I've manged to find and fix 6 or 7 bugs. serious bugs. coredump now type bugs. I've stopped reporting them back to debian because nobody is looking at bug reports. There is no upstream. I've reported them back to a fork I found on sourceforge but they asked me to rewrite my commit message without oxford commas. Seriously.
I'm glad it's open source, I wouldn't be able to use or fix it, otherwise. But nobody else will benefit from my bug fixes.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Fucking better man! you know, just better. The software is fucking better!! no matter what.
wait , what, uhh, this is about security?
No, open source is better!!!! better!!!!!!!!!!!!!!
BETTER!!!!!
See WordPress. Abysmal architecture, programmed by monkeys on crack, pretty good security. The last critical gap was closed after only 8000 websites had been infected, something like .0002% of the installbase or something.
Pretty neat.
I bet that gap in that obscenely expensive Oracle Java web application server thingie isn't found half as fast let alone fixed in such a speed.
We suffer more in our imagination than in reality. - Seneca
Most of the web runs on layers of open source software. If Linus' Law was more than an open source marketing point, the web would be a poster child for secure computing.
Even back in the 90s, open source software wasn't more robust or secure than proprietary software, and that continues to be the case despite numerous assertions to the contrary. Sure, there are more eyeballs on the code, but few delve deeply into it, and fewer still delve deeply into it looking for flaws or vulnerabilities. A lot of open source software is built on a shoestring. There aren't the resources to get the features the code needs, let alone the programmer hours to make it bulletproof.
Moreover, open source software is as vulnerable to players with evil intent as any other kind of software. If a programmer wants to introduce a backdoor, all they need to do is make themselves an expert on some ugly low-level area that no one else wants to get into. The vulnerabilities are hidden by the complexity of the code and the time cost of digging through the ugly code. Bonus points if the programmer is backed by government or industry.
What would you do if you were the NSA? What would you do if you were a private entity that wanted access to all the data everywhere? Do you think they're not actively doing all that and more?
Now add the fact that different layers and components are built by different groups who likely don't coordinate with one another. If one layer or component is well-built, well-audited, and secure, bad players can just move their mischief elsewhere.
See subject & APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p (remove spaces between characters & download).
Yields more security/speed/reliability/anonymity vs. any SINGLE solution (99% of threats = hostnames vs. IP address that most firewalls use) more efficiently/FASTER + NATIVELY 4 less!
(Vs. "Bolt on 'MoAr' illogic-logic" competitors slowing you, hosts speed you up 2 ways (adblocks + hardcodes u spend most time @) vs. competition loaded w/ bugs (DNS/AntiVir) + their overheads (messagepass ('souled-out' to advertiser addons) + filtering drivers) & their complexity leads to exploitation).
* ONLY 1 of its kind in GUI on Linux/BSD!
(Much better vs. Windows model in speed & efficiency + new "merge" feature)
APK
P.S.=> I use Firefox on Linux & it works like a DREAM w/ hosts. You rotten bastards can benefit from my greatness as God's gift to you... apk
There's a huge collective blind spot in the programming community as a whole... they somehow believe that Ambient Authority is an acceptable basis for writing applications in a world of persistent networking and mobile code.
Your software is just fine - well written, functional... I'm going to continue using the Host File Engine by mmell February 17, 2017
Your premise that hostfiles are a good way to deal with advertising and malvertising is quite valid - by JazzLad April 20, 2016
his hosts program is actually pretty good by xenotransplant August 10 2015
his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg September 25 2015
I like your host file system by Karmashock September 09 2015
that APK guy, I use his host file by rogoshen1 Tuesday March 03, 2015
I personally use a HOSTS file blocker produced from a genius called APK by 110010001000 October 27 2017
* Best part = Linux 64-bit model's faster/more efficient (2x work in 1/2 the time)
APK
P.S.=> For a faster/safer/more reliable internet. Even you rotten bastards can benefit from my greatness. God's gift to Slashdot will NEVER be silenced... apk
Are we about to get hit by another bout of catastrophic closed source bugs, since someone is pushing this agenda filled tired old crap again?
"All bugs are shallow" never meant that there would never be any bugs. It simply means that with enough eyeballs, all discovered bugs are quickly fixed. Which seems to be holding very true so far.
Propaganda and deliberate misrepresentations of facts should never make it as "news".
Moorinux's Law: Linux's source code size doubles every two years.
Tablizer's Law: More OSS eyeballs means more interest in product, meaning more source code, meaning more bugs such that bug rate still breaks even.
Table-ized A.I.
Any bug can be fixed after discovery because all eyes will be on it. (Or, at least, the eyes of most of the experts for that particular system.)
A huge part of security is being proactive throughout development---in design, code submission, review, and auditing.
Private companies can hire people to fill these roles as needed, but most open source projects rely on the security consciousness of individual contributors. Since security is often boring or counterproductive to the development of new features, I can easily see security being less of a priority for some developers.
Good security requires many eyes throughout the development process. It needs ongoing oversight to ensure that every module and code submission is consistent with the security model for the project.
BSD has one seriously security-conscious leader, but that is not typical. Maybe Red Hat will pay someone to oversee the security of the Linux kernel or audit its code, but most projects won't have that kind of backing. They'll rely on luck of the draw---maybe you attract someone with security expertise, or maybe you don't.
Without a dedicated security focus, projects should go through hardening phases where they deliberately welcome security experts and design/redesign as necessary for security. Even if it means a slowdown or moratorium on new features. Security takes time and effort, and the only solution is to put more eyes on it.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
Comment removed based on user account deletion
Yes, the bugs can be shallow, but the eyes have to actually look at the code. Unfortunately everyone assumes another has done it or will. Guess what, they haven't and won't.
Do you see anyone debloating the kernel? I looked into it once (video drivers primarily), but there was so much code duplication scattered in so many places that it would have required more time than I had and more importantly lots of interaction with the lkml...
Maybe with a GSOC project or some other sponsorship, but until then there will be very few eyes on the prize.
Open Source is better, but not because there is some vast horde of people auditing the code for free. There isn't. Linus wasn't talking about auditing code. Linus wasn't even necessarily discussing security. That quote doesn't claim or even imply that some benevolent group of open source programmers are scouring code for security flaws.
Linus was simply observing that even difficult bugs are quickly understood when enough people look at the problem. The known problem; not latent flaws in some large body of work.
Maw! Fire up the karma burner!
Proof is: Microsoft is closed source for instance. Is it secure? Not even to Microsoft although they are the ones who can audit the source. That's doubly stupid because they are KNOWN crooks. Anti-Trust the movie was about them but using a fictitious company name "Synapse".
They are all spyware and they are closed source. How can closed source ever be thought of as secure and cool? It can't.
Time to get Microsoft off of retail PC's too. Plenty of Linux distros are super easy for elderly and brand new tech illiterate people.
Die Microsoft die it is shit.
Exactly. ESR summed up Linus's thoughts as ".. all bugs are shallow", not "all bugs don't exist".
Linus's exact words were:
"Somebody finds the problem, and somebody else *understands* it."
I'll share two examples from my own experience. Somebody found the shell shock bug and suggested a fix. Over the next few hours, hundreds of people looked at it. Some saw that the suggested fix wouldn't quite cover this variation or that variation, so they tweaked it. Florian Weimer, from Red Hat, said those tweaks would never cover all the variations, and suggested an entirely different fix, one that went to crux of the problem. Over the next few days, there was a lot of discussion. Eventually it became clear that Florian had been right. When he looked at the problem, he immediately understood it deeply. Well, it looked deep to us. To him, it was shallow.
""Somebody finds the problem, and somebody else *understands* it", Linus said. Stéphane Chazelas found shellshock, Florian understood it, fully, immediately.
There was no need to release a patch to fix the patch for the patch as we often see from Microsoft, or as we've seen from Intel lately. With hundreds of people looking at it, somebody saw the right solution, easily.
Here's another example from my personal experience with the Linux storage stack:
https://slashdot.org/comments....
What's needed in the open-source world aren't more eyes (quantity), what's needed are more clueful eyes: eyes of individuals deeply familiar with the code. Note: these eyes need to be familiar with the entire code/program/thing, not just exclusively the change being made.
It is good to have additional eyes on a general level, but in I'd estimate 80-90% of scenarios in OSS, experienced and familiar eyes are what's necessary.
The problem with open-source projects (and to be fair, this can and does happen within closed-source projects as well, e.g. employee-who-wrote-tons-of-code leaves company; documentation may be good but tribal knowledge is often undocumented, ditto with the "whys" behind the design of something) is that you often have a large quantity of eyes, but very few (sometimes only one pair!) of experienced eyes. The experience comes with time (not necessarily making changes, but just absorbing the knowledge and reasoning and approach styles of those more experienced!) and in many OSS projects, time is not something that's honoured. Instead, the proliferated belief is something like: "some random person on the Internet should be able to download this code, fix the bug, and submit a patch and/or PR", which is unrealistic most of the time.
Security is a whole other matter. That is to say, a whole other "level" to things that is oft neglected these days. Whole separate subject, but applicable.
When you claim it's better "because many eyes can look at it" the following questions are germane.
#1 - How many eyes ACTUALLY look at it, rather than just "have the opportunity"?
#2 - Of what quality are those eyes? Do they know the programming language in question? Are they up to date?
#3 - Is it just the code in question that matters? Or is it the code, plus a bunch of dependencies to other libraries, pre-compiled or otherwise? How long would it take to become not just a passing pair of eyes, but expert in the programming of the particular application?
#4 - Are those eyes likely to report what they find? Propose code solutions, or at least file bug reports?
#5 - Do the devs actually get around to acting on the proposed code or bug reports?
#6 - How fast do other people relying on this particular project stay up to date, either by downloading the code fixes and recompiling or downloading updated binaries?
It's not really any "safer" if it's open source but someone's pet project that gets an actual new version source/binary release every 6-12 months at most...
What's it being compared to? Closed-source orgs usually don't reveal details and problems. We only hear about them when enough people get screwed that it can't be kept from the public. For every closed-source breach you hear about, there may be dozens or even hundreds that go unreported.
The world is full of bright but under-employed coders who have thousands of spare hours to dig for holes. Third-world standards of living and wages make the rewards for evil hacking large from their perspective. Thus, there's a lot of incentive among a lot of people to bust into things.
The labor and incentives for prevention are simply too small compared to that for hacking.
Table-ized A.I.
I have trouble with this industry-concept that software security should be put first -- it's an impossible business objective.
Think about how many industries focus on security. Banks, sure. Money transport, of course. Prisons and jails.
My air conditioner broke last week. It needed a new capacitor. It was a 5-minute $0 fix. Walk between the houses, open the compartment, pull out the breaker.
Now imagine your air conditioner, with the software industry's concept of security. Can you? How many check-points for a repairman to get to my air conditioner? How much added hardware? How much added expense in dollars and time? What stops someone from throwing a paint-filled balloon from fifty-feet away?
Security, when lives aren't at risk, is just so rarely worth it.
And when lives are at risk? Maybe you have a lock on your front door. Maybe it's a deadbolt. Maybe it's a really fancy locking mechanism, super-secure. Your front door is likely right next to a glass window. Congrats on the lock. Enjoy the bars on your windows.
And what stops your car, at highway speeds, from hitting another car at highway speeds? Right, a thin strip of white paint. Excellent. Sometimes the paint is yellow, even better.
We've never focused on security. We simply cannot afford to.
Instead, we talk about insurance, and criminal law enforcement.
So that's what I'm suggesting for software. Law enforcement. Deterrents.
Anything else, well, is just uncivilized.
You misunderstand what the quote is about.
It says "... bugs are shallow", not "bugs don't exist".
See:
https://it.slashdot.org/commen...
In the case of Heartbleed, it became public on April 7th.
The fix was available on April 5th. Meaning it was patched, and some people protected, before users even knew there was a problem.
Compare some IE bugs which were publicly acknowledged for seven YEARS before being fixed.
It says "... bugs are shallow", not "bugs don't exist".
See:
https://it.slashdot.org/commen...
My experience was, I saw a bug report in some open source and tried to fix it, and by the time I had a patch written a better one was already released upstream and I was the last person to upgrade because I was off trying to write a patch.
There are so many freakin' eyeballs available, volunteers are mostly just jerks like me who are getting in the way trying to help! You have to have an inside line to the developers or security researchers to even learn about a bug early enough to have anybody notice even if you understood it as soon as you heard about it.
Even writing new types of network servers; somebody announced they were abandoning a web middleware tool that was popular, and so I started plugging away at an apache module, but within a week somebody else released something similar enough to mine that I just stopped coding and used theirs. Sure, my architecture choices were better, but theirs weren't bad enough to amount to bugs so nobody would ever notice or care.
Programming is easy, the hard part is finding an unserved use case! And fixing known bugs is a pretty obvious use case.
I think there are a couple of aspects to this that might be a bit off the beaten track of threads posted so far...
The first is that we need to think about like-for-like comparisons. When these observations were initially made, 20 years ago, how many projects [either closed source or open source] were using automated source code scanning solutions? i.e. technology specifically written to parse code for flaws?
In other words, 20 years ago the "landscape" was likely to be close to "even". Today, however, many commercial software development shops use vulnerability scanning solutions and/or routinely conduct binary scans of resultant code. Today, many commercial development shops use automated test harnesses for load testing and regression testing. It is fantastic that they do. They do this because they can afford to and because the rapid advancement of this sort of technology has made it possible. Twenty years ago? Not so much.
This would suggest that we might start to see a difference in post-production bugs between Open Source and Commercial/Closed Source software where the development environments differ between these two operating models.
The second observation would be far more tenuous. In the same 20 year period, we have seen many different programming languages "come and go". Obviously the more established platforms (COBOL, C, C++, JAVA) continue to be popular, but this, too, brings differences in bug reports. The longer a language has been in existence, the more mature development becomes, the more libraries become available, the more skilled developers become in preventing even the more obscure bugs.
I don't have access to the data [and wouldn't know where to look for it, tbh] but I think it would be easy to graph out "average number of vulnerabilities per thousand lines of code" - i.e. defect density - over a 5, 10 or even 20-year period of language use. It would be reassuring to see if that trended down - but even more interesting [and worrying] if it didn't.
A while back I went looking to see if there were any "big rules" about different programming languages being more or less prone to vulnerabilities than others. I had read [maybe 25 years ago] that Ada was once thought of being a language with very few bugs. The theory was that it's compiler was so strict that if you could get your code to compile, it would probably run just fine. I was really surprised to learn that although there had been a few studies, there didn't seem to be any emergent evidence to suggest that there were differences between languages. I was surprised because my ignorance had suggested to me that helpful and/or heavily typed languages would be less bug-prone that more relaxed ones - i.e. that JAVA would have a lower defect density than C. Apparently [and I'd be happy for anyone to correct me] the evidence does not support this.
Sorry that this is trending away from the original question, but I think that context is absolutely crucial to get to a good answer to the original post - and that we would find that, like forecasting the weather, it would be pretty hard to do...
Your experiences remind me of something I learned about open source development. I now start by posting about what I intend to do. I've received these responses:
John is working on that and expects to release it next week.
No need to do all that, just use setting Xyx and skip the last part.
That seemed like a good idea, but when we looked into it we noticed this trap.
We decided we want Betaflight to focus on LOS. Your idea fits better with the iNav fork, which already does most of that.
Hey that's a good idea. Can you also allow multiples? That would be useful for me. I can help test.
It's pure BS. Yeah, you *can* look at the code, but how many do? And how many have the requisite knowledge to recognize it when something is wrong?
As noted on Slashdot over 10 years ago (https://it.slashdot.org/story/08/05/11/1339228/the-25-year-old-bsd-bug) it took 25 years to fix a bug in some commonly used open source. My understanding is that the Samba team even coded around the bug instead of looking at the code and getting it fixed.
Is open source security better than closed source? Sometimes yes; sometimes no. Depends on the developers, the projects and the companies involved. Security is about process and there's a lot more to the process than having access to the source code.
See subject: "Imitation=sincerest form of flattery" PROVING u WISH u were ME & poor imitation = u.
* I don't post on hosts in topics that don't fit it (unless you of "moron kind" bring it up 1st)
(Hence, you give yourself away you're impersonating me!)
APK
P.S.=> What are you trying (& failing) to accomplish? Trying to "make me look bad"?? I have to ask as it's EXTREMELY DIFFICULT for me to "think like 'your kind'" (no-mind do-NOTHING "ne'er-do-wells" that can't think, lol) to even TRY to understand your "mental processes" (none obviously that are up to any good)... apk
See my subject: I'd kick YOUR FUCKING ASS for stalking & harassing me you unidentifiable little cowardly cunt - tell me your REAL name, address, & phone # so I can verify it's REALLY you & we can settle this once & for all, fucker...
APK
P.S.=> Everyone SEES you constantly stalking & harassing me bitch, so WHO ARE YOU FOOLING but yourself - & IF I ever get to you? You'll WISH you were dead cocksucker... I shit you not! apk
Open source isn't necessarily better than closed source and closed source isn't always better than open source.
Both have their issues and advantages.. Both have their place.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Somebody found the shell shock bug and suggested a fix. Over the next few hours, hundreds of people looked at it. Some saw that the suggested fix wouldn't quite cover this variation or that variation, so they tweaked it. Florian Weimer, from Red Hat, said those tweaks would never cover all the variations, and suggested an entirely different fix, one that went to crux of the problem.
Shellshock. A bug that was shown to have existed since 1989, and was patched in 2014.
I'm not sure this is the best example to use when discussing whether open source security is better than closed source security.
#DeleteChrome
You'll certainly find more bugs in open source code, simply because they're easier to find. It doesn't follow that there are more bugs in open source code. It's probably more true that there are many more undiscovered bugs in closed source code.
Debate is a form of harassment. Do not question my truth.
I think it's a perfect example of the difference between "bugs don't exist" and "the bug is shallow - to someone". Lots. Of people looked into it deeply and couldn't figure out a good way to fix it. Weimer immediately saw what needed to be done - it was shallow to him, with enough eyeballs "the fix will be obvious to someone".
Compare Intel's Meltdown patches. They release a patch and say everyone should use it. Then two or three weeks later "oh shit, don't install our patch! We'll make a new patch soon.". How many Meltdown patches has Intel released and then retracted? They are missing the set of eyeballs that would see the simple solution to the core problem.
This is an entirely separate issue from avoiding bugs in the first place. Both are important. However, bugs that all the script kiddies have exploits for are much more dangerous than bugs nobody knows about. Therefore, fixing known issues quickly and correctly is a big deal for security.
My father used to tell me that most crimes are crimes of opportunity, which I've largely found to be true in my experience. Someone leaves their car unlocked with valuables visible. Someone leaves their phone at the bar as they go to use the restroom. That sort of thing. In the real world, the criminals you're most likely to encounter are common ones with unsophisticated methods, so simple preventative steps coupled with the effective deterrents you mentioned are generally more than adequate to prevent any given person from becoming a target.
But in a world of connected devices, everything that isn't locked down is effectively just as insecure as a valuable left behind an open door. Everything becomes a crime of opportunity. Not only that, but the opportunity is open to any criminal in the world, rather than being limited to those in your immediate vicinity. Prosecution is an ineffective deterrent when the criminal remains anonymous in most situations. Insurance is an insufficient redress for a "genie can't be put back in the bottle" situation like identity theft, which can have unforeseen, lifelong ramifications.
Put differently, most traditional cases for physical security (e.g. your home example) come with low risks and simple remedies for the victims (i.e. things are mostly replaceable once there's a monetary payout, either via insurance or restitution), and low rewards with high risks for the criminals (i.e. they're physically limited in how much they can take, with each act increasing the likelihood they will be caught), meaning that our civilized, traditional approaches do well at handling those issues. Connected devices, however, flip those balances on their heads, with high risks and poor remedies for victims (i.e. important things can be lost and never fully recovered), and low risks and high rewards for criminals (i.e. with the ability to automate and attack from anywhere, criminals can do a lot more damage with very little exposure to themselves). As such, our traditional deterrents and redresses no longer function as well as they once did.
Ideally, we'd restore those balances, but until and unless we succeed in doing so, it isn't an overreaction or an unreasonable response for people to take their security more seriously when it comes to their connected devices.
P.S. The traffic example you gave was good, but I'll quibble about its inclusion, since it's addressing safety, not security.
Somebody found the shell shock bug and suggested a fix. Over the next few hours, hundreds of people looked at it. Some saw that the suggested fix wouldn't quite cover this variation or that variation, so they tweaked it. Florian Weimer, from Red Hat, said those tweaks would never cover all the variations, and suggested an entirely different fix, one that went to crux of the problem.
Shellshock. A bug that was shown to have existed since 1989, and was patched in 2014.
I'm not sure this is the best example to use when discussing whether open source security is better than closed source security.
On the closed source side of things, lots of bugs that impact Windows 10, will also impact Windows XP (with patches available to customers with agreements, or on XP embedded, or POSready). Back when older operating systems were supported, lots of bugs impacted XP, 2000, NT4, and 9x. So it's likely that many of these current bugs also impact ancient versions of Windows.
We already have laws against this stuff, but we can't hire enough people to staff the agencies that are supposed to handle enforcement. Clearly, your solution has already been tried, and it has failed.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
We need software freedom for all published programs. Merely being able to see some source code doesn't grant anyone the right to compile that code into an executable they can share (including distribute commercially), install, and run. So, source code for one's own vehicle under a free software license is needed. It's quite easy to maintain a code base where the malware isn't listed but is present in the executables people receive and run while publishing source code that has no malware in it and is licensed to users under terms that would allow public disclosure but not the other freedoms of free software.
Digital Citizen
Also, "Linus' law" was written before things like automatic bug reporting that every OS does these days. In other words, software companies noticed how useful it was, and started copying it.
"First they came for the slanderers and i said nothing."
No real diff, but with proprietary code, only 1 entity **can** fix the issue or even admit the issue exists.
With F/LOSS, there are many eyes who have a chance to see the issue and correct it, usually withing a few hours of discovery.
F/LOSS fixes usually are available in a few days, at most.
Proprietary software fixes take 3-9 months.
Which is better?
I have trouble with this industry-concept that software security should be put first -- it's an impossible business objective.
It would be kind of cool if people could follow basic security principles, like, "Don't use telnetd" or "don't release software with default passwords." You don't need perfect security, but think about it a little, at least.
"First they came for the slanderers and i said nothing."
At home, I have used Linux - first Redhat, then Fedora - since about 1999. I have never used any sort of virus/malware scanning software. I don't know how common this is.
"When the going gets weird, the weird turn pro" -- HST
So lets fix the original line, so 'given enough 'competing eyeballs all bugs are shallow'. You did not fail in your attempt to correct a bug, you played a role, you solution not as good as the other but still a comparison and next time, yours might be the better solution. Fixing bugs is about applying the best solution and having a range to choose from, whilst it does delay things, still works to ensuring the best solution at the time is used. So your effort was most definitely not wasted, just part of the overall competing eyeballs, looking for the best solution.
You might think you did a bad job but I think you did a good one, just part of the team effort. Sometimes you solution misses out and sometimes your solution will be the best one. Practice makes for better performance.
Chaos - everything, everywhere, everywhen
Just kidding...
[($)]
First of all there's a significant difference between "Open Source" and "Free Software". The first only saying that the source code is publicly available, the later saying that your are actively invited to engage in the development process.
Unfortunately people forget that "The freedom to improve the program" means that the program needs to be simple enough that individuals can have a decent chance of understanding it and making meaningful changes. We see a dangerous trend towards more complex and integrated software.
Now if you have simple software which can be understood easily, you will have the eyeballs looking at it. There are some semi-free projects like the Linux kernel which have strict code reviews trying to main some level of control by always having a second set of eyeballs looking at it.
What we tend to forget is that the emergency of mostly competently written Free Software in the 1990s raising in popularity in the early 2000s has caused many closed source software companies to try and get their act cleaned up. Microsoft, for example, had a program in which they tried to fix _all_ bugs. It used to be normal for computers to crash, now every crash is seen as a reason to stop using software from that company.
First of all: Hey, Gang, check it out! Bruce Perens replied to me on slashdot! Yeah man, I started a thread that was joined by Bruce Perens! Awesome! ... Ok, sorry, had to get that out of my system ...
I get PHP pretty much the way you pointed out. "PHPs badness is it's advantage", I've argued before. There's a fresh Lerdorf talk on YouTube where he himself says it pretty clearly: "PHP runs shitty code very, very well." ... Big upside that is. The downside is, of course, that PHP is *so* easy to do stuff with, that everyone gets to discover their own version of OOP. After they've built a mess of a CMS, that for some odd reason might become hugely popular ... Maybe because it's got nice buttons to click on or something.
I do PHP for a living (nice book on PHP 5 btw., It got me started. Thanks!) and I'm always torn hither and fro between "take the cash and run" and moving on to Go, TS or something. I've just decided to stick with PHP, since there's so much work to do here and can get certifications ( customers like those) and a gig at every street corner.
We suffer more in our imagination than in reality. - Seneca
The right question is "trust". Do I trust those who designed and built the software if they don't want me to look into it?
These days intentional misfeatures are more relevant than unintentional bugs.
Whose agent is Excel? Exactly. So if Microsoft's and my interests happen to align, fine for me. If not, I've got a traitor in my house.
(And beware of all those half-assed "open source-ish" things, which try to keep the control at the other side, as Chrome or Android are, be it by hardware-locked keys, be it by store tricks or some such: they are a honeypot)
Thanks but no, thanks.
There are a lot of projects (SystemD, Linux kernel) where the maintainers are hostile to people submitting security patches or filing bugs relating to security.
https://www.theregister.co.uk/2017/07/28/black_hat_pwnie_awards/
https://www.theregister.co.uk/2017/11/20/security_people_are_morons_says_linus_torvalds/
Eyeballs don't help when they find things and are told to fuck off.
The difference is that every software exploit, fundamentally, involves an attacker asking for access. They may "ask" in all manner of ways, but they all involve sending data - a sequence of bits - with the meaning that the attacker would like access to this computer, please.
I don't expect my house to have umpteen locks or bars on its windows, the same as I don't expect my computer case to be built of bulletproof titanium. What I would like is for my butler to open the door for me, and only for me.
I can't think of any animosity, no. Of course I've never sent utter crap to Linus. That gets a fun response.
One module owner was "picky" about following all the guidelines exactly, and really thinking through how to do things. That got frustrating at times. It resulted in high-quality software, though. Once when we could couldn't agree on approach A or approach B I suggested we try talking on the phone, thinking just *maybe* a different mode of communication would make a difference. It definitely did make a difference. Halfway through the conversation he thought of approach C, which sounded really good to both of us.
People sometimes have different ideas, or disagree, but I listen carefully to understand their thoughts and concerns and we find an approach that works for both of us. Recently I sent a pull request for a module which is a simple wrapper around a more complex module. I wanted to add an option. He thought the change should instead be made in the more complex, embedded module. I explained why I thought that wasn't the right way to go. He didn't want to make XML::Simple more complex by adding options, so instead we decided to change the default behavior of XML::Simple and not make it an option.
We've never focused on security. We simply cannot afford to.
That is because you and many other people fail to understand how the concept of security is to be applied.
Ultimately, if security is seen as a "state of things", then the ONLY way to be secure is to freeze time since any changes could lead to making things less secure.
Ultimately, things change. Managing that change intelligently is security. Just follow a few simple steps:
Establish what you want to do.
Look for any risks associated with that activity.
Determine if any of those risks can thwart your original intention.
If your original intention can be thwarted, you are free to spend as much energy mitigating the risk as you will on the original activity.
If your original intention can NOT be thwarted by the risks, then it is absurd to spend the same, or more, energy than the original intention.
The final step is to determine if any of the mitigations prevent you from executing your original intention. If the mitigations prevent you from executing your original intention, your security has failed. If your mitigations have increased the energy cost by more than 100%, then your security has failed.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
That sounds like a response I would expect if I sent "this is crap".
I've read and re-read this semi-humorous article to make sure I remember the serious points it includes:
http://www.catb.org/esr/faqs/s...
The gist of it is, if I want something done, I do as much of it as I can, sometimes that's describing the problem in as much detail as possible, including describing what I expected to see happen instead. For a feature request, that means identifying the use case - who would use this new feature, fot what? Other times I send a pull request - I do fix the problem. Normally I only do a pull request (fix) for very simple problems. For more complex ones I send a message describing what I plan to fix first, asking for feedback.
I don't know where you live, but maybe you should consider moving.
I would agree with your father that crime is mostly of opportunity -- I say you can't ever stop Ethan Hunt, so certainly I'd agree that crime prevention is of opportunistic crimes.
But crime prevention isn't about security.
My beloved left her iPhoneX in a restaurant bathroom last week. When she realized, an hour later, she found it at the front. That means at least one woman saw it in the bathroom, and handed it to at least one waitress paid minimum wage, who had this unlocked $1'250 iphone for an hour downtown. And no, she doesn't put a passcode onto it, because that makes the phone unusable in reality.
Currently, and for the last sixty days straight, I have $200 of garden hose and sprinklers on my front lawn. I also keep about $1'500 of gardening tools on the front porch, in plain sight.
I've never owned a car that locks its windshield wipers. I've watched locksmiths and parking lot attendants break into a car in under thirty seconds. Just last week I broke into a car with a wire hanger in under three minutes.
Smashing a window next to a front door is pretty convenient. And with about an hour of practice, picking a lock is just as easy.
I park my convertible open in parking lots all the time. I don't worry about the $200 of stuff that I leave on the seat. I worry about the birds perched on the lightstand above, or the kid with the ice cream cone.
It's not opportunity that stops me from stealing your stuff. It's ethics.
That's like saying the lock on your front door "asks" for a key with the right pattern of bumps, and picking the lock is just sending the bumps a different way.
I don't want to ring my bell and wait for my butler. I want to walk into my house unattested. I also don't want to pay for a butler, nor live with one around. That's why I have a lap-dog, not an attack-dog.
My point is best encapsulated by your final sentence -- all security efforts increase the energy cost by more than 100%.
I want to drive fast. I build a road. I don't want someone else on that road to bump into me, which would kill me and thus impede my original intention of driving forward, fast. So I need to put concrete dividers between the lanes.
Building a road is easy. Even paving a road isn't so bad. But bringing in concrete dividers, and orchestrating entrances and exits to them is absurdly expensive.
Hence, we use white and yellow paint, and just presume that people aren't trying to kill each other with cars.
Think about what a handful of ball-bearings or tire-spikes would do if you just flung them onto a highway?
-Works in MY rig/environment
-RTFM (I already did, this isn't in there)
-Fix it yourself we're working on bigger things, the point of giving you the code is YOU fix it
Hell, with most projects even trying to get them to fix typos and grammar issues in the tooltips or help-docs is frustrating.
Something is missing in this story. Care to show me a link to one?
-Works in MY rig/environment
Means we need to know exactly which environment it doesn't work in (along with what "doesn't work" means).
-RTFM (I already did, this isn't in there)
Often means the person didn't know which word they were looking for in the manual, and therefore didn't see it without reading *carefully".
Seriously, if you're frequently not getting good responses, it's very likely the way you habitually handle / report things is missing some important element that you don't realize you need to include.
Either something you don't realize you need to include, or an aggressive, off-putting attitude. I seriously did read ESR's semi-serious piece at least three times, so I don't forget.
Agreed, but that misses what I was saying. In real life, people like you are who I commonly deal with. In a connected world, unethical people are who I’m bound to encounter because the boundaries have been removed by connectivity. Ethics work fine when we surround ourselves with people like ourselves. They fail when anyone can reach us.
...and hence, I'm saying we make the connected world work like the real life that it is. We start enforcing the laws. We make examples of people. We call them criminals. We make it just as easy to fine them.
And let's be clear, I don't necessarily mean that we always need a big huge court case.
I live in a wonderful little city, next to a giant huge city. We have some very wonderful neighbour-to-neighbour systems. For example, in my city, you are expected to work out the fence situation with your neighbour. It is expected that the two of you will come to an agreement, and no one else cares what that agreement is. However, you have a right to a fence, if you want one. So if you can't come to an agreement with your neighbour, you are allowed to just go ahead and build a fence, on the property line, send half the bill to the city, and the city will pay it instantly, and simply add it onto your neighbour's property tax bill.
The same is true if your neighbour doesn't shovel the snow from their sidewalk, lets their grass/weeds over-grow, or generally lapses on anything that good-neighbours are expected to do.
There's no court case, there's no question. I call the city, the city calls them, if they don't comply right away, the city comes out and does it for them, and charges them for it.
There are plenty of such systems, including those that don't require owning a home. I should think that the connected world would be no different.
And again, I understand the intricacies of accidents. Stumbling upon someone's machine by mis-typing an IP address is like tripping and stumbling into someone's garden. Downloading all of their files is like meticulously picking their flowers. Deleting their files is like unearthing their plants. Doing it multiple times, and after they've asked you to stop is the unequivocal crime.
I think the problem with our laws today, are that they don't allow for obviously equations. I've said this from the street-level cameras. My living room couch isn't public -- even if it's visible through a window, even if the curtains are open. Someone with an x-ray telescope in the street doesn't get to say that I put my couch where it could be seen. The laws were written when houses were long drives from the public street. The law was never written properly. It was never context-aware.
I agree with everything you're saying about how things should function. Enforcing our laws is a good idea. Full stop. It's how other things function in real life and it's how things should work in the digital world as well. I'm not disagreeing with you about that. Nor am I disagreeing with you over what is or isn't a crime. We seem to be on the same page about all of that.
But how do we put it into practice? Your suggestion that "we start enforcing the laws" is predicated on the assumption that we are capable of enforcing the laws. I don't think we are. Going back to my original response:
Connected devices, however, flip those balances on their heads, with [...] low risks and high rewards for criminals (i.e. with the ability to automate and attack from anywhere, criminals can do a lot more damage with very little exposure to themselves). As such, our traditional deterrents and redresses no longer function as well as they once did.
Put differently, I think the laws are fine, and I agree that we should be enforcing them, but I think that we are already enforcing them to the best of our ability, which only serves to prove that our ability to enforce them is broken. We certainly should be working towards enforcing our laws more effectively, and where we have an inability to do so we should be figuring out how to overcome those hurdles. But, during periods where the law can't keep up with criminals, the only reasonable choice a person can make is to secure their property themselves.
That's all I'm advocating for. I'm not saying we should do it instead of enforcing the law. I'm saying that we should do it until we can enforce the law effectively.
Then let's address that part -- "that we are capable of enforcing the laws".
A long time ago, there was something call the wild wild west. Perhaps www has always stood for wild wild west. The wild wild west was defined by the imbalance of powers, mostly due to two things: the power of criminals with unlimited access to guns, and the lack of power of corporations to actually secure anything like money.
A gang of thieves with horses and guns could easily threaten any business, and any sheriff. Today's "organized crime" isn't in contrast to today's small criminals, it's in contrast to the gangs of criminals in the wild wild west, where holding up any bank was exactly that easy.
This parallels, in my mind, to our conversation at-hand. Corporations have no ability to secure their data, and hackers have unlimited access to hacking tools and escape horses.
But banks haven't become any more secure over the last thousand years. Sure, there are big huge vaults that are very secure. But ATMs are less secure than a 1'000 year-old safe, and they are easily ripped from the wall with a few obvious tools. Similarly, a brinks truck is nothing more than a few humans, easily attacked by a gang of ten teenagers with hammers.
But in the wild wild west, there were deterrents that limited crime to only bands of outlaws. Death-penalties were much more common.
I'm not suggesting that we should kill hackers. I am suggesting that we should eliminate their online freedom in the same way. I don't think it would be difficult to effectively revoke a criminal's general hacking tools (connection, real equipment, et cetera). And hey, if the internet really is an essential human right (which is ridiculous, by the way), I'm sure we can develop a consumer-only tablet-style device for these criminals, that really can't do much more than surf the web.
Maybe, that's actually easier than I think. Maybe it comes down to nothing more than curating their data connection -- in the same way that a prison guard curates a prisoner's movements. We'd be jailing their data connection. It might be as simple as that.
It didn't need fixing; if you didn't understand it, it isn't a fix to change it to mean the thing you misunderstood it to be.
Yes, I fully realize that some structure is needed for non-trivial software. That's not news. But there is nothing close to clear-cut science about when to use architecture/pattern X over architecture/pattern Y; and equally important, why X is better than Y. The reasoning GOF-ers give often cherry-picks narrow future change scenarios. I can often think of many more possible future change scenarios that floods their narrow thinking into the gutter. And the reality of actual change is even more brutal than me as it unfolds. It's far more "scenario clever" than I can be, even though I can out-scenario the GOF fans/writers by about 4 to 1. I slap them twice, reality slaps them a dozen.
And it often depends on the domain, as you hint. If you don't know the domain, your crystal ball will fail too often. After you build 20 games, you probably have a good feel about how requirements change and how some stay similar over time. But at Game #1, you know shit about that. I can articulate my experience in a domain about what's likely to happen and not happen, but that's NOT real science: it's merely applying the lessons of experience. (Granted, it may be an early step in science, but that just means we are in the bronze age of software science.)
It lacks anything close to real science. It's Argument From Authority.
And I feel that many heavy GOF-ers are anti-database, and reinvent in code what should be in the database or queries. ER diagrams are easier to absorb and navigate than large tangled OOP pasta. If your particular mind doesn't like databases and feels weaving complex "noun webs" in code is better, that's your prerogative, but don't assume I or anybody else should enjoy what appears to be moldy pasta to us. Databases make it easier to query and study noun info from "different angles". We are not stuck with the nesting or code file structure of the original author. It's more "meta". Show me all green creatures with blue spaceships having a life-span of less than 200 years who came from planets without large moons.
Table-ized A.I.