Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

On Thursday 18 January 2007 05:50, Duncan wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted
> 200701172222.16480.volker.armin.hemmann@××××××××××××.de, excerpted below,
>
> on  Wed, 17 Jan 2007 22:22:16 +0100:
> > NVIDIA was made aware of a problem with our 1.0-8774 driver that caused
> > an X Server crash on July 2006 through a posting on nvnews.net.  The
> > problem was not identified as a security risk.
>
> This is the core of the problem, right here.
>
> Putting it in non-technical terms, if the program is caused to crash, by
> definition, it performed an action the programmer hadn't anticipated, or
> it would have been tested for and dealt with.  Since a non-trivial number
> of these crashes are known to have security implications, and we've just
> demonstrated that the programmer hadn't anticipated the issue and thus
> couldn't protect against it, any such crash must be treated as a potential
> security issue until proven otherwise.  Since it's generally easier, for
> someone who has the code anyway, to just find and fix the bug than to
> demonstrate whether it's a security issue or not, that's what usually
> happens, and it's never known whether it was a security issue.
>

douzends of programms crash every second, without any security implications. 
SOME are problems, but most are just a crash.

> Any crash of a native machine coded binary must be assumed to have
> security implications unless it is demonstrable that's not the case, and
> prioritized accordingly. Since this one WAS a security issue, that could
> not be demonstrated, and NVidia erred in treating it as a
> non-security-issue bug.  Had they acted correctly, they would have treated
> it as a potential security issue, giving it according priority while
> fixing it, and released the bug-fix as a potential security fix, even if
> the issue had never been confirmed as a security vuln.

yeah, and nvidia has also thousands of programmers and developers just for 
linux drivers, right? And every single of them should be a genius who sees 
the security problems of all bugs.

> This demonstrates quite well one of the issues with binary-only code, too.
> First, virtually all non-trivial code, proprietary source or FLOSS, very
> reasonably comes with a disclaimer absolving the author of responsibility
> if the code does something unintended.  It would be insane to do
> otherwise, given the difficulty of anticipating all possible situations
> under which the code might be used.  That's not a problem and as I said is
> pretty much universal in the software industry, open source or not.
>
> However, while open code (viewable without NDA or the like) gives the user
> the ability to verify for themselves the degree of risk, or have someone
> they trust do it if they don't have the skills themselves to do it,
> "black-box" proprietary code not only disclaims any responsibility for
> problems, but provides no way for the user to do his own evaluation (or
> arrange for a party he trusts to do so).  The user is asked to agree to
> absolve the author of responsibility, while no method is provided for same
> user to intelligently ascertain for themselves what's in that black box
> they are being asked to take responsibility for themselves!  IMO, that's
> INSANE, and one reason I can never agree to the EULA most proprietary
> software requires one agree to.


blablabla. 

Lots of words and political agenda.

Fact is, that ALL non trivial software has bugs. Every single kind. 

So, does firefox had sec vulnerabilites in the past? Oh yes. Xpdf? Xorg?
Yes.
The kernel?
Oh yes, almost monthly such vulnerabilietes are reported.

How many people read the code?
almost noone. 
All that 'the user can read the code and look and fix for himself' is nice, 
but wishfull thinking. Most people can't read code. And most of the people 
you can, don't do it or don't find the bugs themselves.

You see lots of Open Source projects, where the security firms need to show 
them their bugs. Why? The devs should find them? Right? Or all the people 
reading the code before downloading and using it?


>
> As it happens, I don't personally have the skills to verify the quality and
> security of the code.

yeah, that is a surprise. Not.

> However, that "someone I trust" is the FLOSS
> community, including the authors willing to put their source code out
> there for examination in the first place.

and still there are lots of bugs in open source software. Lots of bugs leading 
to lots of security problems. Hm.

So much text from you, but where is the 'I was wrong, sorry'?

Even if nvidia should have recognized the bug as a serious problem the moment 
it was reported, they delivered the bugfix in 3 month, 3 days after they got 
informed that it was security problem.  And they did not 'cover it up'.

So  stop spreading FUD, stop slander companies, and please, please stop using 
the term 'slaveryware'. Oh, and a little bit less of preaching, ok?
-- 
gentoo-amd64@g.o mailing list