8 ms·

The right thing for the wrong reasons: FLOSS doesn't imply security

37 points by Seirdy 5y ago

matheusmoreira 5y ago
It does imply trust however. I go out of my way to read source code and I'm a lot more comfortable using code I've read compared to opaque binaries nobody really knows a thing about. Free software is not immune to vulnerabilities but it is quite resistant to people doing shady stuff just because they think they can get away with it. Now with reproducible builds it's gonna be even more trustworthy.
- ASalazarMX 5y ago
  Besides, closed source also doesn't imply security, so at least with FLOSS we have the source code in case we have to investigate.
- jka 5y ago
  Yep. The pushback against FLOSS software could be seen as a delay tactic to allow the continued distribution of software with known flaws (even in commercial environments with source-available agreements, as other commentors have alluded to. if you don't have both the public code and reproducible build of it that you can verify independently, then you may have been provided with human trust, but you do not have software trust). I'd expect that once software trust reaches a sufficiently high-quality baseline, we'll begin to see tricksters retreat (or bolster) network-level traffic gathering and interference. Not all tricksters are hugely sophisticated -- but many of them do get themselves into increasingly complicated situations, often with significant access to resources of finance and leverage -- so that movement would probably be accompanied by a lot of braying for attention and FUD-style tactics (they'll need to find ways to cover their tracks -- something that is often purely about producing distracting noise and search results nowadays, in the era of search engines).
  - Seirdy 5y ago
    Have you noticed a pushback against FLOSS? I'd be interested if that's the case. I went out of my way in this post to make it clear that I'm vehemently in support of FLOSS for a solid list of reasons; it's just that "security" is far lower on that list than some readers would think. There's a reason I only decided to post this months after two of my previous posts in support of FLOSS gained traction ;). Unfortunately, "FLOSS doesn't imply security, but it's certainly helpful. Just set your expectations straight and remember that security isn't a checklist but an emergent property that stems from a variety of factors uncovered through detailed analysis" is a bit too long of a title so I had to make one that looked like I was picking a side before making it clear that I wasn't. Titles aren't good at capturing nuanced views.
    - jka 5y ago
      It's OK, this was me jumping on my usual soapbox, and not a direct response to your article (I should do better at staying on-thread-topic, in general). In the venn diagram of source-code-related security properties, the fact that proprietary code can be secure and that FLOSS software can be insecure aren't controversial to me, so I think I'll tend to be aligned with your core arguments. The pushback that I notice (or perceive? maybe they're different?) is that most large tech companies - regardless of background - seem stubbornly opposed to offering their products and services as FLOSS through-and-through, despite what I think are fairly apparent, technically sound, morally conscious and defensible arguments that the code for the products everyone relies on in life could and should be FLOSS. But: I'll go away and read your post in a bit more depth before adding any further thoughts.
      - jka 5y ago
        Roughly speaking: yes, you make fair points that source code isn't required for a number of different security research approaches (and, as you indicate, many research practitioners essentially isolate the software they're investigating and then attempt to see what it does at a binary level and/or at runtime). Although I suspect that I'm missing other things to add to the conversation, I'd argue that availability of source code -- at least in the Zoom and Intel ME cases -- would reduce the overall time-and-monetary-cost of identifying suspected flaws. And also of nullifying invalid insecurity claims! So that's another argument for FLOSS: let's try to dissuade vendors from (appearing to?) waste our researchers' and defenders' valuable time.
