3 ms·

> Since it's now clear that "many eyes makes all bugs shallow" is patently false "patently false". Proof needed, please, we have enough FUD.

by nyan4 11y ago

vox_mollis 11y ago
GnuTLS and Heartbleed are pretty good examples for starters.
- MikeNomad 11y ago
  And for counter examples, I refer to the CERT emails I get regarding the latest software vulnerabilities and patches. Software security is unfortunately, a goal, not an absolute. The process is both fluid and dynamic, and the improvements iterative. To directly address the tenor of your comments, perhaps it would be better to say, "More eyes make bugs more shallow."
nickpsecurity 11y ago
On contrary, the person making that claim needs to prove it's true or else we reject it as FUD against proprietary software. For a long time, the only software to resist prolonged pentesting by NSA were proprietary products certified to B3/A1 and Type 1 respectively. If NSA could hack them, they couldn't pass. Likewise, in safety, we've seen a number of high assurance systems fielded where every state (including failure) it could be in was known ahead of time. Some setups, like mainframes, hit 17-30 year uptime. All proprietary. Meanwhile, in OSS land, we have a steady stream of easily-prevented or detected defects that compromise security. Just like in most proprietary shops. Like proprietary, those OSS projects producing highly-secure stuff are done by great designers/coders with careful review and testing processes. The community-developed OSS hasn't reached the assurance of aforementioned proprietary systems or some in academia. Yet, highly correct or secure stuff seems equally rare in both types of development with proprietary having a bit more just because there were people paying professionals to build those. In theory, with free/cheap labor, OSS could eventually produce more but there's not enough interest. So, the endless stream of bugs in both closed and OSS software that are often really old disproves many eyes argument. It didn't work for even shallowest bugs consistently, much less deep ones. Software quality comes from people taking responsibility and putting time into QA, esp design/code review. OSS, shared-source proprietary, closed-source... always same requirement that gives quality.
- guelo 11y ago
  Maybe a new OSS license is needed where the price of using the software is reviewing some code once in a while.
  - nickpsecurity 11y ago
    I broke it down from a security or auditing angle for all sides here: https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639 https://www.schneier.com/blog/archives/2014/05/friday_squid_... Review was fundamental. It would be costly and take talent. So, like you, I proposed something that was open source but not quite free. Not many in OSS want to discuss proprietary OSS options but I think it's a critical conversation as it could get better stuff on the market. Prior conversations here at least showed the term, open source, was highly loaded with the expectation of free distribution due to its history. So, I'll modify the essay and next discussion to use shared source. Elaborated more on my concept for a hybrid here: https://news.ycombinator.com/item?id=10500298 https://news.ycombinator.com/item?id=10500298

> Since it's now clear that "many eyes makes all bugs shallow" is patently false "patently false". Proof needed, please, we have enough FUD.

by nyan4 11y ago

> Since it's now clear that "many eyes makes all bugs shallow" is patently false "patently false". Proof needed, please, we have enough FUD.

vox_mollis 11y ago

GnuTLS and Heartbleed are pretty good examples for starters.

MikeNomad 11y ago
And for counter examples, I refer to the CERT emails I get regarding the latest software vulnerabilities and patches. Software security is unfortunately, a goal, not an absolute. The process is both fluid and dynamic, and the improvements iterative. To directly address the tenor of your comments, perhaps it would be better to say, "More eyes make bugs more shallow."

nickpsecurity 11y ago

On contrary, the person making that claim needs to prove it's true or else we reject it as FUD against proprietary software. For a long time, the only software to resist prolonged pentesting by NSA were proprietary products certified to B3/A1 and Type 1 respectively. If NSA could hack them, they couldn't pass. Likewise, in safety, we've seen a number of high assurance systems fielded where every state (including failure) it could be in was known ahead of time. Some setups, like mainframes, hit 17-30 year uptime. All proprietary. Meanwhile, in OSS land, we have a steady stream of easily-prevented or detected defects that compromise security. Just like in most proprietary shops. Like proprietary, those OSS projects producing highly-secure stuff are done by great designers/coders with careful review and testing processes. The community-developed OSS hasn't reached the assurance of aforementioned proprietary systems or some in academia. Yet, highly correct or secure stuff seems equally rare in both types of development with proprietary having a bit more just because there were people paying professionals to build those. In theory, with free/cheap labor, OSS could eventually produce more but there's not enough interest. So, the endless stream of bugs in both closed and OSS software that are often really old disproves many eyes argument. It didn't work for even shallowest bugs consistently, much less deep ones. Software quality comes from people taking responsibility and putting time into QA, esp design/code review. OSS, shared-source proprietary, closed-source... always same requirement that gives quality.

guelo 11y ago
Maybe a new OSS license is needed where the price of using the software is reviewing some code once in a while.
- nickpsecurity 11y ago
  I broke it down from a security or auditing angle for all sides here: https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639 https://www.schneier.com/blog/archives/2014/05/friday_squid_... Review was fundamental. It would be costly and take talent. So, like you, I proposed something that was open source but not quite free. Not many in OSS want to discuss proprietary OSS options but I think it's a critical conversation as it could get better stuff on the market. Prior conversations here at least showed the term, open source, was highly loaded with the expectation of free distribution due to its history. So, I'll modify the essay and next discussion to use shared source. Elaborated more on my concept for a hybrid here: https://news.ycombinator.com/item?id=10500298 https://news.ycombinator.com/item?id=10500298