On Wed, Jun 16, 2004 at 02:12:18PM -0700, Eric Rescorla wrote: > > Let's assume for the sake of argument that two people auditing > the same code section will find the same set of bugs. So, how > to account for the fact that obvious errors persist for long > periods of time in popular code bases? It must be that those > sections were never properly audited, since by hypothesis > the bugs are obvious and yet were not found. However, this > happens fairly often, which suggests that coverage must > be pretty bad. Accordingly, it's easy to see how you could > get low re-finding rates even if people roughly think alike.
Actually, I think that in this regard the answer lies in a sort of critical mass of interest. Ideas about where to look for what sort of bug (or which sections of code to revisit, perhaps because a relevant new fundamental technique has appeared in the literature, or someone else's parser has added a popular feature, or because a protocol specification has changed) tend to propagate through the population of experts who might find bugs slowly at first, and then faster and faster in what's probably an exponential way. This suggests to me that if I happen to be out in front of the curve in casting my eyes over code fragment _X_ or _Y_ (either because of random luck or because I'm at the front of the wave of interest), I'd really better fix what I can, and make that fix public; because trailing out behind me are many, many more people each of whom has _some_ chance of finding the bug that is correlated in a nonzero way with my having found it. I think that this sort of thing is going to turn out to be _very_ hard to tease out evidence for or against using naive studies of bug commission, discovery, or rediscovery rates; but it is my intuition based on many years of making, finding, and fixing bugs, and of watching others eventually redo my work in the cases in which I'd managed to fail to let them know about it. I would argue that in fact this pattern is not the exception; it is the rule. Thor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]