4 ms·

Eric S. Raymond for one. https://en.wikipedia.org/wiki/Linus%27s_Law https://en.wikipedia.org/wiki/Linus%27s_Law

by jvoorhis 12y ago

astrodust 12y ago
Guess that should be renamed to Linus's Fallacy.
crpatino 12y ago
To be fair, Linus's Law was meant to apply to all bugs in general, not particularly to security bugs. Though it can be argued that, given that human nature makes people more prone to go looking into things when there is a (perceived) problem, Linus's Law applies only to the subset of bugs that affect functional requirements of software.
dllthomas 12y ago
The context where ESR coined "Linus's Law" was one of describing how FLO development could be surprisingly effective. "Someone will see an easy way around any given issue" has nothing to do with "there will be no security critical bugs". Neither "secure" nor "security" appear in the section of CatB under discussion there, and they only appear in the wiki article in reference to separate supporting evidence in a security textbook. I will grant that the longer formulation's phrasing of "almost every problem will be characterized quickly and the fix will be obvious to someone" could be interpreted as including obscure security issues, but 1) this could reasonably be part of (every - almost every), and 2) I think it is best to separate the finding of a bug from its characterization - the typical invisibility of security bugs from a functional standpoint certainly means that security audits and best practices are not appreciably less important for FLO software than proprietary software. Any effect of "many eyes" on security absent visibility should be expected to be marginal. The biggest benefits from open source, from a security standpoint, are probably that it enables truly independent audit, and secondarily that it promotes coding as if your code will be published and scrutinized.

4 ms·

Eric S. Raymond for one. https://en.wikipedia.org/wiki/Linus%27s_Law https://en.wikipedia.org/wiki/Linus%27s_Law

by jvoorhis 12y ago

Eric S. Raymond for one. https://en.wikipedia.org/wiki/Linus%27s_Law https://en.wikipedia.org/wiki/Linus%27s_Law

astrodust 12y ago
Guess that should be renamed to Linus's Fallacy.
crpatino 12y ago
To be fair, Linus's Law was meant to apply to all bugs in general, not particularly to security bugs. Though it can be argued that, given that human nature makes people more prone to go looking into things when there is a (perceived) problem, Linus's Law applies only to the subset of bugs that affect functional requirements of software.
dllthomas 12y ago
The context where ESR coined "Linus's Law" was one of describing how FLO development could be surprisingly effective. "Someone will see an easy way around any given issue" has nothing to do with "there will be no security critical bugs". Neither "secure" nor "security" appear in the section of CatB under discussion there, and they only appear in the wiki article in reference to separate supporting evidence in a security textbook. I will grant that the longer formulation's phrasing of "almost every problem will be characterized quickly and the fix will be obvious to someone" could be interpreted as including obscure security issues, but 1) this could reasonably be part of (every - almost every), and 2) I think it is best to separate the finding of a bug from its characterization - the typical invisibility of security bugs from a functional standpoint certainly means that security audits and best practices are not appreciably less important for FLO software than proprietary software. Any effect of "many eyes" on security absent visibility should be expected to be marginal. The biggest benefits from open source, from a security standpoint, are probably that it enables truly independent audit, and secondarily that it promotes coding as if your code will be published and scrutinized.