Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Foundation: Bugs Can Be Made Shallow With Proper Funding

Posted by timothy on from the cybernetic-eyeballs-are-people-too dept.

jones_supa writes The record amount of security challenges in 2014 undermined the confidence many had in high quality of open source software. Jim Zemlin, executive director of the Linux Foundation, addressed the issue head-on during last week's Linux Collaboration Summit. Zemlin quoted the oft-repeated Linus' law, which states that given enough eyes, all bugs are shallow. "In these cases the eyeballs weren't really looking", Zemlin said. "Modern software security is hard because modern software is very complex," he continued. Such complexity requires dedicated engineers, and thus the solution is to fund projects that need help. To date, the foundation's Core Infrastructure Initiative has helped out the NTP, OpenSSL and GnuPG projects, with more likely to come. The second key initiative is the Core Infrastructure Census, which aims to find the next Heartbleed before it occurs. The census is looking to find underfunded projects and those that may not have enough eyeballs looking at the code today."

95 comments

  1. The best bug is the one not written by zyche · · Score: 1

    Spending resources on 'finding the next Heartbleed' bug... I fail to see the advantage of finding it by a coordinated search as opposed to someone just stumble on it (as long as the bugs are reported responsibly of course).

    Software can't be made secure afterwards, it must be the the primary goal.

    1. Re:The best bug is the one not written by Gaygirlie · · Score: 3, Insightful

      Software can't be made secure afterwards, it must be the the primary goal.

      That's bullshit. Software can definitely be made secure afterwards even if it wasn't that to begin with, there is no other obstacle to that than manpower and time. Also, security being a primary goal does not guarantee that there won't be bugs, so again, that makes that saying utterly ignorant. Bugs, by very definition, are accidental issues, not designed-in features, and no amount of "primary goals" will guarantee that mistakes and accidents won't happen.

    2. Re:The best bug is the one not written by Anonymous Coward · · Score: 0

      Tom/Barbara, the act of "making the software secure" ends up, in practice, meaning that the software is pretty much rewritten from scratch with security being the primary goal. That's where the "manpower and time" comes in. The software may not be completely rewritten all at once, but the final product that's deemed "secure" will contain basically none of the original code.

      The development process that the GP is describing is like:

      Write secure software ===> Use secure software ===> Benefit immensely from secure software

      The development process that you're describing is like:

      Write insecure software ===> Get fucked again and again by its security flaws ===> Rush frantically to rewrite pretty much all of the software ===> Throw it all away because it's an ungodly mess ===> Write secure software ===> Use secure software briefly ===> Go bankrupt due to the stupid amount of money wasted on writing insecure software

    3. Re:The best bug is the one not written by zyche · · Score: 1

      Except that pretty much noone spends that time or resources to do that. It's more fun to continue adding features into the doomed architecture. Or start over... again.

      If you design a software with a certain feature set insecurely, it's often difficult to keep those features when re-goaling for security.

      A depressingly large majority of all software hasn't been coded with best-knowledge tools and APIs in mind. Not even those of the time of writing, but particularly not the one of the current time!

    4. Re:The best bug is the one not written by BarbaraHudson · · Score: 1

      The poster you're replying to wasn't me, you insensitive clod.

      Now, the poster was correct. The original unix was a mess when it came to security. Things evolve, and our understanding of the problem evolves as well. Something that was designed to be secure 5 years ago and passed scrutiny then could very well be swiss cheese today. You HAVE to be able to add security - the alternative is rewriting from scratch every time.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    5. Re:The best bug is the one not written by Eunuchswear · · Score: 1

      The 'original UNIX' was a mess compared to what?

      Before multics nobody had a fucking clue about security.

      --
      Watch this Heartland Institute video
    6. Re:The best bug is the one not written by BarbaraHudson · · Score: 1
      Compared to its predecessor, Multics, from which it drew inspiration. Unix was a mess:

      We went to lunch afterward, and I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"

      Still happens ...

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    7. Re:The best bug is the one not written by Eunuchswear · · Score: 1

      Which says nothing about security.

      --
      Watch this Heartland Institute video
    8. Re: The best bug is the one not written by Anonymous Coward · · Score: 0

      Making the system unavailable with a specific input, is one of the "CIA" things you need to protect against.

      Crappy code that can't be effectively maintained, is insecure. That was in fact, the problem with OpenSSL and heartbleed.

    9. Re: The best bug is the one not written by FormOfActionBanana · · Score: 1

      mod parent up, damn. The things people say around here.

      --
      Take off every 'sig' !!
    10. Re:The best bug is the one not written by BarbaraHudson · · Score: 1

      A machine that crashes and has to be booted because of bad OS code is doing a denial-of-service attack on itself. How does that not affect overall security and the integrity of your data?

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    11. Re:The best bug is the one not written by Eunuchswear · · Score: 1

      Firstly, Multics, while good, was only different from Unix in degree, not kind. Multics also included a panic routine and would call it when it was unable to continue.

      HODIE NATUS EST RADICI FRATER ring any bells? (Just one example).

      Secondly, have you been using any Multics systems lately? I wonder why not.

      Thirdly, which meaning of "security" are you using today? You seem to be chopping and changing.

      --
      Watch this Heartland Institute video
  2. Linux was better when there was little funding. by Anonymous Coward · · Score: 4, Interesting

    I've been using Linux for an awfully long time, since the mid 1990s (Yggdrasil, then Debian). Over time, as Linux has gotten more and funding, it has gotten worse and worse. I initially switched to Linux because it generally just worked, and it worked better than many of the alternatives. But now it's just getting fucking horrible. I mean, look at systemd. Normal users, and especially power users, don't want it. It just causes problem after problem for many people. Yet we have corporate interests and corporate-funded developers forcing it on us, even forcing it into community-oriented distros like Debian. GNOME and Firefox are other great examples of community-based open source projects that got co-opted by money and ruined, to the most recent versions of both being almost totally unusable. On the other hand, we see projects that get less commercial interest, like Slackware and Xfce, producing the most usable and reliable open source software systems around. Linux was better when there wasn't so much money floating around. Back then it was about creating great software, and doing things right. Now it's about everything but that.

    1. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 0, Flamebait

      Linux doesn't have "power users", it has programmers. Programmers recognize that systemd is doing the Right Thing. Sysadmins who think their entire job is to write shell scripts don't like systemd because they might have to update their skills. We get it: you're stuck in the 90s. I'm sure it was a good time for you. Please keep using your old software that's broken just the way you like it.

      A hobby OS is one that forces you to script its internals. Linux needs a system which allows it to track processes and resources accurately, rather than just double-forking and hoping that the pidfile will be accurate when you need that service again. What you're saying is, "I don't understand why people think systemd is necessary." If you had any intellectual honesty that would be your cue to research exactly why people think systemd is necessary. Instead you've come to nostalgize about some golden time of Linux, that never was. If you don't like the direction things are going, please leave, and don't let the door hit you on the way out.

    2. Re:Linux was better when there was little funding. by BarbaraHudson · · Score: 4, Insightful

      As Heinlein noted, TANSTAAFL, just like there's no such thing as free beer. Everything has a cost. Even free software.

      And when you have such a fragmented ecosystem, the attack surface is going to be huge (after all, an OS is more than just a kernel), and the idea that "with enough eyes all bugs are shallow" is patently false. So it turns out that open source has been to a large extent relying on the same "security through obscurity" model. This was fine a decade ago, but the competition have stepped up their game and can afford to throw money and bodies at the job without begging.

      The solution would be to do a code freeze for 2-3 years while the developers of the various projects audit their code and the ways other projects interact with their code - not just for security problems, but to get rid of bloat and cruft. That's not going to happen, because it makes too much sense. Everyone wants the newest shiny.

      Linux was definitely better when there were fewer distros. What a mess.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    3. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 0

      Switch to one of the BSDs, problem solved. OpenBSD and DragonflyBSD have security and elegant design as their primary goals. Linux is good, but always remember - the people who give the most money are the ones who make the most decisions. Linus, by and large is irrelevant nowadays. He doesn't have as much real power over Linux as people seem to think.

    4. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 0, Troll

      You have no idea what you're talking about. Please read about cgroups. If you like what you read, feel free write it into the BSD of your choice. Systemd does not break compatibility, the kernel does. Not only that, it does it to fix a very specific and very important problem, namely, that tracking processes by means of scripts and pidfiles is fundamentally flawed. It's not even the first time that someone has tried to fix this, it's just the project with the biggest uptake in Linux so far.

      Complaining about compatibility is just ignorant. The most charitable interpretation is that you're saying that Linux developers should not use Linux-specific features. Otherwise you're making some sort of statement about what features different kernels should have, and in either case, good luck with that.

      In any case, it has nothing to do with control; your argument rests on a false premise. If you want compatibility with Linux, write equivalent features for the BSD kernel.

    5. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 1

      As a programmer, I find systemd horrible. It breaks compatibility with Unix.

      Even the old GNU programs have largely broken UNIX compatibility a long time ago.

    6. Re:Linux was better when there was little funding. by phantomfive · · Score: 3, Informative

      Yet we have corporate interests and corporate-funded developers forcing it on us, even forcing it into community-oriented distros like Debian.

      Debian adopted systemd for reasons outlined here. It wasn't a conspiracy. Poettering knew that distros are crucial to the adoption of systemD, so he's made things as easy as possible for them, and given them features they wanted. Essentially systemd makes it easier to write an init script, and since Debian writes a lot of them, they liked that.

      Of course, Poettering has been less responsive to other parties (like the kernel devs), but that's another topic.

      --
      "First they came for the slanderers and i said nothing."
    7. Re:Linux was better when there was little funding. by BarbaraHudson · · Score: 2

      As a programmer, I find systemd horrible. It breaks compatibility with Unix. It's a nightmare that will shrink the open source landscape to just linux. The rest of us must now reinvent basics like toolkits, web browsers, etc because Linux zealots want to take over the world.

      Or you could just bang around on this.

      Pre-emptive multitasking with 1000hz scheduler, multiprocessor, multithreading, ring-3 protection
      Responsive GUI with resolutions up to 1920x1080, 16 million colours
      Free-form, transparent and skinnable application windows, drag'n drop
      SMP multiprocessor support with currently up to 8 cpus
      IDE: Editor/Assembler for applications
      USB 2.0 HiSpeed Classes: Storage, Printer, Webcam Video and TV/Radio support
      USB 1.1 Keyboard and Mouse support
      TCP/IP stack with Loopback & Ethernet drivers
      Email/ftp/http/chess clients and ftp/mp3/http servers
      Hard real-time data fetch
      Fits on a single floppy, boots also from CD and USB drives

      Since the blurb was writtten, browser, digital tv, webcam, movies, etc. have been added.

      Or you can play around with Plan9 - runs by itself or as an application atop linux, windows, etc.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    8. Re:Linux was better when there was little funding. by serviscope_minor · · Score: 1

      As Heinlein noted, TANSTAAFL, just like there's no such thing as free beer. Everything has a cost. Even free software.

      Free software is free as in beer. If you claim it's not free because of the time to put in, then $100 lying on the pavement in front of you isn't free because you have to take the time t ogo and bend down and pick it up. Making such claims is basically changing the definition of the word "free" to mean something other than what it actually means.

      Linux is Free as in Beer because you can get it for no cost.

      And as for a free lunch, well, I think he was mistaken. I remember switching to Linux in the late 90s. For what I was doing, it was better in ever aspect than what I was switching from and free as in both speech and beer.

      and the idea that "with enough eyes all bugs are shallow" is patently false.

      It never meant there will be no bugs, it meant that once observed the bugs will be shallow and therefore fixed easily. Heartbleed is a perfect example of the many eyes thing: it was fixed within hours. Deep bugs are hard to fix, and shallow ones are easy to fix. The meaning of the quote was all about fixability, not nonexistence.

      The solution would be to do a code freeze for 2-3 years while the developers of the various projects audit their code and the ways other projects interact with their code - not just for security problems, but to get rid of bloat and cruft. That's not going to happen, because it makes too much sense. Everyone wants the newest shiny.

      If you want that, then OpenBSD is read and waiting for you :)

      --
      SJW n. One who posts facts.
    9. Re:Linux was better when there was little funding. by Skiron · · Score: 2

      " like Slackware and Xfce, producing the most usable and reliable open source software systems around." Well said - exactly what I use (even Slackware on my Raspberry Pi's).

    10. Re:Linux was better when there was little funding. by BarbaraHudson · · Score: 1

      TANSTAAFB either.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    11. Re:Linux was better when there was little funding. by dkf · · Score: 1

      I've been using Linux for an awfully long time, since the mid 1990s (Yggdrasil, then Debian).

      Darn noobs! I remember having fun making the MCC Interim distribution work...

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    12. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 0, Interesting

      Could not agree more. Linux has been a stable environment for years, and whenever a problem has occured, one could usually have solved it with a little log investigation and at least with googling arounf. But since systemd appeared, now one gets a non bootable system every few weeks, and the logs really do not help at all. So this time the the systemd decided that a NFS mount in fstab is not a supported thing to have anymore? Fuck me sideways, a red larson scanner for 90s at startup is now a thing to convert me for supporting your crap? I am really convinced that Redhat introduced systemd just to sell more support hours for Linux.

    13. Re:Linux was better when there was little funding. by walterbyrd · · Score: 1

      Sadly, the BSDs tend have hardware compatibility issues.

      They are great for servers - better than Linux, IMO. But for desktops, and laptops, I don't know if I could recommend a BSD.

    14. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 0

      Systemd is really cool. Power user here :P Just read "systemd for Administrators" and you will understand why they changed all the stuff.

    15. Re:Linux was better when there was little funding. by tlhIngan · · Score: 3, Insightful

      Over time, as Linux has gotten more and funding, it has gotten worse and worse. I initially switched to Linux because it generally just worked, and it worked better than many of the alternatives. But now it's just getting fucking horrible. I mean, look at systemd. Normal users, and especially power users, don't want it. It just causes problem after problem for many people.

      No, it hasn't gotten worse. It has gotten responsive to user demands.

      Back in the 90s when life was simple, users were simple. Unless you used an Amiga or MacOS, if you played a sound, that was it - no one else could play a sound (MacOS and Amiga had software mixers so you could listen to music AND hear application generated sounds - you could use exclusive mode if you needed it, though).

      Likewise, you logged in and you rarely had things starting up just for you.

      And your networking options were... single. You either had Ethernet, or a modem, and only one IP per host. And rarely did you move - I mean, if you were on Ethernet, it was assumed you were on the same network permanently, or at least changes were rare.

      Nowadays, user demands have gone way up. Audio has to be mixed by the OS because the user may listen to tunes, start yakking on VoIP, and having sound effects played while gaming, all simultaneously. The VoIP call goes over say, a Bluetooth headset or the communications path, while the music and sound effects play through the main speakers. Oh, and no application is to dare use the HDMI port to send audio as it's hooked to a monitor with no speakers. A modern PC can easily have 4 or 5 different ways to play audio.

      Likewise, when you log in, you probably have a few per-user services you like to have - either from the environment you're using or other services. It would be a shame if logging in again restarted those services (e.g., you log in locally, then log in remotely over ssh) or if those multiple sessions couldn't communicate with each other (e.g., you make a change remotely, and it fails to propagate through the rest of the logins).

      And networks... well, an Ethernet port or WiFi? A user may connect to many different networks in a single day, and have more than a few ways to send a packet around. Perhaps they're hooked to their same network multiple ways - either dual Ethernet, or Ethernet plus WiFi. And maybe the next time the connection is re-established, those ports need to be firewalled because it went from private network to public.

      Back in the old days, well, audio was simple because your PC couldn't really do multiple things at once. Networks were generally safe so it didn't matter that you didn't bring up the firewall on the public Ethernet connection. And users didn't run too many things in the background because no one could imagine needing to log into the console AND over ssh simultaneously, or they could just remotely kill the session because there wasn't important stuff to save.

      And it's perfectly fine on a server that sits in a rack and never moves until it's powered down and retired. But modern users need this complexity just to manage their normal use case. Sure you can force the user to tell you what kind of network is at the other end, or to re-establish the VPN, but users want computers to do stuff automatically - I mean, why should I tell the computer this coffeeshop WiFi is public over and over again - can't it remember?

      Or to reconfigure my VoiIP app because I attach my Bluetooth headset to my computer so it now uses that - why can't it ask for a communications headset, and if one isn't available right now, use the default audio hardware. Then when one suddenly appears (Bluetooth!), automagically use that? Zero reconfiguration, event he app doesn't have to reopen the audio device because the audio core did it internally.

      It should be telling that the most popular Linux "distribution" in the world is Android, which has its own init system (like systemd, it manages processes, events, and other things), its own audio

    16. Re:Linux was better when there was little funding. by ezdiy · · Score: 1

      Systemd does not break compatibility, the kernel does.

      jimmie status=triggered

    17. Re:Linux was better when there was little funding. by Zero__Kelvin · · Score: 1

      You have a serious reading comprehension problem.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    18. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 0

      It's the same sort of mentality that drives new development over maintenance in the startup industry. I think it's probably tied to the idea that new projects and young projects are unencumbered by red tape and process. Instead we see a lot of crackerjack programmers in that industry frantically spewing out brand new projects that have no air of quality about them. They're literally brainfarts held together with some trust-fund money and their notion of security, or even the end-user, is woeful. These enterprises don't exist to create customers, they exist to create an ego for some 24yr old wanna-be-CEO. The kind of CEO that still wants to write code I might add.

      The landscape of technologies and languages is really a landscape of egos. Every programming language is bolstered by some larger-than-life narcissist whose only intention is to be the defacto standard. Wouldn't you like to be able to make the statement "My programming language runs all software in the world!"...think of the ego stroking you could derive from that. The downside of competition is that short of producing a "best", it just produces a long line of barely adequates. The cost of determining what is "best" gets handed off as an arbitrary decision for some programmer somewhere. Every programmer has a "favorite", although these are definitely not "best" and perhaps not even "locally best". Choosing a base technology is an arbitrary decision, and a critical one that every project in the world faces at some time. That line of me-toos gets longer until no-one has the faintest clue what "best" is anymore, or even how to measure anything. Arbitrary, arbitrary, arbitrary. Not computer science.

    19. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 0

      The right thing is to swallow many error messages and the ones they don't stuff into a binary file?

      The right thing is to have 25 executables all dependent on each other? Might as well be 1 giant executable.

      The right thing is to have user land apps depend on systemd?

      The right thing is to have a init system with its own networking?

      The right thing would be if you were aborted along with your ass buddy Poettering.

    20. Re:Linux was better when there was little funding. by phoenix_rizzen · · Score: 1

      Unless you used an Amiga or MacOS, if you played a sound, that was it - no one else could play a sound (MacOS and Amiga had software mixers so you could listen to music AND hear application generated sounds - you could use exclusive mode if you needed it, though).

      FreeBSD 4.x, also from the 90s, allowed you to play multiple sounds simultaneously. It used the same OSS code that Linux used ... but they enhanced it to support features Linux never did. Unfortunately, Linux devs continuted with their NIH syndrome and came up with ALSA as a fix for this non-issue. Even that didn't do all the things OSS did on FreeBSD, and eventually led to the development of the horrid PulseAudio (why fix the foundation when we can just paper over top). Other than a few network- and BlueTooth-related things, PA still doesn't work as nicely/smoothly as OSS on FreeBSD.

      Fixing "exclusive sound" issues on Linux shouldn't have required a 10+ year commitment; but nobody wanted to fix OSS-on-Linux.

      And your networking options were... single. You either had Ethernet, or a modem, and only one IP per host. And rarely did you move - I mean, if you were on Ethernet, it was assumed you were on the same network permanently, or at least changes were rare.

      Been running wireless on laptops since the days of the Orinoco Silver and Orinoco Gold PCMCIA cards (aka before 802.11b). Windows 9x and FreeBSD never had issues with them. Plug the card in, dhclient runs, you have Internet access. Remove the card, connect the Ethernet cable, dhclient runs, and you have Internet access. Moving between networks would (rightly so) drop running connections, but everything worked. It did require a bit of manual configuration for the wireless side of things, but that was all in a single configuration file and easy to manage. And it got even easier in the early 802.11g days with the advent of wpa_supplicant.conf

      Again, Linux devs and their NIH syndrome saw them go through multiple different wireless stacks, multiple different ways to configure things, and things were a mess! Each wireless driver included its own wireless networking stack, for pete's sake. And what you configured to work with one driver wouldn't work with the next. There was no centralised configuration file for wireless on Linux, although Debian got close with their wpa_supplicant extensions to /etc/network/interfaces. Once things were working nicely on Linux, the desktop devs came down with their own case of NIH and had to wrest control of wireless from the CLI guys, coming up with NetworkManager. And then WiCD. And a bunch of other alternatives to them. Now you couldn't configure wireless (or any networking) until after you logged into the GUI! (Unless you jumped through some hoops. Eventually, that was fixed.)

      Users haven't gotten more complicated; nor have use-cases. But Linux desktop developers have certainly developed more complex cases of NIH and are constantly re-writing everything "just because", thus overly-complicating things. Things are not better now than they were 15 years ago on the Linux desktop. Especially not compared to other OSes out there. Even the other F/OSS OSes.

    21. Re:Linux was better when there was little funding. by Anonymous Coward · · Score: 0

      Linus has 100% say over what goes into the mainline branch.

  3. Whose Eyes? by Capt.Albatross · · Score: 4, Insightful

    Even for non-security bugs, the many-eyes hypothesis contains a large dose of wishful thinking, but at least in that case most eyes are looking with the same purpose. When it comes to security, however, it is a race between black-hat and white-hat eyes, and the former only have to win once.

    1. Re:Whose Eyes? by thieh · · Score: 2

      The problem with many-eyes hypothesis is that not everyone looks for the security bugs and not everyone is capable of looking for every kind of bug. Everyone will notice a problem when the UI behaves differently. Not many of us will notice when the command-line utility did something subtly different (especially when it comes to RNG, like the Debian OpenSSL bug back in 2008) without abnormal output.

    2. Re:Whose Eyes? by swillden · · Score: 2

      Even for non-security bugs, the many-eyes hypothesis contains a large dose of wishful thinking

      Not true; Torvalds' observation wasn't what he wished would happen, it what what he'd observed repeatedly on a large and complex project over the period of many years.

      That said, I think your disagreement is because, like many, you misunderstand the hypothesis. What Torvalds said wasn't that given enough eyes all bugs are visible, but that they're shallow, meaning easy to track down and fix. The hypothesis doesn't even come into play until the existence of the bug is known.

      And, undoubtedly, there are some bugs that are deep no matter how many eyes are looking at it, so the hypothesis isn't literally true in all cases. But it is true in nearly all cases, as Torvalds has been in an excellent position to see.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    3. Re:Whose Eyes? by Your.Master · · Score: 3, Informative

      Torvald's didn't say the "many eyes" thing at all. Eric S. Raymond did.

    4. Re:Whose Eyes? by swillden · · Score: 1

      Torvald's didn't say the "many eyes" thing at all. Eric S. Raymond did.

      Really? Wow. I've had that attribution wrong for years. Thanks.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Whose Eyes? by FormOfActionBanana · · Score: 1

      Yeah, WTF?

      --
      Take off every 'sig' !!
    6. Re:Whose Eyes? by Capt.Albatross · · Score: 1

      The [many-eyes] hypothesis doesn't even come into play until the existence of the bug is known.

      If that is so, then it doesn't help much with security, where finding exploitable bugs (and doing so before they are exploited) is usually the hard part.

    7. Re:Whose Eyes? by swillden · · Score: 1

      The [many-eyes] hypothesis doesn't even come into play until the existence of the bug is known.

      If that is so, then it doesn't help much with security, where finding exploitable bugs (and doing so before they are exploited) is usually the hard part.

      Precisely. It's not that the hypothesis is wrong, it's just that it doesn't apply.

      This doesn't reduce the value of open source for security software, because while it gives both white hats and black hats a great deal of help with finding vulnerabilities, the nature of security research means that the white hat side benefits more. Open source software, developed in public, also makes it more difficult for the likes of the NSA to insert back doors, because it's not just a matter of paying (or threatening) some company to insert the compromise. That's not to say it can't be done. I'm quite certain it is done. But it's harder, and it's more likely to be discovered and removed.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    8. Re:Whose Eyes? by phantomfive · · Score: 1

      It comes from this article, which if you haven't seen, you might enjoy reading.

      --
      "First they came for the slanderers and i said nothing."
    9. Re:Whose Eyes? by swillden · · Score: 1

      It comes from this article, which if you haven't seen, you might enjoy reading.

      Thanks. I actually read The Cathedral & The Bazaar shortly after ESR published it, and have read it several times since. I'm really not sure how the "many eyes" notion got associated with Torvalds in my head.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  4. Shallow, WTF by rossdee · · Score: 1

    Bugs can be made shallow?

    On Linux, bugs are only skin deep

    Why have bugs at all?

    1. Re:Shallow, WTF by BarbaraHudson · · Score: 1

      Bugs can be made shallow?

      Sure. Just put on your cockroach-killer shoes (you know, the ones with the pointy toes to get 'em in the corners) and start stomping.

      Unfortunately, you can't eliminate programmer errors the same way.

      (programmer errors are not "bugs". they didn't mysteriously creep into the code on their own when nobody was looking. saying "it's a bug" is just a way to avoid responsibility for a mistake, and leads to both a slack attitude and a feeling of non-responsibility).

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  5. Second Linus Law: Curse the bugs out by JoeyRox · · Score: 3, Funny

    Maybe Linus isn't cursing at the developers with enough frequency or intensity?

    1. Re:Second Linus Law: Curse the bugs out by Anonymous Coward · · Score: 0

      He is geting soft in his old age.

    2. Re:Second Linus Law: Curse the bugs out by Kjella · · Score: 3, Insightful

      Maybe Linus isn't cursing at the developers with enough frequency or intensity?

      It seems the kernel is rarely the problem, so I'd say the amount of cursing is just right. The problem is Linus doesn't run all these other projects.

      --
      Live today, because you never know what tomorrow brings
  6. Oblig by Anonymous Coward · · Score: 0

    How much to get rid of systemd?

  7. the solution is to fund projects...? by Anonymous Coward · · Score: 0

    No, the best solution is to simplify the software. And the REALLY best solution is to teach respect from infancy onward. The general computing machine cannot be made 'secure'. It is impossible. It will never know a USB disk from a disguised keyboard issuing commands. Throwing money around is chasing ghosts and just corrupts the process. All your 'free' software will be as bloated as the worst from Microsoft. Sorry, like with all power and money, you must confront the desire, and not the objects of that desire. Until then, nothing is going to change.

  8. Re:Mutual Exclusion by Anonymous Coward · · Score: 0

    Well said. A lot of people use open source exactly because it does not cost anything. On the other hand, software is getting so complex that it's increasingly hard to be created just by volunteers working for free. This creates a dilemma.

  9. Red Hat by Anonymous Coward · · Score: 0

    They have the moneies and the talent to do this....to bad they are trying to kill Linux with systemD. :(

    1. Re:Red Hat by kthreadd · · Score: 0, Troll

      If by by "kill" mean "improve" then yes.

    2. Re:Red Hat by F.Ultra · · Score: 0

      +1

  10. Re-engineer the OS to include ROMs? by Redfearn · · Score: 2

    Is there a way to re-engineer operating systems so that some parts are strictly read-only (like, baked in ROM chips); other parts difficult to change (flash them?), and so on? Right now, it seems all data, programs and operating system components are equally vulnerable to writes by viruses. How many people would be harmed if some basic components of XP had been burned into ROM? Then anti-virus programs could hook into those "fortified" modules to maitain or restore the integrity of other parts.

    1. Re:Re-engineer the OS to include ROMs? by Anonymous Coward · · Score: 0

      Is there a way to re-engineer operating systems so that some parts are strictly read-only (like, baked in ROM chips)

      That's not how this works. That's not how any of this works.

      I unfriend you.

    2. Re:Re-engineer the OS to include ROMs? by Anonymous Coward · · Score: 0

      Why not?

    3. Re:Re-engineer the OS to include ROMs? by war4peace · · Score: 1

      This has been tried with DRM. I remember those game CDs coming with bad sectors intentionally written to make copying difficult, and software products which came with a specially crafted parallel port dongle to add hardware protection.
      None worked.

      The solution you're proposing makes life more difficult only to regular users who would need to order chips and slam them into a motherboard to upgrade their operating system. Not to mention a bug which would creep into the read-only part of the OS. At least now you can patch it, if it were a chip you would need to physically replace it and in the meantime just pray you don't fall victim to the malware written for that bug.

      --
      ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
    4. Re:Re-engineer the OS to include ROMs? by Anonymous Coward · · Score: 0

      To be simplistic, anything that can be done by code, can be undone by code.

      Because real ROM is only writable once, so the OS would need to be burned onto chips on the motherboard and could never be patched or updated. You could not switch OS's with your hardware, and could never completely upgrade. Apple hardware had some of this in the 80s and the 90s as a piracy prevention technique. The only real possible option is a physical mechanism (like ultraviolet erasable roms), but this would make upgrades, patches and OS switches onerous.

      Anything else is creating a virtual ROM with something that is not ROM (Flash, RAM, disk), and since there needs to be a way to decide whether the visualization is opaque or transparent (to allow writing for upgrades, but prevent writing for viruses), there will always be the chance that (1) there is a way for something to bypass the protection when it should not be allowed to or (2) flaws in the code that uses the protection that invalidate the protection.

    5. Re:Re-engineer the OS to include ROMs? by phantomfive · · Score: 1

      How many people would be harmed if some basic components of XP had been burned into ROM?

      Everyone who had one, because they would be found to have security vulnerabilities (see here for an example of exactly that happening), and then everyone's system would be vulnerable.

      Incidentally, Kaspersky was building an OS that does exactly what you suggest, so if it works, then maybe we will see more of what you suggested in the future. I'm doubtful though, for reasons mentioned in the previous paragraph.

      --
      "First they came for the slanderers and i said nothing."
    6. Re:Re-engineer the OS to include ROMs? by Ramze · · Score: 1

      Intriguing suggestion, but perhaps based on a false premise that "data, programs and operating system components are equally vulnerable to writes by viruses." That's most certainly not the case even on a Windows platform. System files and folders usually require an admin to modify, and drivers and other OS components typically must be signed drivers to update. On "trusted computing platforms", there's even more security on what can even boot on the machine. A virus should only have privileges based upon the user that allowed the infection (who should not be admin or root for daily tasks) or an elevation if it found a flaw to escalate privileges. This is part of why OS X and Linux rarely have viruses, but Android and Windows with their lax security have more than their fair share. (And I say this even though I have many Windows machines along with a Nexus 7 running Android).

      A better solution would be for XP to have had better security levels (User/Power User/ Admin were great as a start, but EVERYONE had to be an admin just to add a printer, sync their phone, random stupid task, etc.) Windows 7 and 8 are much better about this... and even an Admin isn't really full Admin - still has popups to verify and you must take ownership of some files in order to modify them, etc. A better question would be - how many viruses would have been prevented if people logged in as USERS instead of Admins for their everyday tasks?

      I have this fancy Read Only Compact Disk with Linux on it... and another with a version of Windows. I also have them on bootable USB flash drives. One even has a persistent install - so there's the compressed image plus changes and other installed software on another area of the drive. They're basically what I boot into when I think a system is infected to try to repair/clean them with various antivirus tools and system cleaners. Your proposal is not without merit - as obviously I use these read-only or difficult-to-modify entire OSes to clean such infections.

      I'm just not sure what issue your proposal would resolve, and how you'd expect to implement it. It's not a bad idea in principle, but I'm not sure how you'd pick and choose which bits to be read-only and which to be re-writable.... and I'm not sure why a virus couldn't simply modify the code to ignore your read-only memory and point to it's virus-ridden duplicates instead?

      Some viruses infect boot loaders, so you could write a BIOS/EUFI that uses "trusted computing" and point a windows startup to a ROM.. maybe even one with crypto keys that will allow the next 10 or 20 updates of various windows files (signed/hashed kernels, etc) to load on startup and nothing else. The more you make read-only, the more you obsolete your system. You might even be baking bugs into the system that can't be removed through updates! As for flash memory, I know of viruses that have infected the flash memory on ethernet cards and sound cards. I don't know if you want to have parts of the OS in imbedded chips that could be tampered with or become permanently infected with the wrong virus.

      Even if you could somehow protect the primary OS from corruption through this method (unlikely - it's more likely to freeze bugs in place for future exploits), you'd still be open to running viruses - even if the virus is wiped by a simple reboot. Some viruses only take 1 run to do their damage. One virus I know simply scanned the system for media files and deleted any .jpg, .jpeg, .mp3 files. It could run in userland as a script from double clicking on a malformed file attachment (like a pdf). Once it runs, it's damage is done. Only a file restore utility or a backup could undo it. Others run, but infect programs rather than the OS. So, MS Outlook gets infected - virus spams your contacts, they get infected, and so on. There's just too many kinds of viruses and worms to protect against them all by this method.

      I think maybe a system restore, a virus scanner, or mayb

    7. Re: Re-engineer the OS to include ROMs? by Anonymous Coward · · Score: 0

      Use Linux live cd

    8. Re:Re-engineer the OS to include ROMs? by rubycodez · · Score: 1

      that's some of the idea behind http://en.wikipedia.org/wiki/W...

      OpenBSD does this even for kernel with x86-64

    9. Re:Re-engineer the OS to include ROMs? by Anonymous Coward · · Score: 0

      Is there a way to re-engineer operating systems so that some parts are strictly read-only (like, baked in ROM chips); other parts difficult to change (flash them?), and so on? Right now, it seems all data, programs and operating system components are equally vulnerable to writes by viruses. How many people would be harmed if some basic components of XP had been burned into ROM? Then anti-virus programs could hook into those "fortified" modules to maitain or restore the integrity of other parts.

      Yeah, there's a system like that that was designed where all OS and application binaries would be cryptographically signed and nothing would run unless explicitly authorized by the user. It would have been super secure. It's called Palladium and the TPM.

      The freetards, being what they are, screamed bloody murder of course and stalled adoption but they'll come around eventually once enough Linux boxes get pwned.

  11. Re:Mutual Exclusion by Anonymous Coward · · Score: 0

    A lot of the decent Open Source software are now productized with a combination of extra management tools, capabilities, and support.

    Probably for the vast majority of them their #1 competition as products is their own "free $$" version.

  12. totally wrong solution by Anonymous Coward · · Score: 0

    The right solution is not to support irresponsible projects like OpenSSL, instead projects like libressl should be supported instead. in fact i'm going to go donate some cash to openbsd now to rebel against this article.

  13. Open Source grows up by Anonymous Coward · · Score: 0

    Hippies everywhere learn that nothing is free.

  14. Modern software... by frank_adrian314159 · · Score: 1

    Modern software security is hard because modern software is complex.

    Doesn't that just about say it all? More eyes don't solve complexity issues, only more brains and better architecture.

    --
    That is all.
    1. Re:Modern software... by Kjella · · Score: 2

      Doesn't that just about say it all? More eyes don't solve complexity issues, only more brains and better architecture.

      I think that if you do some research - at least if you limit yourself to human subjects - you will find there's a strong correlation between number of eyes and number of brains so "more eyes" implies "more brains". And if you can settle the age-old discussing of whether encapsulation, abstractions and design patterns reduce or increase complexity you should the IT Peace Prize.

      --
      Live today, because you never know what tomorrow brings
  15. Too late... by QuietLagoon · · Score: 1
    Once the bugs are in released code, it is too late to remove them efficiently.

    .
    Maybe a more cost-efficient approach to spending the Foundation's money would be to determine how and why the bugs get into the code in the first place, and reduce their occurrence as early in the development cycle as possible.

    The earlier in the development cycle a bug is eliminated, the cheaper it is to eliminate the bug.

    1. Re:Too late... by Kjella · · Score: 2

      By the time something becomes "core infrastructure", it's usually not in a condition where a rewrite is at all advisable. You have an existing code base that's seen lots of real world usage and presumably works well most of the time, what you need is testing, cleanup, sanity-checking, error handling and formal verification that it performs as intended. And it's particularly important that you review obscure functionality like the heartbeat TLS extension that lead to the heartbleed bug, that you put many eyes were few have wandered before.

      Of course if you find that something's genuinely missing, like a layer to prevent SQL injection and just depending on every piece of code doing the "right thing" that might be a reason to re-architect, but I think your advice is far more applicable to new development than the projects were talking about here. For example there's nothing wrong with the heartbeat spec, it's fine. It's the implementation that was fatally flawed and the only way you can catch that is reviewing the code.

      --
      Live today, because you never know what tomorrow brings
  16. Come on. by Anonymous Coward · · Score: 0

    Funding is the issue? So what is Microsoft's, Apple's, Adobe's, and Autodesk's excuse for selling buggy products? You will always have bugs in software this is why I'm always getting updates that patches bugs and fixing security holes on my Windows 7 platform and for applications. The only reason why i'm not on linux or bsd is because the software that i use such as productivity suits and games are not available otherwise i would switch.

    If people don't like systemd then switch to another distro, create your own distro, or switch to BSD which runs pretty much all linux software.

  17. Acorn did exactly this by Anonymous Coward · · Score: 0

    RiscOS resided in ROM. If you have something suitably small, say QNX, and/or a suitably large flashROM, you could conceivably flash the OS, then move the flash-write-protect jumper, and you're golden. So yes, you could conceivably have this.

    Instead the peecee industry came up with "UEFI SecureBoot", which tries something with keys (effectively in the hands of redmond, not coincidentally) that is being sold as a security improvement but in reality is about control, and this isn't the first time: Paladium/TCPA comes to mind. So if you'd want something useful to happen, it's going to be up to the tinkerers again. And, perchance, that too we can make happen.

    You could perhaps see if the CoreBOOT project isn't dead yet, and join up, or help revive it, or something to that tune.

  18. ooooo by daveime · · Score: 1

    > The solution is to fund projects that need help

    But then it's not FOSS anymore? How will they resolve this massive ethical dilemma?

  19. Education by Anonymous Coward · · Score: 0

    How about you pay infosec people to review your code? How about you educate programmers, so that they learn how to properly write secure code, how to avoid mistakes, how to use fuzzers, compiler plugins and specialized software for security reviews, ...? That way, the "many eyes" would actually help, but not because they are programmers... but they are programmers that know about security.

  20. Oh, you mean like companies that hire programmers by Anonymous Coward · · Score: 0

    Software companies do this sort of development all the time... they hire developers and have those developers work on problems which they might not work on for free otherwise.

    I do think open source software can have advantages over completely closed efforts. But this does separate some of the free and open mystique out of open source software... that it is the cure for all closed source problems and that it somehow defies economics that apply to other areas of life.

    At the end of the day: programmers have lives and those lives have a cost to maintain... they ignore that at their own peril. Those that have money to fund this sort of thing will want their money focused on specific problems or issues, that's good and right and the nature of a trade. It's also very much like a regular corporate entity that hires programmers to build software for them.

  21. Who has billions and exploits open source? by Anonymous Coward · · Score: 0

    Okay, so who has billions of dollars and exploits open source to build walled gardens and make more billions? Maybe they should start by putting up some money.

  22. Fund systemd? So redhat makes more billions? by walterbyrd · · Score: 1

    Tempting offer, but I think I'll pass.

  23. Good testing takes more than 50% of time and res by postmortem · · Score: 1

    There is a way to properly test software. But it is insanely expensive. Real mission critical software (like airborne systems) has standards for code verification that are pretty tough. For example per standard DO-178B, required is complete structural coverage analysis; object code analysis; worst case throughput analysis; stack analysis, etc.

    There's no way that volunteer programs can find funding for this or human resources to do this. Although many companies do contribute to various open source programs, the level of testing required to remove most of bugs is extremely costly. Who's going to pay for software to be nearly perfect, if it is not required of it? Truth it, pretty much nobody outside mission critical software does this kind of testing.

  24. How 1969 to 1973 by Anonymous Coward · · Score: 0

    Eyes finding security bugs in software. If only compilers could somehow detect egregious security bugs automatically.

    1. Re:How 1969 to 1973 by FormOfActionBanana · · Score: 1

      Well, finally today they do. LLVM is good for catching unsafe casts and such, which can hide buffer overflows.

      --
      Take off every 'sig' !!
    2. Re:How 1969 to 1973 by Zero__Kelvin · · Score: 1

      How do you expect a compiler to figure out that the asymmetrical public key cryptography package you wrote has a security flaw because you implemented an algorithm improperly? Do you really think compilers can understand what code is doing at the systems level?

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  25. Trying to play "security guru" wannabe? by Anonymous Coward · · Score: 0

    See subject: Odd you ran 7x then eh bigshot http://slashdot.org/comments.p... vs. "lil' ole' me" (who made you EAT YOUR WORDS easily)?

    APK

    P.S.=> You started this http://yro.slashdot.org/commen... with me, trolling/harassing/attempting & failing @ "mocking" me, & I am simply going to PUBLICLY HUMILIATE YOUR TROLLING WANNABE ASS with ease (especially by giving you a dose of your OWN medicine, whimp) & by "osmosis" GOOGLE along with you too - bring your PhD's in here from Google - I WILL HAND THEM THEIR ASSES just like I have yours, easily, on the topic of hosts (especially vs. ALMOST ALL ADS BLOCKED WHOM YOU'VE PAID OFF TO NOT DO ITS JOB RIGHT BY DEFAULT)... apk

    1. Re:Trying to play "security guru" wannabe? by swillden · · Score: 1

      I missed you, man. What happened, anyway? Why did you disappear?

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    2. Re:Trying to play "security guru" wannabe? by Anonymous Coward · · Score: 0

      From what I've read you trolled and you ate your words for it.

    3. Re:Trying to play "security guru" wannabe? by swillden · · Score: 1

      No reason to leave me hanging. I expect you to respond to EVERY post I make. Don't slack!

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:Trying to play "security guru" wannabe? by Anonymous Coward · · Score: 0

      You hung yourself repeatedly here swillden http://slashdot.org/comments.p...

  26. Payoff by GOOGLE by Anonymous Coward · · Score: 0

    "Open source software, developed in public, also makes it more difficult for the likes of the NSA to insert back doors, because it's not just a matter of paying (or threatening) some company to insert the compromise. That's not to say it can't be done. I'm quite certain it is done. - by swillden (191260) on Sunday February 22, 2015 @12:11PM (#49105921) Homepage

    It's certain Google pays Adblock to compromise it ("souled-out" 2 Google/Crippled by default http://techcrunch.com/2013/07/... & ABP too http://finance.yahoo.com/news/... )

    APK

  27. Re:Mutual Exclusion by Anonymous Coward · · Score: 0

    You do realize that ~88% of the Linux kernel devs get paid to work on the kernel don't you?

  28. conculsion based on a myth by johncandale · · Score: 1

    undermined the confidence many had in high quality of open source

    protip: only naive college-level awareness fanboys thought that. Everyone else was aware of the illusion of security in Linux and knew it was mostly through obscurity that it was not the victim of attacks. It's not just a lot of eyeballs btw, but the right eyeballs. And reviewing shipped code for security is usually the last thing foss people spend their time on.