back to article Securing open-source code isn't going to be cheap

Open-source software has always been more secure than proprietary software, but that doesn't mean it's "secure." To lock it down, we need to invest serious cash in developers and maintainers. You may have noticed that a lot of people are getting seriously cranky about open-source software security lately. They have a reason. …

  1. Charlie Clark Silver badge

    It's not an open source problem

    Everyone is bad at security in software; it doesn't matter whether its open or closed source. And some things can't be solved easily because security is difficult™. Something that is considered secure today might be considered insecure tomorrow because someone discovers a new kind of attack.

    But the major problem is misaligned incentives: no software maker is under real pressure to fix bugs because they are largely exempt from liability. It's fashionable to bang on about flaws in open source libraries but what about last year's clusterfuck that was Hafnium? If Exchange came with strict liability then Microsoft might well have been bankrupted by claims. Instead, it continues to make record profits.

    Oh, companies do love freeloading: last week I got an e-mail from a company wanting to know whether one of my libraries was subject to US export restrictions! Yeah, like I'm going to spend unpaid time or effort on any kind of indemnification!

    1. Throatwarbler Mangrove Silver badge
      Alert

      Re: It's not an open source problem

      "And some things can't be solved easily because security is difficult™."

      Whoa, whoa, whoa, hold your horses there, son. I have it on good authority from various commenters here that any competent IT organization can nail security with no problem, so if your systems get hacked or you get afflicted with ransomware, it is solely the fault of IT for not having bulletproof systems.

      1. Cederic Silver badge

        Re: It's not an open source problem

        Ah, we can, we're just told we're not allowed to.

        All I have to do is lift the Mollyguard and hit the big red button and all our systems become instantly secure.

    2. Anonymous Coward
      Boffin

      Re: It's not an open source problem - you forgot only

      Security is both a closed source and an open source problem.

      As the article points out, programmers, closed and open source, rank security at the bottom, just ahead of documentation. Their goal is an implemented working program with security and documentation to follow.

      Reviewing old code for unknown security vulnerabilities requires paid eyes.

      1. DJV Silver badge

        Re: It's not an open source problem - you forgot only

        Ummm... his title and first sentence were stating exactly that!

        1. Anonymous Coward
          Anonymous Coward

          Re: It's not an open source problem - you forgot only

          Security is very easy if you want to trade usability.

          I used to use a computer system that was very secure, the terminals were inside a metal room and the screens turned off if the door opened.

          The connection to the actual computer was a fibre, so no electronic eavesdropping.

          The computer itself was in an underground concrete room with some gentlemen with machine guns who discouraged visitors. No paperwork or media went on or off site.

          The only application was the OS, even the Fortran compiler ran on a front end machine and the programs got transferred on tape to the big machine.

          I doubt that Cray/OS even had an antivirus.

          1. chuBb.

            Re: It's not an open source problem - you forgot only

            If your trading usability for security your doing it wrong and probably making it less secure as people will actively subvert the security to make their lives easier, old chestnut of very secure building rendered moot by security being so onerous that fire escape gets blocked open to facilitate fag breaks

            Tis human nature to be efficient (read as lazy) and exploit any advantage for personal gain

            1. Hawkeye Pierce

              Re: It's not an open source problem - you forgot only

              I have to strongly disagree with your opening statement.

              Just about any form of security hampers usability almost by definition. Security is something that gets in your way of doing something by making you prove who you are before letting you do that thing.

              As such every there is ALWAYS a trade-off between security and usability and as such there is no one level of security that is appropriate for everything. It depends on your analysis of the risks and the level of inconvenience/security you deem appropriate.

              Logging in to The Register to post a message could be made more secure by implementing 2FA for example. But there's a usability trade-off there is to whether that is appropriate.

              1. Roland6 Silver badge

                Re: It's not an open source problem - you forgot only

                >Just about any form of security hampers usability almost by definition.

                The problem isn't so much 'security' aka locks etc. but more about code robustness.

                Buffer overflow et al aren't security breeches in the traditional sense, they largely arise because of coding practices.

                However, I would agree whilst Rust produces more 'secure' code than C, it lacks the usability of C, the only question is whether the (lost) usability of C is important in the context of what you are coding.

              2. chuBb.

                Re: It's not an open source problem - you forgot only

                Depends on your definition of usability.

                From your reply I take your definition of usability to mean convenience

                Is http more usable than https because it has one char less?

                Are stairs more usable than escalators?

                So no I don't equate security as a trade off in usability, convenience certainly, if security prevents the activity intended (the use) then yes it would effect usability

              3. DevOpsTimothyC

                Re: It's not an open source problem - you forgot only

                Just about any form of security hampers usability almost by definition. Security is something that gets in your way of doing something by making you prove who you are before letting you do that thing.

                As such every there is ALWAYS a trade-off between security and usability and as such there is no one level of security that is appropriate for everything. It depends on your analysis of the risks and the level of inconvenience/security you deem appropriate.

                That's why we have things like single sign on.

                I'd argue that it's ALOT easier for me to sign on once in the morning and then my access flows from there rather than having to sign on to random sites (some using http) through the day.

                I've seen corporates which have had the "strong" password requirements (8 characters long, atleast 1 each of uppercase, lowercase, numeric and special, that needed to be changed every 3 months and not be the same for the last 3 passwords), but then have 5 or 6 internal websites on http which required your domain credentials to be re-entered to use. And of course for security the cookie time had to be short so if you spent 10 mins without interacting with the site you had to re-enter all those details.

                Security has to be practical. There is no point in spending £5K on a lock for a £200 bicycle.

          2. Fred Daggy Silver badge

            Re: It's not an open source problem - you forgot only

            I always commented that complexity is the enemy of security. If something is too onerous, people will search for simper solutions. If its too hard to write ones own code, correctly, at sufficient speed, simpler solutions will be use (eg, use someone else's code) - for example.

            Getting security right is hard. And right means it is simple enough any moron, or manager can use it. Without resorting to work-arounds.

      2. Yet Another Anonymous coward Silver badge

        Re: It's not an open source problem - you forgot only

        >Security is both a closed source and an open source problem.

        Although the open source, I'll just pull in random library to do X rather than write something = because it's free, might lead to a bunch more vulnerabilities.

        1. AdamWill

          Re: It's not an open source problem - you forgot only

          I mean, it's not really *that* simple. Random Developer X "just writing something" is pretty likely to "just write something" with security vulnerabilities.

          Shared code on the whole, in the long run, when done properly, tends to *decrease* security issues. If we didn't have widely-used SSL libraries we'd certainly have more code with security vulnerabilities due to bad home-grown SSL implementations.

          If you're thinking about things like leftpad, well, there's a few other factors in play there, like Javascript not having a standard library. Languages with sensible standard libraries are less subject to the problem of projects either constantly needing to reinvent the wheel, or needing to pull in tons of dependencies for fairly trivial operations.

          1. Yet Another Anonymous coward Silver badge

            Re: It's not an open source problem - you forgot only

            Yes the open source may be better quality than mine but it is likely to also pull in other libraries with other functionality.

            I might write a logging library that isn't safe against printing unsanitized strings, but I'm unlikely to accidentally implement remote procedure call functionality from scratch

        2. Anonymous Coward
          Anonymous Coward

          Re: It's not an open source problem - you forgot only

          https://xkcd.com/2347/

    3. chuBb.

      Re: It's not an open source problem

      It's not so much a skills problem or even a project management deadline meeting corner cutting exercise. They are both symptoms however. Security is a philosophy (and possibly a religion based on reactions I've had to debates on the subject).

      Much like critical thinking (hate the term, but I guess credulity needs to be taught given the obsession education has with learning without understanding), security needs to be instilled from a young age, the value of your data, how to protect your data, leading to question how data will be used, personal security (cover pin pad, avoid shoulder surfing, trust nothing that's emailed etc.) with a foundation of that any one who ends up writing systems will have a better understanding than most in the industry who grew up with computers then the Internet being a bit of a frivolous novelty; which is certainly reflected in current legislation and lack of consequence , if any of the major vendors made cars they would spend more time being recalled for public safety concerns than on the road...

      Throwing money at the problem would grease the wheels of change but will do little to aid the uptake of a different way of thinking.

  2. VoiceOfTruth Silver badge

    Keep on spreading this nonsense...

    'Open-source software has always been more secure than proprietary software'

    Let's make some big sweeping generalisations, shall we? Here's my experience of > 30 years in computing. 99% of users do not look at any source code whatsoever, they are end users. That is fine and I have no problem with that. The 'open source' world is not so different. The fact that source code is available does not mean that is being read. The 'given enough eyeballs all bugs are shallow' mantra is just a slogan. Firstly, reading source code takes time. Secondly, reading other people's source code is often boring. Thirdly, those reading the source code need to understand what the programs do and and what they are meant to do. Fourthly, with each step of this short list the number of competent programmers and source code reviewers gets less and less. This 'problem' is even more obvious when it comes to anything to do with cryptography - you need programmers who understand mathematics. The question becomes not just is the programming correct, is the mathematics correct?

    In the Linux fanboys attempts to woo Windows/Mac users to Linux (GNU/Linux, you pedants), they repeat the same mantra that I opened this comment with. As such, the average ability of Linux users has decreased substantially from where they were 20 years ago. Who remembers rebuilding a RedHat kernel in 1999? Or installing Debian at all? The fact that you could install Debian was almost a sign of competency. If you add another 20 million very basic computer users to Linux, almost none of them is competent enough to find and fix a bug in source code. Their average level is 'how awesome is my desktop background!'.

    The general thrust of the article is correct, but let's leave the generalisations to one side unless you can back them up (as I did).

    1. mpi Silver badge

      Re: Keep on spreading this nonsense...

      Which situation is better:

      a) The code is open source, so the potential for public scrutiny exists (whether or not this potential is used is a different question). If a bug is found, many people will be able to suggest fixes, or even implement fixes prior to an official release. If a bug isn't fixed, the project can be forked. If a bug isn't fixed for some prior version, people can backport it.

      b) The code is closed source. Everyone has to trust some company to check it for security loopholes. If a bug is found, many people won't even be aware until it is fixed, the company is the only one who can fix it, and until it is released people have to use some workaround (usually "turn XYZ off") (if there is one). If the bug isn't fixed, projects relying on the software have to be redesigned to use something else. If the bug isn't fixed for some prior version, no one can backport it.

      A or B?

      1. Charlie Clark Silver badge

        Re: Keep on spreading this nonsense...

        What if B comes with a support contract but A doesn't? That would make B preferable for many users.

        I'm all in favour of open source but it's not a solution in itself.

      2. VoiceOfTruth Silver badge

        Re: Keep on spreading this nonsense...

        'the potential for public scrutiny exists'

        'The potential' is a meaningless concept, and I do wish that people would stop spreading this nonsense. It's like saying there is the potential for rain tomorrow. Well so what? Look how much potential there was for checking Log4j. Your comment is much like the GNU/Linux fanboys' comments 'supported by the community' patter. Well about 1% of the Linux community is actually able to actually search for bugs in source code. 99% can make some new cranky desktop pictures and submit them to some theme web sites.

        There is so much nonsense in the Linux 'community' that it makes me sick. Here's an introductory lesson to programming 'Hello World' in C/C++/Python/Go/Rust/etc. Congratulations, now you too can submit kernel patches.

        1. mpi Silver badge

          Re: Keep on spreading this nonsense...

          > 'The potential' is a meaningless concept

          The potential for rain is the difference between a farm eventuelly being able to grow crops and one that can never grow a crop.

          1. Charlie Clark Silver badge

            Re: Keep on spreading this nonsense...

            That's a poor analogy. It's more like being able to fix some farm machinery because you have the manuals. That sounds great, but without the right tools and understanding of how the machinery works, the potential may never be fulfilled.

            And, to give the thing some perspective: back in the day AT&T, IBM, et al. did use to provide manuals for all their mainframes, because if something did go wrong you were expected to be able to fix it yourself. At least with IBM this continued well into the PC era, which is why, if you paid, you could get the relevant manuals to look up those error messages that would occasionally pop up in OS/2.

            1. Ian Johnston Silver badge

              Re: Keep on spreading this nonsense...

              And, to give the thing some perspective: back in the day AT&T, IBM, et al. did use to provide manuals for all their mainframes, because if something did go wrong you were expected to be able to fix it yourself.

              I once discovered a fun bug in VAX/VMS: you could set a password with spaces in it but you couldn't ever change it thereafter. I remember the system manager pulling down a source code listing of the operating system (written in SNOBOL, iirc) so he could make changes to allow me to update my expired but unchangeable password.

              1. Bitsminer Silver badge

                Re: Keep on spreading this nonsense...

                It was written in BLISS32, not SNOBOL.

                They distributed (most of) the source code for VAX/VMS on microfiche. It was a stack of 4x6 film sheets about an inch thick.

                I spent many a day squinting at a 'fiche reader screen (fully analog!) to reverse-engineer the account number field in the user authorization file (UAF). And how to set it, via assembler. And how to avoid crashing the machine (we only had one 11/780 for 100-plus people so experiments had to be very carefully managed and timed.)

                In the Good Old Days.

                1. Ian Johnston Silver badge

                  Re: Keep on spreading this nonsense...

                  It was written in BLISS32, not SNOBOL.

                  Thanks for the correction. It was a long time ago!

              2. scubaal

                Re: Keep on spreading this nonsense...

                HaHa thats *still* a problem with some current websites.

                Supercheap auto just updated their website to only accept complex passwords = good thing

                but they set the same validation on old password = bad thing

                So the 'change my password' wont work because it wont accept the old password at the validation prompt - despite happily accepting that password for login.

                I tried for over 3 months to explain the problem and get someone to take notice. There is no mechanism to contact anyone with technical responsibility. It still aint fixed.

                I guess there are no new bugs - just new ways to implement them.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: Keep on spreading this nonsense...

                  NAB changed their website to accept long passwords a few years ago. The previous site would also "accept" long passwords, but apparently only used the first 8 characters & discarded the rest. On changeover, they had to advise anyone with a password longer than 8 characters, to only use the first 8.

          2. midgepad

            The concept is far from meaningless, but it means ...

            Availability of source code doesn't ensure that it is read or understood or corrected.

            But...

            Availability ensures that faults cannot* be denied, ignored, or kept unfixed.

            All of those occur with closed source not because of its inferior philosophical nature, but because companies misbehave. There may be no programmer to hand. The direction and marketing may prefer to sell faulty software than to spend money fixing and reissuing it, the (new) management may not understand, believe, or care...

            That's a quality worth having, but not automatic salvation.

            * short of your copy of the compiler being dishonest as is theirs. Scary compiler attacks.

            1. Anonymous Coward
              Anonymous Coward

              "ensures that faults cannot* be denied, ignored, or kept unfixed."

              Feel free to look at the bug tracker of any open source project. Lots of bugs kept unfixed, because noone is fixing them. There are not only security bugs that require immediate attention for the extensive damage they can done.

              1. werdsmith Silver badge

                Re: "ensures that faults cannot* be denied, ignored, or kept unfixed."

                You can’t say that about the sacred cow.

              2. mpi Silver badge

                Re: "ensures that faults cannot* be denied, ignored, or kept unfixed."

                The thing is, in open source projects, we CAN look at the bug tracker.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: "ensures that faults cannot* be denied, ignored, or kept unfixed."

                  I can look at bug trackers of closed source projects as well. It's not that you can't give your customers a bug tracker if your project is not open source.

            2. JohnTill123

              Re: The concept is far from meaningless, but it means ...

              With reference to your last note: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

      3. Snake Silver badge

        Re: A or B?

        See, you missed the OP's point entirely: NEITHER is better than the other, the failings inherent in the design exists in both systems.

        A closed-source system with 10,000 programmers will be better than an open-source system with only 200 active programming participants - just because one is labeled "open" doesn't mean anything if the vast majority of actual users never look, or understand, the source code.

        1. Anonymous Coward
          Anonymous Coward

          Re: A or B?

          @Snake.

          I have upvoted you because I think you have raised an important point.

          I run paid for software because if I have a problem, I can ring someone up and get it sorted.

          I also think it is wrong to use "free, (it never is free)" to earn money.

          But your last point is the most important. The vast majority of free software users don't give a damn as long as it is free. Look at the hell that was raised when "Audacity" was bought by a company. What was the biggest reaction? "Someone will port it" That should really have read "someone, anyone but me, will port it then I can download it and use it for free".

          "Many eyes" really means someone else's eyes.

          1. Ian Johnston Silver badge

            Re: A or B?

            In the case of Audacity it's not the purchase but the purchasers who cause concern. Who in their right minds would enter into a financial relationship with a Russian company.

            1. Roland6 Silver badge

              Re: A or B?

              I'd be a little less divisive; we've yet to see the full effects of Trump's legacy, where many (outside of the USA) are now reconsidering relationships with US companies...

      4. david1024

        Re: Keep on spreading this nonsense...

        When anyone is responsible... Noone is.

      5. Ian Johnston Silver badge

        Re: Keep on spreading this nonsense...

        False dichotomy time. Open source also means that Bad People can look for weaknesses to exploit. And unlike most users, they have a financial incentive to do so.

        1. Charlie Clark Silver badge

          Re: Keep on spreading this nonsense...

          Whether code is open or closed source matters little when it comes to finding exploits. While can find some standard vectors (SQL injection, poor hashing, etc.) with some static analysis, it's usually easier to run the various toolkits against the executable.

          You can look at the change logs for open source for clues, the same goes for release notes or CVE notices. But the really nasty stuff tends to comes from labs where there are lots of eyeballs paid to look for, but not report, exploits.

      6. Roland6 Silver badge

        Re: Keep on spreading this nonsense...

        It's not 'if' but 'when' a bug is found.

        Rust attempts to prevent obvious bugs, but it too can't protect from intentional coding decisions/'errors' such as those at the heart of Y2K.

      7. Anonymous Coward
        Anonymous Coward

        Re: Keep on spreading this nonsense...

        Fine in theory, but the big problem in open source is where tens/hundreds/thousands of projects blindly trust and pull in dependencies without reviewing them, which in turn pull in dependencies, which in turn...

        Any one of these common dependencies having a flaw affects a huge number of projects. Example, log4j.

        https://xkcd.com/2347/

    2. heyrick Silver badge

      Re: Keep on spreading this nonsense...

      "The fact that source code is available does not mean that is being read."

      Of course, however if something a person creates is out there in the world available to be read and tagged with their name as the contributor, I'm pretty sure that many will attempt to create fairly sane code. After all, a potential employer might be the eyeballs that read the code.

      As opposed to something where the source is not available where there's no pride incentive, just the need to make something that compiles and does what the spec says, as quickly as possible.

      I've dipped into some code that was previously closed. Some has been great. Some has been a complete shitshow (single letter variables, logic structures that defy belief, and in one case comments that seemed to pertain to an entirely different program).

      For these reasons, I believe that an open source coder will be more likely to use commands like strncpy instead of strcpy and hoping it fits. Because they may be judged on that code. With closed source, it's only their peers who are ever likely to look...

      1. Snake Silver badge

        Re: pride incentive

        @hayrick:

        "As opposed to something where the source is not available where there's no pride incentive, just the need to make something that compiles and does what the spec says, as quickly as possible."

        Are you actually going to take a stand and declare that there are NO programmers for hire, with published work, who takes pride in their code?!

        I am very, very sure that hundreds of thousands of for-pay code jockeys will take large exception to that.

        1. midgepad

          Demonstrating their pride: incentive

          Not my area, but you can't usually show off how good the code you wrote for company A when you look for a job with company B, can you?

          Unless it is open source, of course!

          So, there's some potential incentive to have a chunk of good code done well which you can show specific individuals.

          And if there have been other people jn the project picking out infelicities for you, it may make you look even better.

          1. Snake Silver badge

            Re: showing your code

            "Not my area, but you can't usually show off how good the code you wrote for company A when you look for a job with company B, can you?"

            Sure you can. They know your current employer, you just need to mention what projects you were responsible for. They'll test you no matter what prior proof you provide, regardless.

        2. Charlie Clark Silver badge

          Re: pride incentive

          Very true. But there is also undeniably a problem with some of the larger corporations as staff and teams are moved around with fewer and fewer people in a position to understand the codebase. This is certainly the case with MS Office.

        3. heyrick Silver badge

          Re: pride incentive

          "and declare that there are NO programmers for hire, with published work, who takes pride in their code?!"

          Just like everything else in life, there's no black and white, so kindly don't put words into my mouth. I'm simply pointing out that knowing others (and others that you don't necessity know) can review your code (again without you necessarily knowing) could well be an incentive to do better.

          Additionally, those who work with closed source are more likely to work for a commercial company whose marketing promised a product last week, management wants to know why it isn't ready, and it's hardly an environment conducive to doing better.

          That's not to say there isn't lovely commercial code and shitty open source, of course. I'm just pointing out the obvious (to me) psychological differences between the two methods.

      2. An_Old_Dog Silver badge

        pride of code != good or readable code

        The most horrible assembly language code I've read was open source. It was written by a possibly-genius math Phd, and was for one of the transcendental math functions. The ONLY comment was at the beginning. It read, "All constants copyright (C) 1983 by" [name-of-author].

        The most beautiful assembly language code I've ever read was open source. The header comments told you everything you needed to know.

        Just because a person can write effective and functional code does not mean they will write READABLE code, pride of workmanship notwithstanding.

    3. Snake Silver badge

      Re: Keep on spreading this nonsense...

      Yes! Finally! Someone [else] speaking the unwelcome truth of the conditions of FOSS.

      "Who remembers rebuilding a RedHat kernel in 1999?"

      I do. Still have the diskettes. And the entire experience taught me that, for me at least, the promotion of Linux was more about the journey than about your solution. Far too many Linux aficionados promote Linux because they are convinced that the technology of their affection is superior, not because Linux will actually "solve" any problems you may be experiencing. They fixate on the OS layer and then expect you to adapt whatever workflow you are currently using to that singular focus, regardless of how YOU, as an individual, actually function.

      As you said, they've talked about "eyes on the code" for decades now. Yet here we are, 2022, and security issues are popping up in much-used coding. So the "eyes" didn't bother to actually both look...and understand. Users are users, programmers are programmers, and it's both incredibly, well, arrogant and naive to expect everyday users to become proficient in programming simply because they adopt a particular operating system. That's not their job.

      'Security is not taught in schools'

      This isn't 1999. We aren't using a single-core, 400mHz Pentium Ii with 512MB RAM.

      This is 2022. Pretty much every enthusiast is on a minimum of a hyperthreaded quad-core. 8GB RAM is the new normal, with most enthusiasts going up to 16-32GB, and content creators often going up to 64+. 500GB of fast storage space, now SSD, is considered a pleasant minimum.

      Depending upon your humans to remember every point of design failure, every possible weakness, is QUAINT. We are all sitting in front of what would have been considered mainframe power when Linux first introduced yet we expect the programmers to operate under the 1990's paradigms.

      Protections should be baked into the systems from the start. Rust is the future but we have many programmers butting heads under the dual beliefs that ' Real programmers don't need help!' and 'Code elegance and efficiency is all!'. Your code isn't "efficient" if that great-looking design, the one you concerned yourself about the 3ms saved in that loop, is compromised and 3 million user's data gets out. The stakes are much higher in today's computer world than they ever were.

      1. VoiceOfTruth Silver badge

        Re: Keep on spreading this nonsense...

        'Far too many Linux aficionados promote Linux because they are convinced that the technology of their affection is superior'

        Indeed. I guess my point in a nutshell is that 99% of the Linux fanboys are themselves not competent to judge that Linux is superior - they have neither looked at any of the source code and are not competent to look. Instead they are following a mantra. Having an awesome desktop picture does not make a great UNIX/Linux user.

      2. Ian Johnston Silver badge

        Re: Keep on spreading this nonsense...

        The first Linux I tried to install was Mandrake (or Mandriva) around 2000 ish, when it was clear that OS/2 and eComStation were not going to keep me going forever. The OS/2 boot loader, which also had a copy of Windows for work, had to be chained with Lilo. In theory not too difficult but in practice something in the Linux installed scribbled all over the disk's MBR, which was a tad annoying.

        So I posted to uk.comp.os.linux to ask if anyone had seen this before and could help. Although I did get some good advice ("You're screwed. Reinstall everything.") about three or four posters lambasted me for days, telling me that what I claimed to see was impossible, that I was clearly a Microsoft (sorry, "Micro$oft") shill and so on and so on.

        All good fun, I imagine, but it didn't give an impression of Linux as more than a hobby for the perpetually conspiracy bound. So I waited until Ubuntu 6.06 came out and discovered that it installed flawlessly first time, alongside OS/2 and have been running Ubuntu or Xubuntu on everything since.

        Moral~ ;You catch more flies with honey than vinegar.

        1. anothercynic Silver badge

          Re: Keep on spreading this nonsense...

          I cannot applaud you enough for that eloquent description.

        2. JohnTill123

          Re: Keep on spreading this nonsense...

          Dude, you think the Linux people were nasty? Try the OpenBSD guys. I once wanted to know if I could change the MAC address on an Ethernet card and I was literally accused of trying to destroy the Internet between Asia and North America.

          Don't get me wrong: I love OpenBSD as much as I love Linux. But the communities were really difficult back then.

    4. Graham Cobb Silver badge

      Re: Keep on spreading this nonsense...

      Sorry, VoiceOfTruth, you are plain wrong.

      The statement 'Open-source software has always been more secure than proprietary software' is true.

      You seem to be mixing things up... Of course most users of any type of software never look at any of the code. You are right that reviewing existing code is time-consuming, boring, etc. But that is not relevant. The issue is the remaining difference in how many people do actually look at the code.

      With proprietary code, generally 3-4 other people review new code/patches (is your experience different?). With OSS, the number who review new code/patches is very different for different projects - it may be very small or it may be huge (such as patches posted to LKML). I am sure the average, weighted by number of users around the world, is a bit larger - maybe 6-8̇.

      But the real difference isn't the code review when the code was written. It is who reviews the code at a later date. When an issue occurs, such as a serious bug is found in one project, or a major hack occurs, the difference between proprietary code and OSS becomes extreme! The proprietary code remains at 3-4 people looking at the code. But the OSS turns into thousands of people looking at the code!

      Take the recent polkit issue. I don't claim that being open or closed made any difference to the likelihood of the bug occurring in the first place. But now it has been found, many thousands of developers have looked at that code, related and nearby code, and (most importantly of all) similar code in other contexts (sudo, other OS's, etc).

      This has led to much increased confidence in the quality of those other implementations. On the other hand, I am sure that Microsoft (for example) have had some people review their similar code in the Windows kernel, for the same reason - but that will be tens of people (at most), and no one outside Microsoft knows the results of that review (so users do not have an increased level of confidence).

      The same goes for other major bugs found in Linux or other OSS. They all trigger a lot of open discussion about the problem, other related problems that may be in existing code, implications and impact of the bugs in different contexts, ways to protect against similar bugs or design patterns to avoid them in the future, review of other code which could have similar problems, the effectiveness or otherwise of possible operational workrounds where code cannot be fixed immediately, etc. All of those contribute massively to the security of the OSS projects being discussed - even before the code fixes are released.

      That is why 'Open-source software has always been more secure than proprietary software'. Not because of some fiction that "many eyes" is about the number of people reading the code for the hell of it. The "many eyes" come into play once issues are found.

      1. Snake Silver badge

        Re: Just plain wrong

        @Graham Cobb

        But you are still making generalizations. The secret is in your own wording

        "But the real difference isn't the code review when the code was written. It is who reviews the code at a later date. When an issue occurs, such as a serious bug is found in one project, or a major hack occurs, the difference between proprietary code and OSS becomes extreme! The proprietary code remains at 3-4 people looking at the code. But the OSS turns into thousands of people looking at the code!

        That might be true, that you [can] have more eyes looking at the code "at a later date", but at that point the damage is done. The horse has bolted and left the stable...but now you have more eyes looking at that broken gate. That is not "better security" whilst the program is under the most general of usage, that is after the program has been well used and someone, *finally*, looked at the code (sometimes decades after initial rollout) that could have been linked to thousands upon thousands of projects.

        It is time for F/OSS to get off of its high horse. "Free", "open source" or "closed source"...it does not matter. You are only using those terms to justify a personal bias in your belief system of how code should 'be' ("free and accessible to everyone", or "I do indeed need to get paid for my work").

        What matters is how many individuals are qualified to work on the project, how many people actually ARE looking at the project, and what they are looking for/at when they are working on said project.

        Don't be elitist. An "open source" project where everyone works on improving the UI/UX, but not a single person is looking over old, linked libraries and testing for vulnerabilities under modern conditions, is NO, NO better than a "closed source" project doing the exact same thing. NO BETTER. Just because people are doing it without expectation of compensation does NOT mean that this work is of any better quality, or more useful in finding hidden problems. It is arrogance to believe otherwise.

        1. Graham Cobb Silver badge

          Re: Just plain wrong

          No, you have missed my point.

          I am saying nothing about the quality of the developers, or about the effect of paid-for or free on development. Absolutely not! In fact I am absolutely sure that, in general, paid, professional software developers are much more skilled, and less likely to create bugs than unpaid amateurs. The difference is not about money!

          The difference is about "proprietary" vs "open source". The much greater security for OSS is exactly because the code is visible and can be read, studied, fixed, broken and modified by anyone. That makes for much larger effective teams on a number of large projects. Much more discussion, amongst the many professional, paid, software developers (working for many companies or as consultants) working on projects such as the Linux kernel, the various filesystems, containerisation, browsers, samba, Gnome and KDE, ...

          What matters is how many individuals are qualified to work on the project, how many people actually ARE looking at the project, and what they are looking for/at when they are working on said project.

          Exactly. And, in general, for OSS those are much higher than for proprietary software. Particularly when a bug is found - proprietary software can only call upon the normal development team when a serious bug occurs - they have to understand it, fix it, test in all the appropriate environments, develop lessons-learned, etc. OSS can call upon hundreds of developers to engage in that process, and they also immediately turn to look for similar bugs in related or similar projects. That is exactly what we saw in the polkit case.

          Polkit was no better or worse than equivalent proprietary software in having that bug. But now that bug has happened, in an OSS product, everyone (even amateurs!) now know to check for the impact of argc==0, not just in security critical software such as this but even in the simplest of apps. All the similar code in security-critical contexts in other OS's (OSS and proprietary) has now been examined and reviewed by their respective developers and even some of their users.

          1. Snake Silver badge

            Re: OSS has larger effective teams

            I'm not sure that can be proven. Some packages have a large contributor base yet others have but one (look at the dependency on colors.js).

            It varies tremendously, sometimes based solely on expected level of peer acknowledgment, so to say OSS "has larger effective teams" to work on problems is on the same level of inaccuracy as "more eyes on the code", which hasn't been proven as effective since the number of revealed old & legacy bugs has only grown recently.

    5. Psmo
      Windows

      Re: Keep on spreading this nonsense...

      My sweeping generalisations are better than yours.

    6. Anonymous Coward
      Anonymous Coward

      Re: Keep on spreading this nonsense...

      The big problem that causes these massive security headaches in open source is when so many different projects pull in somebody else's project, that pulls in something else, that pulls in something else, ad infinitum all the way back to the random guy in Nebraska.

      Very rarely will anyone look at the upstream source for issues despite the "many eyes" idea. They may not even realize that the code they are using has pulled in other projects.

      You then end up with a veritable clusterfuck, where one insecure project affects hundreds of end products. Where even identifying which end products are affected becomes a nightmare as you can't track the chain and embedded systems that nobody cares about anymore never get fixed.

      I am not saying this never happens in closed source, but it is definitely less of an issue.

      1. Snake Silver badge

        Re: pulling projects

        This is true. Open source depends very, very strongly on a chain of trust through the code base, very much like certificates are.

        The problem is if the code is actually worthy of being trusted, or are you just making that assumption? How many people actually have read through the source code of GIMP, from beginning to end, to confirm the it does what's written on the tin, and nothing more?

        Yes, closed source CERTAINLY has the same questions. But there is a monetary factor involved there: screw up and your financial future can be on the line. Sony injecting a root kit causes both reputational and financial repercussions. Open source? Not so much - reputation, sure. But financial hasn't been proven much at all.

        1. Anonymous Coward
          Anonymous Coward

          Re: pulling projects

          Yes, closed source CERTAINLY has the same questions. But there is a monetary factor involved there: screw up and your financial future can be on the line.

          I've read you comments chronologically here, and I think you got a valid point. Very valid. But...

          I must point out that here you too are simplifying the argument to make a point. If you consider screw up and your financial future can be on the line you should also consider "all those other" commercial variables/ tools/ influences. Sure, you got a point about the relation between "screw up" and "business consequence", but we all here have enough experiences with holistic corporate operation and life to know that you can (and will) hedge for that. Especially knowing the human species, particularly if we are talking money. This is why you can, to stay within your "user is just user" argument, force your changes/ opinion/ profitable situation on customers/ users, whether it's a bloody ribbon, a file format (Can you sent it as Word/ PowerPoint because I can't open it...) as an "industry standard", or deny ownership of anything after payment and wreck your brain how you can change everything you do to "something subscription" without "right to ownership repair" to nurture your market share and bottom line.

          So in short, your argument of "financial consequences" seems to refer to that other one often heard: "Consumers voting with their feet". Well, think about it, how many times have you seen that happen with paid software? Your users, indeed sheeple, most likely will moan about that screw up, but then rationalise that "it's what it is" and go on with their life. I'm sure if we sit down and think about it, we can up with millions of those real life examples (as you will also with the contrary no doubt ;)

          1. Snake Silver badge

            Re: simplifying arguments

            Your points are certainly valid. I was thinking during my opinion of "financial consequences" in terms of lawsuits - like you, I don't take much faith [any more] in people or organizations to 'do the right thing' simply because their constituents are filing complaints.

            Making them pay through the nose, however, usually gets some level of response. Even if initially only equivalent to a gnat biting a rampaging elephant; hopefully enough bites kills the damn thing.

            1. Anonymous Coward
              Anonymous Coward

              Re: simplifying arguments

              Making them pay through the nose, however, usually gets some level of response.

              Indeed. If the amount is big enough. Which real life examples (MS, Google, FB, Apple) show hasn't been the case really. IF that case ever makes it to becoming a (very labour intensive) court case.

              And additionally, be honest: who are those who have to (wake up and) oblige them to do that?

              Ah, them?

              Hmmm...

              :)

            2. Richard 12 Silver badge

              Re: simplifying arguments

              Every EULA explicitly denies such liability.

              When was the last successful lawsuit along those lines?

        2. Psmo

          Re: pulling projects

          You mean screw up and your financial future can be on the line pass the project off to marketing for a rebrand, surely?

      2. DevOpsTimothyC

        Re: Keep on spreading this nonsense...

        I am not saying this never happens in closed source, but it is definitely less of an issue.

        Most closed source software pulls in open source libraries to provide certain elements of functionality. Take a look at https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/ as an example

      3. Richard 12 Silver badge

        Re: Keep on spreading this nonsense...

        Closed source products use huge amounts of open source software. Just take a look at the 3rd party licence pages.

        Almost every "significant" open source project has commercial contributors, because they use them.

        - Even if the licence doesn't require your changes to be published, they're almost always offered upstream because it makes life far easier if you don't have to apply your own pile of patches.

        The large and popular open source software are generally mostly written by the commercial contributions of multiple companies.

    7. david 12 Silver badge

      Re: Keep on spreading this nonsense...

      Windows NT has had unix subsystem for 20 years. But it used to be different enough from BSD or Solaris or gnu/Linux that you had to recompile applications for the platform.

      Now we have Win10/Win11 with a (mostly) binary compatible Linux virtualised OS. The people who want to use Linux binaries now (including commentators here) think that 'cross platform' means 'binary available', and 'unix' means 'binary compatible'.

      The vast majority of 'Open Source' users don't think Open Source means 'I can re-compile Open Office to run on a posix system'.

  3. Anonymous Coward
    Anonymous Coward

    Umm, nope..

    Sure, as open-source co-founder Eric S Raymond pointed out in Linus' law: "Given enough eyeballs, all bugs are shallow."

    As far as I know he admitted later that that statement was more marketing than his personally perceived truth.

    I get the idea, but it assumed people even look for issues instead of hacking together a tool because they need a solution for a problem - and security typically isn't anyone's problem until it goes wrong, as ample examples will testify.

    I have some ideas for this, but it's going to take me a few months before I get round to this. I'll ping El Reg when we're ready for discussion because just about the first step is to ensure there is sane debate - yet another isolated effort isn't going to work, that's been tried already.

    1. Arthur the cat Silver badge
      Unhappy

      Re: Umm, nope..

      the first step is to ensure there is sane debate

      I totally agree. Unfortunately the disruption to logistics due to the pandemic appears to have caused a severe global shortage of sane debates. [See your preferred local or global news source for corroborative examples.]

  4. Brewster's Angle Grinder Silver badge

    "Now there is an urban legend that open-source developers don't get paid. Please. We came out of the basement a long, long time ago."

    This is not a phrase I use often, but the correct response to that is "check your privilege". There's still plenty that doesn't get paid for. That's "free" as in "exploitative".

    1. Dan 55 Silver badge

      Here's a comment in the explain xkcd for the "guy in Nebraska" cartoon:

      "I worked for the Linux Foundation on the Core Infrastructure Initiative supporting OpenSSL and other projects. The one that scared me was Expat the XML parser maintained by two people on alternate Sunday afternoons assuming no other distractions."

      See also: OpenSSL, NTP, TZ database, etc...

      1. UK DM

        But I've worked on it too

        Libexpat 1.95.1 from circa 2000.

        So that is at least 3 people :p

        Oooo and OpenSSL too...

        Anyhow enough gossip in the El Reg today I've got some more code to read.

  5. gnasher729 Silver badge

    Me and openssl

    At some point in my career I had the pleasure to have to read more of the OpenSSL source code than I liked. I found it frightening. I wouldn’t trust it one bit.

  6. fg_swe Bronze badge

    Systemic Security Approaches

    1.) Proper Grammars, Parsers, Scanners. Make them suited to the application, precise and as strict as possible. Stay clear of of Generic Serialization.

    2.) Memory Safe Languages can eliminate 70% of CVE Bugs. Do NOT use C. See http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf

    3.) Sandboxing, Firewalling. MS Word has no business reading your engineering files and neither does CATIA need access to your letters.

    3.2) Scripts from not-well-known sources should run inside a sandbox.

    4.) Certified, Minimalist Mikrokernels

    https://hensoldt-cyber.com/2021/06/24/sel4-why-a-microkernel-system/

    https://fgw.ddnss.de/L4gegenueberLinux.html

    5.) KISS: Keep your security approach simple and therefore easy to analyze, easy to follow. Avoid TLS, if possible. Way too complex to properly implement.

    6.) Minimize attack surface to the outside. Exposing Exchange/Outlook/Office to the outside world is a very bad idea, given that they are behind points 1 to 5 by at least 20 if not 40 years.

    1. Roland6 Silver badge

      Re: Systemic Security Approaches

      Major omission the design approach.

      Proper design needs to be baked in and that may mean no code until the design has been read and approved. It is here that I suspect you will see some clear water between (some) proprietary code-bases and open source, where the company has enforced a structured design process, using off-the-shelf proprietary tools...

  7. Robert Grant

    > I don't know everyone who's anyone in Linux and open-source circles, but I know a heck of a lot of them. Almost all of them are being paid very well indeed.

    I think this is reductive. There are thousands of projects out there, being quietly maintained, and I bet you don't know how much of that time is paid for.

    1. Brewster's Angle Grinder Silver badge

      And all it takes is one obscure library to not properly sanitise its inputs ("I'll fix that later"), and Bobby Tables is your progeny.

      1. Graham Cobb Silver badge

        Sure. And how many obscure libraries are used in proprietary corporate environments? We have no way to know if the proprietary software we are using has that problem, let alone pay someone for help to fix it if the supplier wont.

        1. Brewster's Angle Grinder Silver badge

          I really wasn't wading into the open source/closed source debate. I'm only willing to take the field in the paid/unpaid open source debate: you can use an open source project developed by lots of salaried devs working at foundations or commercial ventures, but still end up depending on a library that one volunteer hacks on alternate Sunday afternoons...

  8. F0ulRaven

    This is going to run forever - the why is open source not as secure as it should be, considering it is ideologically clean and doesn't involve any capitalism?

    1. Graham Cobb Silver badge

      I think it is more... how can we further improve the improvement we have seen in OSS security even further? Which processes are working well, which are not? Can we improve where money is being spent (whether it is going on paid developers, better tools, automated testing and operations, ...)?

      1. This post has been deleted by its author

  9. david 12 Silver badge

    For what it's worth:

    http://www.swdsi.org/swdsi07/2007_proceedings/papers/236.pdf

    "A SECURITY COMPARISON OF OPEN-SOURCE AND CLOSED SOURCE OPERATING SYSTEMS"

    "Our analysis leads us to conclude that there are no inherent qualitative differences between Windows and other operating systems."

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like