Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!uudell!Kepler!mjhammel From: mjhammel@Kepler.dell.com (Michael J. Hammel) Newsgroups: comp.unix.sysv386 Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386 Message-ID: <15342@uudell.dell.com> Date: 20 Feb 91 23:38:34 GMT References: <113@calcite.UUCP> <446@bria> <15297@uudell.dell.com> Sender: news@uudell.dell.com Reply-To: mjhammel@Kepler.dell.com (Michael J. Hammel) Organization: Dell Computer Corp. Lines: 53 In article <113@calcite.UUCP>, vjs@calcite.UUCP (Vernon Schryver) writes: > In article <15297@uudell.dell.com>, mjhammel@Kepler.dell.com (Michael J. Hammel) writes: > > .... Why can't the reseller expect that > > the original developer had fully tested the original product? > > Have I correctly inferred that the author either works in a testing > organzation or in a non-technical or at least non-software capacity at Dell? > Test engineer. Software and Hardware in R&D. > There is no plausible test that would have found the big, bad bug. Please > don't suggest a program that would write to all possible invalid pages in > the hope of causing something unexpected without providing a way to do that > quickly enough to be useful, and with a way to reliably detect that > something more interesting than the FP registers were trashed. > I misrepresented what I was trying to say. I wasn't suggesting that the particular bug that has been discussed lately could have been found this way. Its just that its oftern hard to point to *exactly* who should be responsible for some problem when various groups have their fingers in the code. Besides, I've learned, as a test engineer, that pointing doesn't solve the problem. In fact, it often slows the fixes development. As a tester, however, I can't help but point at myself for a bug that gets by. After all, its my *job* to find bugs. > There has been enduring interest in proofs of correctness, ADA, and the > rest of the "constructive" software reliablity stuff, because testing finds > only a minority of the bugs. Testing is good for knowing if an old bug has > reappeared and for knowing if the build was a complete failure. That's all. > I wouldn't say its that unimportant. A major part of testing (it shouldn't be this way, but often ends up like this) is to uncover the bugs "on the surface" so the product looks good to the user. The more important (often more destructive) bugs take longer to find (either by automated testing or just be sheer accident) and often don't get found because of time constraints to get a product to market. I suppose it depends on how one views "testing", as a non-technical part of the development process, or a more sophisticated and integral part of the development process (thats not a good description, but I think you understand what I mean). We should probably move this discussion to comp.software-eng. Or email me if you'd liked to talk more about it. Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Lead, follow, or get the hell out of the way."