DonHopkins 5y ago
"You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code." -Ken Thompson "Given enough eyeballs, all bugs are shallow." -Eric S Raymond pretending to quote Linus Torvalds by mis-attributing his own wishful fallacy as "Linus's Law" Then there's Theo de Raadt's salty quote about ESR's ridiculous "many eyes" argument that Raymond deceptively calls "Linus's Law": https://groups.google.com/g/fa.openbsd.tech/c/gypClO4qTgM/m/UzcgS_iYn1IJ https://groups.google.com/g/fa.openbsd.tech/c/gypClO4qTgM/m/... "Oh right, let's hear some of that "many eyes" crap again. My favorite part of the "many eyes" argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code." -Theo de Raadt on ESR's "Linus's Law" Actually, that fallacious "many eyes" argument was "formulated" by Eric S Raymond (to whom Theo was referring as "the originator of the statement"), which ESR misleadingly named "Linux's Law" in "honor" of Linus Torvalds, who never even made that claim, which is ironic because it actually dishonors Linus by being an invalid fallacy. https://en.wikipedia.org/wiki/Linus%27s_law https://en.wikipedia.org/wiki/Linus%27s_law >Validity >In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate. While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs". >The persistence of the Heartbleed security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum. Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain. In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking". Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed. >Empirical support of the validity of Linus's law was obtained by comparing popular and unpopular projects of the same organization. Popular projects are projects with the top 5% of GitHub stars (7,481 stars or more). Bug identification was measured using the corrective commit probability, the ratio of commits determined to be related to fixing bugs. The analysis showed that popular projects had a higher ratio of bug fixes (e.g., Google's popular projects had a 27% higher bug fix rate than Google's less popular projects). Since it is unlikely that Google lowered its code quality standards in more popular projects, this is an indication of increased bug detection efficiency in popular projects. The little experience Raymond DOES have auditing code has been a total fiasco and embarrassing failure, since his understanding of the code was incompetent and deeply tainted by his preconceived political ideology and conspiracy theories about climate change, which was his only motivation for auditing the code in the first place. His sole quest was to deceptively discredit the scientists who warned about climate change. The code he found and highlighted was actually COMMENTED OUT, and he never addressed the fact that the scientists were vindicated. http://rationalwiki.org/wiki/Eric_S._Raymond http://rationalwiki.org/wiki/Eric_S._Raymond >During the Climategate fiasco, Raymond's ability to read other peoples' source code (or at least his honesty about it) was called into question when he was caught quote-mining analysis software written by the CRU researchers, presenting a commented-out section of source code used for analyzing counterfactuals as evidence of deliberate data manipulation. When confronted with the fact that scientists as a general rule are scrupulously honest, Raymond claimed it was a case of an "error cascade," a concept that makes sense in computer science and other places where all data goes through a single potential failure point, but in areas where outside data and multiple lines of evidence are used for verification, doesn't entirely make sense. (He was curiously silent when all the researchers involved were exonerated of scientific misconduct.)
viktorcode 5y ago
I didn't like few implications author makes. > One of the biggest parts of the Free and Open Source Software definitions is the freedom to study a program and modify it; in other words, access to editable source code. You don't have to have FLOSS-compatible open source license to run security audits on the code. For instance: Microsoft allowed government entities to check Windows security-related source code for many years. Just having access to the code is enough for audits, regardless of the license. > One such reason is that source code is necessary to have any degree of transparency into how a piece of software operates, and is therefore necessary to determine if it is at all secure or trustworthy. Although security through obscurity is certainly not a robust measure... If code is not open sourced it doesn't mean security through obscurity is employed. It simply means there's no public access to the code. This is a very common misconception.
- deknos 5y ago
  > Just having access to the code is enough for audits, regardless of the license. No. who guarantuees that the code is the one, which is compiled to the binary you are running?
  - pabs3 5y ago
    You can use Reproducible Builds to compile the source code and get the exact same binary: https://reproducible-builds.org/ https://reproducible-builds.org/
    - deknos 5y ago
      with opensource you can do this. but with closed source like from microsoft, that is not automatically given.
      - ben_w 5y ago
        In the context of “government agencies”, they can just order Microsoft to make it possible, if they care. In the case of Windows for Warships[0], one of the arguments (if they absolutely had to use Windows and nothing else) might be something like “Dear Mr. Gates, if you don’t empower us to do our job, we can’t guarantee that North Korea won’t retarget our nukes at your face. Sincerely, the Royal Navy.” [0] https://en.wikipedia.org/wiki/Submarine_Command_System https://en.wikipedia.org/wiki/Submarine_Command_System
