Ariel Waissbein <[EMAIL PROTECTED]> writes: > > > > Roughly speaking: > > If I as a White Hat find a bug and then don't tell anyone, there's no > > reason to believe it will result in any intrusions. The bug has to > > become known to Black Hats before it can be used to mount > > intrusions. This can either happen by Black Hats re-finding it or some > > White Hat disclosing it. So, the question is, at least in part, what > > the likelihood of these happening is... > > > > -Ekr > > > > Eric, > I'd say that the good part comes when the security community learns > from its mistakes, builds a theory around it, and finds conclusive > solutions to well defined and isolated problems. So that examples (bug > reports) give the necessary intuition, they are valuable, and in fact, > necessary.
I think it's importances to distinguish between new classes of bugs and new instances of old bugs. I agree that new classes of bugs are potentially interesting, however, I don't think that this argument applies to the 513th buffer overflow. See S 8.4 of the paper. > My point is that, though your argument may be correct, you > arrive at the conclusion that "bug reporting has no effects" > arbitrarily. I never claimed that. What I said was that the evidence that the positive effects of bug reporting in terms of reduced intrusions did not clearly offset the negative effects of said reporting. > I do not mean to act like the old greeks, interested only in > theoretical problems, and despising the empirical. I'd like to > maintain InfoSec infraestructures safe as of ten years ago. But I will > not get into a discussion on the process of "bug reporting", since the > extensive threads all over cannot settle it. I am confindent that bugs > need to be reported, eventually -the sooner the better. And that it is > the software-development community's job to learn from this continuous > reporting. Doing otherwise is neglecting reality. I'm not sure how to answer this. In my view it's a bad idea to be confident of propositions when one doesn't have empirical data to support them. -Ekr --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
