Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Open Source Security Software IT

Open Source Code Isn't a Warranty (opensource.com) 214

An anonymous reader writes: Automotive software issues such as the Jeep hack and Volkswagen cheating on emissions tests have made headlines this year, which means the public is thinking about software in cars like never before. Some experts have argued that mandating that such software be open source is a solution to the problem. In an article on Opensource.com, Ben Cotton writes that although there are definite benefits to public scrutiny of the software, code visibility alone is no guarantee. It's an important thing to bear in mind, because "Open, therefore secure" is an easy straw man to knock down.
This discussion has been archived. No new comments can be posted.

Open Source Code Isn't a Warranty

Comments Filter:
  • Guarantee (Score:4, Insightful)

    by KatchooNJ ( 173554 ) <<Katchoo716> <at> <gmail.com>> on Tuesday October 27, 2015 @11:49AM (#50810439) Homepage

    I think the better word choice is "guarantee" instead of "warranty" for the headline.

    • Re:Guarantee (Score:5, Insightful)

      by ShanghaiBill ( 739463 ) on Tuesday October 27, 2015 @12:10PM (#50810633)

      I think the better word choice is "guarantee" instead of "warranty" for the headline.

      Also, "visible source" would be better than "open source". Unless they actually mean that anyone should be able to copy, modify, fork, and redistribute.

    • Re: (Score:3, Interesting)

      But it allows you to create guarantee because you can audit it.

      For closed source software, you have to trust the supplier and their guarantee.

      Do you trust yourself or your proprietary software vendor more? It can be a hard choice in some situations.

      • Re:Guarantee (Score:4, Insightful)

        by Capt.Albatross ( 1301561 ) on Tuesday October 27, 2015 @12:29PM (#50810827)

        Do you trust yourself or your proprietary software vendor more? It can be a hard choice in some situations.

        It's a Hobson's choice for me, as I don't have the time or resources to verify the software of my car, let alone those that I rent.

        • Re:Guarantee (Score:4, Insightful)

          by ShanghaiBill ( 739463 ) on Tuesday October 27, 2015 @01:25PM (#50811335)

          I don't have the time or resources to verify the software of my car

          I don't have the time or resources to replace a bad head gasket in my car. But I am not going to buy a car with the hood welded shut.

          • Re:Guarantee (Score:5, Insightful)

            by Capt.Albatross ( 1301561 ) on Tuesday October 27, 2015 @01:49PM (#50811535)

            I don't have the time or resources to verify the software of my car

            I don't have the time or resources to replace a bad head gasket in my car. But I am not going to buy a car with the hood welded shut.

            Many of the things you use are welded shut - integrated circuits, for example.

          • I don't have the time or resources to replace a bad head gasket in my car. But I am not going to buy a car with the hood welded shut.

            What's the difference? If you don't have the time or resources to replace it then it's not going to get replaced. Generally most people don't have the time, but do have the resources to get engine parts replaced.

        • But you don't have to though as long as one other person does it and reports the results. I don't have time to fix bugs in a lot of the open source software that I use, but someone else does and I get the benefits of that at no cost to myself, and if I make any contributions, someone else can benefit from my work as well.

          There's probably someone with either enough time on their hands or the predilection towards such things that they would do an audit and more than likely you'd get a small handful of peop
          • None of this matters unless it is actually happening to a significant extent. I could be persuaded by statistical evidence, but not by wishful thinking, no matter how often it is repeated.

            • If you don't think that Open Source software have bugs fixed by people all over the world right now "to a significant extent" you must be living in denial. Granted it does not happen to 100% of all projects but if a product is running FLOSS you can be sure to a big percentage that there is some one else hacking it.
              • by KGIII ( 973947 )

                A study, not that long ago, said something like 98% of all open source projects get abandoned in ____ amount of time. I forget how long. I'm not sure that you can say that a "big percentage" has someone else hacking it. It's quite a stretch to do so. This may be true for popular software but that's actually not the majority of open source software.

                And no, I'm a Linux user. A registered Linux user actually. I'm just not a zealot and am inclined to try to be honest. It's the internet, you can do that here.

              • The fact that bugs are found and fixed in open-source code does not allow you to conclude that open-sourcing will improve bug discovery to any significant extent. That is the issue where wishful thinking is being substituted for evidence.
                   

                • Where do you think companies such as Coverty finds source code to improve their scanners, it's probably not in closed software.
            • "significant extent."

              Define "significant". If someone makes a patch which I apply to MY CAR, that is significant, to me.

              And, because I applied the patch, my car DOES NOT accelerate uncontrollably, or veer off the road, or catch fire and blow up, or turn into a Decepticon in your children's school zone, it's pretty significant to you as well.

        • by TheCarp ( 96830 )

          yes but, as long as some number of people are willing and interested enough, which for something as widely used as a car, you can expect will be the case (even if it wasn't open, people would be hacking on it), then it works anyway.

          Though, in no way are you really protected, its not like "bugs" can't be engineered and well obfuscated.

          Oh gee look, some odd data corruption when this register overflows and.....oh quite odd there.

      • But it allows you to create guarantee because you can audit it.

        Only if you compile it yourself and have the actually ability to audit the software. (and you have a compiler you trust)

        For closed source software, you have to trust the supplier and their guarantee.

        This is true of most open source software as well with the exceptions mentioned above. If Mozilla provided a warranty for firefox, I have no actual ability to audit their software and even if I did, such an audit would be meaningless unless I compiled the software myself. For any non-trivial piece of open source software, this means that functionally there is little difference between t

        • by orasio ( 188021 )

          That's proof by lack of will, or imagination.

          Open source means that you, or an army of people like you, can get it audited, somehow.
          For example, you can set up a kickstarter for it and pay someone you trust.
          You might also have the competition look at cheats.
          Your government can also audit the source, if it's important enough.

          People do have power, it takes a lot of getting together with others and stuff, but a lot more is possible than what you can do personally.

          • by Holi ( 250190 )
            >Your government can also audit the source, if it's important enough

            Your government can do that regardless of whether or not the software is open or not.
            • by orasio ( 188021 )

              My government can't.
              My government _could_ do it or pay someone to do it, if the code was open.

      • by AmiMoJo ( 196126 )

        Head over the XDA Developers, where people mod phone firmware for fun. Note the number of wannabe coders who rant about how stupid Google is and how Android is complete crap without their mods and "fixes". Have a look at some of the scripts and apps they have written.

        Very, very few people are qualified to write embedded software for cars, and fewer still to audit it and understand what is safe and why things are done the way they are done. We really, really don't want random people screwing with their car's

      • by mwvdlee ( 775178 )

        What guarantee do you have that your cars runs the code you were allowed to see?

        • What guarantee do you have that your cars runs the code you were allowed to see?

          All the consumer safety lawyers willing to make themselves rich by suing car companies.

          After a serious accident, if the car company cannot reproduce the binary from the published code, they are going to be forking over a lot of money.

    • For the VW incident. having the code open probably wouldn't do much, as it is just the settings/input file which would cause the damage.
      Your code could be perfect and still used for evil.

      • by mwvdlee ( 775178 )

        That file would be considered source code as well.

        • by KGIII ( 973947 )

          A generic .config is usually in the source but that often gets edited and is not included in the source. Why would it be included in this source?

          • by mwvdlee ( 775178 )

            A generic config file is something that is supposed to be tailored to the individual end-user. In the case you describe it would be a static file that would be identical for each installation of the code. How is that any different from a very specialized domain-specific programming language?

            • by KGIII ( 973947 )

              They don't use the code across multiple vehicles with different configurations and settings?

              • by mwvdlee ( 775178 )

                They sure can. But the settings files for the individual vehicles will be identical accross all cars of the same model.
                It's kinda like translations; you're only using one set of them, but they're still considered part of the code.
                Otherwise, please explain why programming language IS source code and some more specialized and limited language (what these files are) ISN'T source code.

                • I would probably draw the line on if the config file contains something the equivalent of an IF statement.
                  Where using the config file will define the order and decision making based on previous inputs.

                  That would include #ifdef style commands.
                  However if it is just a table...
                  Default = 50
                  60 kph = 40

                  While it may perform critical roll in the decision process it isn't changing the logic just the thresholds.

                • by KGIII ( 973947 )

                  Why? Oh, just 'cause they'd use it to hide it still. But it doesn't seem *likely* that the settings file (the .config) will be identical across vehicles. Sometimes you even get a generic config that you'd change yourself to suit the environment variables. They could easily say, "Well, there's the source code." They'd be accurate, I guess. I'm kind of thinking along the lines of, say, a PHP script with manual installation.

    • Since when did any software, open or otherwise, come with a warranty or guarantee of any kind?

      Software licenses are notorious for claiming practically nothing about the effectiveness of the software they cover. Typically they're full of legalese that goes to great length at how the software is offered with no warranty of any kind, not even an implied warranty or merchantability (whatever that means) or fitness for any particular purpose, blah blah blah.

  • However.. (Score:4, Interesting)

    by Anonymous Coward on Tuesday October 27, 2015 @11:57AM (#50810515)

    The more insight into code, the less likely companies will do what VW did because its open to public scrutiny. I think we should be focusing on the "Open, therefore open to scrutiny" than the misconception of "Open, therefore secure".

  • by gQuigs ( 913879 ) on Tuesday October 27, 2015 @12:00PM (#50810537) Homepage

    or maybe...

    Open, therefore not illegal to review?

  • A straw man attack consists of refuting an argument which no one is making. It is not a generic term for false arguments. "Open, therefore secure" may be false, but it is not a straw man.

    OTOH, since no one is making the case that open source is secure by default, the last line does look like a straw man. (But it's not really.)

  • -1 Stupid (Score:2, Insightful)

    by Grishnakh ( 216268 )

    This software absolutely should be open-source. The OpenSSL issue is an example of why open source is superior, even though it's obviously no guarantee you'll have no problems: when the vulnerability was discovered, it was fixed very quickly.

    The problem with proprietary software is that there's no way to actually fix it, unless the vendor wants to. When the OpenSSL problem was found, a fix was made and rolled out, and everyone was able to install it.

    When a vulnerability is found on your 5-year-old Jeep an

    • Jeep releases vehicle with buggy software.

      Buggy software comprises 10 million lines of code (the estimate of the size of the offending VW code).

      Years down the road, after extensive analysis, white hat posts new and improved software to Git.

      ????

      At issue here is how does a third party hack get distributed to end users?

      Further, car makers really don't like it when you chip your car. Last year, I got a warranty notice for my A3 TDI saying my car needed new software to fix part of the emissions control system (h

    • it's equally important that you can actually get the fix *onto* the device

      Don't even get me started on how I can't flash vanilla Android onto the Samsung Galaxy S4 that I own because they locked down the bootloader. Moved onto a Nexus device and will never give my money to Samsung as long as they continue with that shit.

    • The OpenSSL issue is an example of why open source is superior, even though it's obviously no guarantee you'll have no problems: when the vulnerability was discovered, it was fixed very quickly.

      I think the OpenSSL issue is an example of exactly the opposite. It was a text book example of an open source project that had convoluted and complicated code that actively disincentives anyone to look at the code and thus allow code to go without review and bugs unseen. The idea was that all bugs are shallow yet Heartbleed and Shellshock have both shown some bugs that have stayed with the system despite repeated modifications to the source code and presumably people reading and working with it for many yea

      • Open source is superior only in that it provides an ability to do a code review. Clearly that has failed spectacularly in some of our most common and most depended upon open source components.

        Huh? I never said OS was perfect; far from it in fact. It's also no guarantee that people are actually going to audit it. I don't understand why people keep thinking this. But if you think proprietary software is of higher quality on average, you're deluded. There's crap code in both camps.

  • ...but it admits to the possibilities that a) an enterprising white hat (or black hat) CAN inspect the code for integrity, logical structure, and fitness for purpose, and b) if a black hat can (or could, or does) exploit the code, a white hat can improve the code to close that security breach. Closed Source limits the potential white hats to those the intellectual property owner chooses...and they have little economic incentive to choose well or comprehensively, or ask for expensive comprehensive inspectio

    • by Bert64 ( 520050 )

      And blackhats frequently do have illegal access to closed source code, putting whitehats (and every other user) at a significant disadvantage.

  • Duh... (Score:5, Insightful)

    by gweihir ( 88907 ) on Tuesday October 27, 2015 @12:15PM (#50810681)

    Another stupid comment by people that do not understand the difference between a "necessary condition" and a "sufficient condition".

    Open-sourcing the software/firmware in question is a necessary thing. That means it must be done. It is not a sufficient condition. That means it is not enough. It still must be done, but other things must be done in addition to get the desired outcome.

    It is almost as if people do not understand basic logic anymore. No surprise so many things in the IT space get screwed up badly these days.

    • Open-sourcing the software/firmware in question is a necessary thing. That means it must be done. It is not a sufficient condition.

      I love open source, and I think the default approach for much software should be open, but it's neither necessary nor sufficient. The insufficiency is clear, at least in the short term. With regard to necessity, there are lots of other options. Here are a few:

      1. The vendor could be held liable for any and all security breaches and reliability problems due to their software. That is, they could be required to provide warranties/guarantees, and to be bonded to ensure that they can't skip out of payment by f

      • by gweihir ( 88907 )

        While these approaches all sound nice in theory, they are unworkable or mostly worthless in practice for the type of software under discussion here.

        I have done such audits. You get 5 days to review 1000 lines of badly structured and undocumented code. In the end you conclude "no obvious backdoors or vulnerabilities", the vendor is off the hook and the code still sucks. And point 4? Until people doing the code are actually paid wages that attract those that can do it, forget it. Methodologies are vastly over

        • I have done such audits. You get 5 days to review 1000 lines of badly structured and undocumented code.

          Then you haven't done the audits I'm talking about. I have, and I've had my code audited. It takes many weeks, includes the active participation of the developers and is very thorough.

          • by gweihir ( 88907 )

            I have. But that type is not within the financial means of most projects, hence the meaningless ElCheapo version.

  • Open source vehicle code isn't about preventing vulnerabilities, it's about allowing owners to fix issues that the manufacturer does not fix. In the US an auto manufacturer is only required to perform recalls for 10 years after the initial sale of a vehicle. There are plenty of well maintained vehicles over 10 years old but if a new vulnerability were discovered in the software then the owner would have no way to get it fixed. If the software were open source then it would likely be fixed by someone other t
  • When we considered open source in the vehicle 15 years ago, the lawyers clobbered it as they company likes putting the supplier on the hook for recalls.

    In any case, the company is responsible for defects in the open source. You cannot wave away the rights of anyone you plow into, regardless of the cleverness of any disclaimers.

  • What warranty do the Closed Source companies give to the users of the software?
  • It's not THE solution all by itself, but open source is an essential part of the solution.

    A GPL-v3 style anti-tivoization clause is necessary too, otherwise you can't verify that the published source is actually what is running on the device.

  • Obviously, a machine code binary is a form of open source, just not a very useful one. The most open state of a software project is when any outside contributor has exactly same access to knowledge as founder/CEO, including personal one on one attention from key developers. This is impractical in practice. The best we can hope for is that all machine-readable materials are equally available to all contributors.

  • and then we get into the discussion that the source provided might not be the same as what is actually running in your ECU.
    who's going to check those things?

"Open the pod bay doors, HAL." -- Dave Bowman, 2001

Working...