Bancakes 5y ago
Lack of FOSS implies lack of security. By default software is insecure and has malfeatures which need turning off.
- q-big 5y ago
  > By default software [...] has malfeatures which need turning off. The problem rather is that such software is not simply considered malware by the public.
- user-the-name 5y ago
  Not at all, any more than FOSS implies security.
thompson1 5y ago
[flagged]
- Seirdy 5y ago
  This user copy-pasted my comment from lobste.rs without context and added their own unrelated link to the end. Original comment: https://lobste.rs/s/8ajhgl/right_thing_for_wrong_reasons_floss_doesn#c_erxbty https://lobste.rs/s/8ajhgl/right_thing_for_wrong_reasons_flo...
- krageon 5y ago
  > I’d consider the proprietary Google Chrome or Microsoft Edge more secure than Pale Moon or most webkit2gtk-based browse Now consider Chrome had a widely exploited (by a large ad network) known (by everyone, which means also Google) third party -> first party bypass for a long time. This destroys the security model, but I'm guessing the ad network loved it. This is what you get for trusting a project created and maintained by an ad company.
  - iudqnolq 5y ago
    I'm expecting your exploit to be something like "automatically signs you into Google search". I don't like that sort of thing (in fact I use Firefox, mostly for moral reasons) but I disagree strongly with your general argument. The average person has their personal information known by data brokers. All using an insecure niche product does is add more attackers with their personal information. In addition technically-legal attackers constrain themselves a bit to not violate the law too much, whereas Russian gangsters have less incentive to restrain themselves.
    - krageon 5y ago
      The spirit of your rebuttal is couched in the belief that a known oppressor is better than a party that could be an oppressor, because you know what to expect. I categorically disagree, but that is okay.
      - 5y ago
kazinator 5y ago
"Imply" is a big word that requires logical proof. Even formal verification may fall short of implying security, unless it's from the transistor level on up. The issue is that, rather, non-FOSS implies the existence of significant hindrances in the area of security. It also implies a dependency on a single vendor, and their responsiveness to incidents.
nonrandomstring 5y ago
Seirdy's article is mostly focused on bug-finding in the binary domain, by fuzzing, memory analysis, decompiling and other techniques. He makes the entirely correct observation that having source to audit is only one part of thorough debugging, because many exploits are only manifest at runtime in the context of specific hardware, operating systems, and build chains. Seirdy does not denigrate source auditing as some interpretations of his words here seem to say. This feels like quite a mature article and there are implications he touches on but doesn't fully explore like Thompson's "Trusting trust" rabbit hole of the "malicious compiler" and the fact that security by obscurity has some serious clout if you can compile for non-standard hardware. The Non Specific Agency may have a zero-day for your Debian package, but it won't irk the program on your FPGA emulated Fairchild F8 Microprocessor.
- Seirdy 5y ago
  (am author) I'm actually going to touch on that Ken Thompson article in a follow-up about how sandboxing can improve not just security, but user freedom/control too (if implemented a certain way). It'll go over how software itself should be considered untrusted (citing Thompson); however, even if it is "trusted", it still might consume untrusted content (often by reading data from arbitrary files or the network). Part of what it means to use free software IMO is having less dependence on a vendor, and reducing trust is one of multiple things that can work in that direction.
