David Crocker wrote:
I don't think this analogy between software development and manufacturing holds.
There are no "manufacturing defects" in software construction
For software:
A design defect is when you correctly implement what you wanted, and you
wanted the wrong thing. A "manufacturing d
Ah,
The age-old Gary vs. jOHN debate. I do believe along the continuum of
architecture-->design-->impl. that I've shown the ability to discern flawed
design from source code in source code reviews.
Cigital guys reading this thread have an advantage in that they know both
the shared and exclusive
> I'm sorry, but it is just not possible to find design flaws by
> staring at code.
I strongly disagree with this, largely because I've done it myself.
It's the primary way I find design flaws in code, in fact.
Even if you add "unmotivated by a misbehaviour example", I've still
done it, though on
Gary McGraw:
> I'm sorry, but it is just not possible to find design flaws by
> staring at code.
My experience is otherwise. Without detailed documentation I can
usually see where in the life cycle the mistake was made: analysis
(e.g., solving the wrong problem), design (e.g., using an inappropria
This thread sure has opened up some lively debate...
Gary McGraw wrote:
As a matter of practice, I usually use the terms that you suggested as
modifiers and say:
implementation bug
design flaw
software defect
FWIW, I like to use the nomenclature "security defect" as an
all-encompassing ter
To cycle this all back around to the original posting, lets talk about
the WMF flaw in particular. Do we believe that the best way for
Microsoft to find similar design problems is to do code review? Or
should they use a higher level approach?
Were they correct in saying (officially) that flaws s
Hi sc-lers,
The new book is being released today and is finally available. For
information on the book see www.swsec.com. You might enjoy reading Dan
Geer's foreword (http://www.swsec.com/book/foreword/), which is both
erudite and entertaining as geer's writing tends to be. The Table of
Content
On 2/2/06, David Crocker <[EMAIL PROTECTED]> wrote:
> If some small bolt in my car fails because the bolt met its manufacturer's
> specification but was not strong enough to withstand the loads it was
> subjected
> to, that is a low-level design error, not a manufacturing error.
I agree.
> Simil
Hi Gary,
In one of your prior posts you mentioned documentation. I believe that the
problem with WMF was that someone had not examined WMF as a postential
source of vulnerabilities, since the embedded code was an legacy capability.
My belief is that one of the keys to finding flaws lies in the p
Wietse Venema wrote:
> My experience is otherwise. Without detailed documentation I can
> usually see where in the life cycle the mistake was made: analysis
> (e.g., solving the wrong problem), design (e.g., using an inappropriate
> solution) or coding.
I tend to agree - for *many* design related
Gary McGraw <[EMAIL PROTECTED]> wrote:
>The new book is being released today and is finally available.
My copy arrived from AW y'day in the mail (there's a story behind how I
got to request it; suffice to say it wasn't quite a routine order), so I
was a little surprised to see that it was only o
Title: The role static analysis tools play in uncovering elements of design
Jeff,
An unpopular opinion I’ve held is that static analysis tools, while very helpful in finding problems, inhibit a reviewer’s ability to find collect as much information about the structure, flow, and idiom of code
Gary McGraw wrote:
> To cycle this all back around to the original posting, lets talk about
> the WMF flaw in particular. Do we believe that the best way for
> Microsoft to find similar design problems is to do code review? Or
> should they use a higher level approach?
>
> Were they correct in sa
Title: Re: [SC-L] Bugs and flaws
I think I would word that
differently. The design defect was when Microsoft decided to allow meta data to
call GDI functions.
Around 1990 when this was
introduced the threat profile was entirely different; the operating system could
trust the metadata.
John, I think this has to do with what you want to achieve when you explore
code.
A static analysis tool is a fancy sort of pattern matcher. If the kinds of
patterns you're interested in aren't that fancy, ("does the program use
function X()?"; "what is the class hierarchy?") then a fancy pattern
"Gary McGraw" <[EMAIL PROTECTED]> wrote:
> To cycle this all back around to the original posting, lets talk about
> the WMF flaw in particular. Do we believe that the best way for
> Microsoft to find similar design problems is to do code review? Or
> should they use a higher level approach?
I'l
The best definition for "flaw" and "bug" I've heard so far is that a flaw is
a successful implementation of your intent, while a bug is unintentional. I
think I've also heard "a bug is small", a flaw is big", but that definition
is awfully squishy.
If the difference between a bug and a flaw is in
Al Eridani <[EMAIL PROTECTED]> wrote:
> If the design says "For each fund that the user owns, do X" and my
> code does X for
> all the funds but it skips the most recently acquired fund, I see it as a
> "manufacturing" error.
>
> On the other hand, if a user sells all of her funds and the design
18 matches
Mail list logo
