| |||||||||||||
|
| |||||||||||||
IssueIssuePosted Jul 9, 2008 18:58 UTC (Wed) by ncm (subscriber, #165)Parent article: Dan Kaminsky Discovers Fundamental Issue In DNS: Massive Multivendor Patch Released (Securosis.com)
Why can't we call a flaw a flaw? "Issue" is corporate-speak, drained of sense. Yes, I know that the headline comes from the original source. The guilty party appears to be Dan Kaminsky himself. Kudos to Jake for translating correctly to English in the squib text.
(Log in to post comments)
Issue Posted Jul 9, 2008 20:55 UTC (Wed) by nix (subscriber, #2304) [Link] I have been castigated in the past for calling bugs bugs. Apparently customers think our code is bug-free as long as we don't call the, er, `issues' they report `bugs', even if they called them exactly that. (sheesh, ridiculous magical thinking: or, rather, typical bleaching: expect `issue' to go this way in ten years or so).
defect / fault / failure Posted Jul 10, 2008 2:46 UTC (Thu) by zooko (subscriber, #2589) [Link] If we're talking about a problem that exists in the design of DNS or in a particular implementation, we should call it a "defect" (this is the standard term among the safety engineers for what we programmers informally call a "bug"). If we're talking about a problem that exists at run-time, when something goes wrong internally, we should call it a "fault". If we're talking about somebody getting ripped off because they relied on DNS and a criminal exploited DNS, then we should call it a "failure". It is useful to make these distinctions among different kinds of problems, and using the word "defect" instead of "bug" makes it easier to communicate accurately with safety engineers from other disciplines. (Also, as Eric Hughes suggested to me many years ago, there may be a psychological benefit of this terminology -- a "bug" sounds like something endogeneous, but a "defect" is clearly the responsibility of the engineer who designed the system.) defect -- A flaw in a system or system component that has the potential to cause that system or component to fail to perform its required function during execution, [Jones - IBM]. ( Reference : SEI:SE-CMM) fault -- an incorrect step, process or data definition in a computer program ( Reference : ISO/IEC JTC1/SC7:14598-1) failure -- The inability of a system or component to perform its required functions within specified performance requirements. [IEEE STD 610.12-1990] ( Reference : SEI:SE-CMM) references: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=... http://www.totalmetrics.com/cms/servlet/main?Subject=List... http://en.wikipedia.org/wiki/Safety_engineering IEEE 610.12-1990, "IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries"
defect / fault / failure Posted Jul 10, 2008 5:09 UTC (Thu) by ncm (subscriber, #165) [Link] I suppose that leaves "flaw" for cases where you can't or don't want to say which it is.
defect / fault / failure Posted Jul 11, 2008 16:45 UTC (Fri) by giraffedata (subscriber, #1954) [Link] People like to use the term "bug" for its connotation even when its denotation doesn't apply. "Bug" connotes something bad; something that should embarass someone; something that should be fixed. But its traditional denotation is a programming defect, as distinct from a higher level design defect. Nobody's saying what this DNS issue is, so I don't know if it's a bug or not, but it sounds to me like the code is all functioning as its designers meant it to, and just not meeting the requirements of today's deployments. I would not use the word "bug" myself. Also, I'm not sure from what I've read that it's universally regarded as a defect. Are there people defending the existing function? If so, it's more objective to call it an issue than a defect. An issue is not a euphemism for bug, default, fault, etc. An issue is something people are thinking about.
defect / fault / failure Posted Jul 11, 2008 17:01 UTC (Fri) by giraffedata (subscriber, #1954) [Link] fault -- an incorrect step, process or data definition in a computer program ( Reference : ISO/IEC JTC1/SC7:14598-1) This is a pretty bad definition; it doesn't capture the essential difference between a defect and a fault as the terms are commonly used and as used in the other references. There's a simple distinction: a defect is a state and a fault is an event. If my email sending program doesn't check the divisor for 0 before dividing by it, that's a defect in the program. Each time I run the program and it crashes because it divides by zero, that's a fault in my sending of the email. If I don't have some way to recover and get the email out anyway, it's also a failure in my sending of the email.
The defect is being patched, the issue remains Posted Jul 10, 2008 14:02 UTC (Thu) by copsewood (subscriber, #199) [Link] Dan Kaminsky didn't discover the basic problem with the design of DNS or implementations of it. This was known about years ago, to the extent DJB was aware of it and worked around it to make DJBDNS not vulnerable to the same extent other unpatched DNS implementations are. Kaminsky appears to have discovered an attack which exploits the problem in a more devastating manner than previously known possible. The basic defect in DNS isn't solved by the current set of patches. DNS without DNSSEC, even if further third party cache-poisoning exploits are not discovered, still depends upon trust in a chain of middlemen DNS caching servers in order to communicate authoritative DNS information from DNS content servers to clients. So the wider issue of insecurity inherent within the design of DNS itself remains. The additional entropy provided by these patches makes a class of technical attacks by outsiders more difficult, but this simply delays the inevitable need to transition to DNSSEC at some point in the future.
|
|
||||||||||||