btdmaster 5y ago
The most concrete counterexample I can think of is the Windows XP leak -- as source code was leaked Microsoft seemed to be really annoyed because security flaws were kept all the way up to Windows 10 (in the name of backwards compatibility).
- phendrenad2 5y ago
  Sure, they SAID that they were annoyed because of potential security issues. But you know what really annoys companies? Their secret sauce being easily viewable to competitors, and the extra workload their legal department will have tracking down people who host the leak and sending them DMCAs.
  - btdmaster 5y ago
    But they supplied source code to other companies: https://web.archive.org/web/20081216125724/http://www.microsoft.com/resources/sharedsource/windowslp.mspx https://web.archive.org/web/20081216125724/http://www.micros... (this is suspected to be how the leak was started in the first place).
    - phendrenad2 5y ago
      Would you give me your Social Security Number if I asked for it? Why not? Would you give it to your bank when opening a bank account? Why? When you join a company, you have to sign a NDA that covers not only the company's trade secrets, but any trade secrets of that company's partners that you are exposed to. So, Microsoft is somewhat free to share their source with select partners whom they trust will keep it secure, and only share with employees who need it. I don't think Joe's Software LLC would have been able to get the Windows source code, even with an NDA.
phendrenad2 5y ago
Yeah, I'm not sold on the "FLOSS is more secure" idea either. Good on you for trying to write down some arguments against it. But unfortunately, comparing the security of closed-source software to the security of open-source software is too difficult. You'd basically have to take two competing programs, one open, one closed, and spend many human-hours trying to hack both, and then publish your results. I believe that in such a test, open-source would perhaps have MORE security bugs. That's just what my gut tells me. Instead, people simply look at the number of security holes patched, and see that FLOSS projects report and fix many more holes. So surely FLOSS is more secure, right? Or, they rely on folk wisdom like "With enough eyes all bugs are shallow" which aren't any more proven in the real world than "FLOSS is more secure".
SAI_Peregrinus 5y ago
FLOSS doesn't imply security, it allows verifying it. Closed-source software doesn't allow verifying it, so it's safest to assume it's insecure.
- Seirdy 5y ago
  > Closed-source software doesn't allow verifying it, so it's safest to assume it's insecure. The bulk of the article was a response to this claim: it covered how closed-source software can have its security analyzed through black-box techniques. I recommend giving it a read before dismissing it.

37 points by Seirdy 5y ago

It does imply trust however. I go out of my way to read source code and I'm a lot more comfortable using code I've read compared to opaque binaries nobody really knows a thing about. Free software is not immune to vulnerabilities but it is quite resistant to people doing shady stuff just because they think they can get away with it. Now with reproducible builds it's gonna be even more trustworthy.

ASalazarMX 5y ago
Besides, closed source also doesn't imply security, so at least with FLOSS we have the source code in case we have to investigate.
jka 5y ago
Yep. The pushback against FLOSS software could be seen as a delay tactic to allow the continued distribution of software with known flaws (even in commercial environments with source-available agreements, as other commentors have alluded to. if you don't have both the public code and reproducible build of it that you can verify independently, then you may have been provided with human trust, but you do not have software trust). I'd expect that once software trust reaches a sufficiently high-quality baseline, we'll begin to see tricksters retreat (or bolster) network-level traffic gathering and interference. Not all tricksters are hugely sophisticated -- but many of them do get themselves into increasingly complicated situations, often with significant access to resources of finance and leverage -- so that movement would probably be accompanied by a lot of braying for attention and FUD-style tactics (they'll need to find ways to cover their tracks -- something that is often purely about producing distracting noise and search results nowadays, in the era of search engines).
- Seirdy 5y ago
  Have you noticed a pushback against FLOSS? I'd be interested if that's the case. I went out of my way in this post to make it clear that I'm vehemently in support of FLOSS for a solid list of reasons; it's just that "security" is far lower on that list than some readers would think. There's a reason I only decided to post this months after two of my previous posts in support of FLOSS gained traction ;). Unfortunately, "FLOSS doesn't imply security, but it's certainly helpful. Just set your expectations straight and remember that security isn't a checklist but an emergent property that stems from a variety of factors uncovered through detailed analysis" is a bit too long of a title so I had to make one that looked like I was picking a side before making it clear that I wasn't. Titles aren't good at capturing nuanced views.
  - jka 5y ago
    It's OK, this was me jumping on my usual soapbox, and not a direct response to your article (I should do better at staying on-thread-topic, in general). In the venn diagram of source-code-related security properties, the fact that proprietary code can be secure and that FLOSS software can be insecure aren't controversial to me, so I think I'll tend to be aligned with your core arguments. The pushback that I notice (or perceive? maybe they're different?) is that most large tech companies - regardless of background - seem stubbornly opposed to offering their products and services as FLOSS through-and-through, despite what I think are fairly apparent, technically sound, morally conscious and defensible arguments that the code for the products everyone relies on in life could and should be FLOSS. But: I'll go away and read your post in a bit more depth before adding any further thoughts.
    - jka 5y ago
      Roughly speaking: yes, you make fair points that source code isn't required for a number of different security research approaches (and, as you indicate, many research practitioners essentially isolate the software they're investigating and then attempt to see what it does at a binary level and/or at runtime). Although I suspect that I'm missing other things to add to the conversation, I'd argue that availability of source code -- at least in the Zoom and Intel ME cases -- would reduce the overall time-and-monetary-cost of identifying suspected flaws. And also of nullifying invalid insecurity claims! So that's another argument for FLOSS: let's try to dissuade vendors from (appearing to?) waste our researchers' and defenders' valuable time.

