bugtraq - Re: Update: Web browsers - a mini-farce (MSIE gives in)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20041029183410.3affeb19.infamous41md@hotpop.com>
Date: Fri, 29 Oct 2004 18:34:10 -0400
From: infamous41md@...pop.com
To: bugtraq@...urityfocus.com
Subject: Re: Update: Web browsers - a mini-farce (MSIE gives in)


I've been following this discussion with a complete sense of shock and amazment.
Why are you people making up excuses for crap ass programming?  It IS NOT
ACCEPTABLE, and if you keep putting forth the notion that it is, nothing is
going to change.  The fact that a browser cannot accomplish its fundamental
purpose without crashing and burning is, well, pathetic.  Now, I'm the first to
admit that I'm new and rather inexperienced to this game, BUT, regardless of
that, you don't need an "expert" in automotive technology to tell you that a new
car shouldn't lose all control, and fly off the road when the ground is a bit
slick.  Why is that? Well, I imagine they TEST FOR THOSE TYPES OF THINGS.  If
these browser manufacturers applied the same BASIC principles, and wrote a
SIMPLE (but excellent) tool like Michael's to test their products before
releasing them, well maybe we wouldn't be here right now.

Making arguments like "oh we can't possibly find every bug, so why try at all"
is just stupid.  Yes, that was an exaggeration, but so was the original comment
made.  Obviously we are all humans, and the best of us make the stupidest
mistakes, I sure know that I do.  However, trying to downplay the significance
of bugs like these by blaming "time contstraints" is a feeble attempt to avoid
the real issue at hand.  I don't think anyone is asking for silver bullets here
-more like simple and basic verifications of a product.  Other industries are
held up to certain standards, and frankly I think the software industry should
be as well.

* dons flame-retardant suit and boots, and sets hose to full blast *

On Fri, 29 Oct 2004 15:38:51 -0400
Valdis.Kletnieks@...edu wrote:

> On Fri, 29 Oct 2004 15:25:26 EDT, David Brodbeck said:
> 
> > This suggests that it's reasonable for a program to segfault because the
> > user made a mistake, instead of having some non-fatal form of error
> > handling.  I don't think that should be acceptable at all, though I agree
> > it's very common.  If I had a dollar for every time I've lost work because a
> > segfault or GPF happened before I saved my document...
> 
> The problem is that if you say "it isn't acceptable at all", then you *VERY*
> quickly end up with almost *NO* software that's "acceptable".
> 
> All software is buggy. *ALL* of it.  Learn to accept it. Making a "this is not
> acceptable" declaration about something that in general is not totally
> preventable is just doomed to failure.
> 
> Also, remember that programmer time is *FINITE*.  Would you have been willing
> to not have the last 3 "this is indispensable" features in your favorite
> software in order that the programmers track down every single possible
> failure mode?  Would you give up 2? 1?
> 
> Most software projects could probably fairly easily eliminate (rough guess)
> some 75-90% of the really bonehead errors via better programming methodology
> and automated software testers/verifiers - but after that, it's going to be
> *really* hard to get much further improvement.
> 
> There are no silver bullets....
> 
> 


-- 
-sean