Comment by lmm
2 years ago
None of the significant security vulnerabilities that I can remember have been "deep" - subtle things that require extensive familiarity with the specific codebase and could never have been found by a drive-by contributor, which is the idea that ESR is refuting. Debian keygen bug? Dumb one-liner. Heartbleed? Dumb one-liner. Goto fail? Technically a logic bug, but a two-line thing that could be understood by reading that one file without any additional context.
I've seen cases where exploitation was complex, but even then, that tends to be because the full exploit is chaining together several bugs, each of which is individually simple and could be fixed by a drive-by contributor.
If that was the intended meaning of "shallow", why does the number of eyeballs matter? I think the more obvious interpretation is "quickly discovered".
Yes. We don't have to guess at this, because Raymond wrote that explicitly in the article.
In the article the number of eyeballs is pretty explicitly a minor caveat, and the main point is the shallowness in the sense of approachability:
> In Linus's Law, I think, lies the core difference underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.
> In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.
15 replies →
Spectre, Meltdown and Rowhammer were all discovered in the same timeframe as the things you listed, and were decidedly more complex than dumb one liners. Yes, those are all have a hardware component (and thus the "fixes" are software workarounds), but the fixes involved way more than one or two lines of work.
The workaround fixes are complex, but the actual issues are very simple, no?
No. Architectural leakage via a side-channel is far from simple. It requires deep understanding of the code (i.e. what it does, why it is doing it that way and the implied effect of executing the code on the architecture) and also of the architecture (i.e. how it is executing and why that causes leakage to be observable via the side-channel).
If anything, these are canonical examples of non-simple bugs.
7 replies →