DonHopkins 5y ago

"You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code." -Ken Thompson "Given enough eyeballs, all bugs are shallow." -Eric S Raymond pretending to quote Linus Torvalds by mis-attributing his own wishful fallacy as "Linus's Law" Then there's Theo de Raadt's salty quote about ESR's ridiculous "many eyes" argument that Raymond deceptively calls "Linus's Law": https://groups.google.com/g/fa.openbsd.tech/c/gypClO4qTgM/m/UzcgS_iYn1IJ https://groups.google.com/g/fa.openbsd.tech/c/gypClO4qTgM/m/... "Oh right, let's hear some of that "many eyes" crap again. My favorite part of the "many eyes" argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code." -Theo de Raadt on ESR's "Linus's Law" Actually, that fallacious "many eyes" argument was "formulated" by Eric S Raymond (to whom Theo was referring as "the originator of the statement"), which ESR misleadingly named "Linux's Law" in "honor" of Linus Torvalds, who never even made that claim, which is ironic because it actually dishonors Linus by being an invalid fallacy. https://en.wikipedia.org/wiki/Linus%27s_law https://en.wikipedia.org/wiki/Linus%27s_law >Validity >In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate. While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs". >The persistence of the Heartbleed security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum. Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain. In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking". Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed. >Empirical support of the validity of Linus's law was obtained by comparing popular and unpopular projects of the same organization. Popular projects are projects with the top 5% of GitHub stars (7,481 stars or more). Bug identification was measured using the corrective commit probability, the ratio of commits determined to be related to fixing bugs. The analysis showed that popular projects had a higher ratio of bug fixes (e.g., Google's popular projects had a 27% higher bug fix rate than Google's less popular projects). Since it is unlikely that Google lowered its code quality standards in more popular projects, this is an indication of increased bug detection efficiency in popular projects. The little experience Raymond DOES have auditing code has been a total fiasco and embarrassing failure, since his understanding of the code was incompetent and deeply tainted by his preconceived political ideology and conspiracy theories about climate change, which was his only motivation for auditing the code in the first place. His sole quest was to deceptively discredit the scientists who warned about climate change. The code he found and highlighted was actually COMMENTED OUT, and he never addressed the fact that the scientists were vindicated. http://rationalwiki.org/wiki/Eric_S._Raymond http://rationalwiki.org/wiki/Eric_S._Raymond >During the Climategate fiasco, Raymond's ability to read other peoples' source code (or at least his honesty about it) was called into question when he was caught quote-mining analysis software written by the CRU researchers, presenting a commented-out section of source code used for analyzing counterfactuals as evidence of deliberate data manipulation. When confronted with the fact that scientists as a general rule are scrupulously honest, Raymond claimed it was a case of an "error cascade," a concept that makes sense in computer science and other places where all data goes through a single potential failure point, but in areas where outside data and multiple lines of evidence are used for verification, doesn't entirely make sense. (He was curiously silent when all the researchers involved were exonerated of scientific misconduct.)

viktorcode 5y ago

I didn't like few implications author makes. > One of the biggest parts of the Free and Open Source Software definitions is the freedom to study a program and modify it; in other words, access to editable source code. You don't have to have FLOSS-compatible open source license to run security audits on the code. For instance: Microsoft allowed government entities to check Windows security-related source code for many years. Just having access to the code is enough for audits, regardless of the license. > One such reason is that source code is necessary to have any degree of transparency into how a piece of software operates, and is therefore necessary to determine if it is at all secure or trustworthy. Although security through obscurity is certainly not a robust measure... If code is not open sourced it doesn't mean security through obscurity is employed. It simply means there's no public access to the code. This is a very common misconception.

deknos 5y ago
> Just having access to the code is enough for audits, regardless of the license. No. who guarantuees that the code is the one, which is compiled to the binary you are running?
- pabs3 5y ago
  You can use Reproducible Builds to compile the source code and get the exact same binary: https://reproducible-builds.org/ https://reproducible-builds.org/
  - deknos 5y ago
    with opensource you can do this. but with closed source like from microsoft, that is not automatically given.
    - ben_w 5y ago
      In the context of “government agencies”, they can just order Microsoft to make it possible, if they care. In the case of Windows for Warships[0], one of the arguments (if they absolutely had to use Windows and nothing else) might be something like “Dear Mr. Gates, if you don’t empower us to do our job, we can’t guarantee that North Korea won’t retarget our nukes at your face. Sincerely, the Royal Navy.” [0] https://en.wikipedia.org/wiki/Submarine_Command_System https://en.wikipedia.org/wiki/Submarine_Command_System

Bancakes 5y ago

Lack of FOSS implies lack of security. By default software is insecure and has malfeatures which need turning off.

q-big 5y ago
> By default software [...] has malfeatures which need turning off. The problem rather is that such software is not simply considered malware by the public.
user-the-name 5y ago
Not at all, any more than FOSS implies security.

thompson1 5y ago

[flagged]

Seirdy 5y ago
This user copy-pasted my comment from lobste.rs without context and added their own unrelated link to the end. Original comment: https://lobste.rs/s/8ajhgl/right_thing_for_wrong_reasons_floss_doesn#c_erxbty https://lobste.rs/s/8ajhgl/right_thing_for_wrong_reasons_flo...
krageon 5y ago
> I’d consider the proprietary Google Chrome or Microsoft Edge more secure than Pale Moon or most webkit2gtk-based browse Now consider Chrome had a widely exploited (by a large ad network) known (by everyone, which means also Google) third party -> first party bypass for a long time. This destroys the security model, but I'm guessing the ad network loved it. This is what you get for trusting a project created and maintained by an ad company.
- iudqnolq 5y ago
  I'm expecting your exploit to be something like "automatically signs you into Google search". I don't like that sort of thing (in fact I use Firefox, mostly for moral reasons) but I disagree strongly with your general argument. The average person has their personal information known by data brokers. All using an insecure niche product does is add more attackers with their personal information. In addition technically-legal attackers constrain themselves a bit to not violate the law too much, whereas Russian gangsters have less incentive to restrain themselves.
  - krageon 5y ago
    The spirit of your rebuttal is couched in the belief that a known oppressor is better than a party that could be an oppressor, because you know what to expect. I categorically disagree, but that is okay.
    - 5y ago

kazinator 5y ago

"Imply" is a big word that requires logical proof. Even formal verification may fall short of implying security, unless it's from the transistor level on up. The issue is that, rather, non-FOSS implies the existence of significant hindrances in the area of security. It also implies a dependency on a single vendor, and their responsiveness to incidents.

nonrandomstring 5y ago

Seirdy's article is mostly focused on bug-finding in the binary domain, by fuzzing, memory analysis, decompiling and other techniques. He makes the entirely correct observation that having source to audit is only one part of thorough debugging, because many exploits are only manifest at runtime in the context of specific hardware, operating systems, and build chains. Seirdy does not denigrate source auditing as some interpretations of his words here seem to say. This feels like quite a mature article and there are implications he touches on but doesn't fully explore like Thompson's "Trusting trust" rabbit hole of the "malicious compiler" and the fact that security by obscurity has some serious clout if you can compile for non-standard hardware. The Non Specific Agency may have a zero-day for your Debian package, but it won't irk the program on your FPGA emulated Fairchild F8 Microprocessor.

Seirdy 5y ago
(am author) I'm actually going to touch on that Ken Thompson article in a follow-up about how sandboxing can improve not just security, but user freedom/control too (if implemented a certain way). It'll go over how software itself should be considered untrusted (citing Thompson); however, even if it is "trusted", it still might consume untrusted content (often by reading data from arbitrary files or the network). Part of what it means to use free software IMO is having less dependence on a vendor, and reducing trust is one of multiple things that can work in that direction.

btdmaster 5y ago

The most concrete counterexample I can think of is the Windows XP leak -- as source code was leaked Microsoft seemed to be really annoyed because security flaws were kept all the way up to Windows 10 (in the name of backwards compatibility).

phendrenad2 5y ago
Sure, they SAID that they were annoyed because of potential security issues. But you know what really annoys companies? Their secret sauce being easily viewable to competitors, and the extra workload their legal department will have tracking down people who host the leak and sending them DMCAs.
- btdmaster 5y ago
  But they supplied source code to other companies: https://web.archive.org/web/20081216125724/http://www.microsoft.com/resources/sharedsource/windowslp.mspx https://web.archive.org/web/20081216125724/http://www.micros... (this is suspected to be how the leak was started in the first place).
  - phendrenad2 5y ago
    Would you give me your Social Security Number if I asked for it? Why not? Would you give it to your bank when opening a bank account? Why? When you join a company, you have to sign a NDA that covers not only the company's trade secrets, but any trade secrets of that company's partners that you are exposed to. So, Microsoft is somewhat free to share their source with select partners whom they trust will keep it secure, and only share with employees who need it. I don't think Joe's Software LLC would have been able to get the Windows source code, even with an NDA.

phendrenad2 5y ago

Yeah, I'm not sold on the "FLOSS is more secure" idea either. Good on you for trying to write down some arguments against it. But unfortunately, comparing the security of closed-source software to the security of open-source software is too difficult. You'd basically have to take two competing programs, one open, one closed, and spend many human-hours trying to hack both, and then publish your results. I believe that in such a test, open-source would perhaps have MORE security bugs. That's just what my gut tells me. Instead, people simply look at the number of security holes patched, and see that FLOSS projects report and fix many more holes. So surely FLOSS is more secure, right? Or, they rely on folk wisdom like "With enough eyes all bugs are shallow" which aren't any more proven in the real world than "FLOSS is more secure".

SAI_Peregrinus 5y ago

FLOSS doesn't imply security, it allows verifying it. Closed-source software doesn't allow verifying it, so it's safest to assume it's insecure.

Seirdy 5y ago
> Closed-source software doesn't allow verifying it, so it's safest to assume it's insecure. The bulk of the article was a response to this claim: it covered how closed-source software can have its security analyzed through black-box techniques. I recommend giving it a read before dismissing it.