public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64]  Re: MAKEOPTS values for Athlon 64 X2
Date: Thu, 18 Jan 2007 04:50:33 +0000 (UTC)	[thread overview]
Message-ID: <eomuap$q95$1@sea.gmane.org> (raw)
In-Reply-To: 200701172222.16480.volker.armin.hemmann@tu-clausthal.de

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200701172222.16480.volker.armin.hemmann@tu-clausthal.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.

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.

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.  

While I agree it's unreasonable to NOT have a disclaimer absolving the
author of responsibility for damages, I'm not going to absolve someone
from responsibility for their code without first having the ability to
check it myself, or have someone of my choosing do so.  That by definition
then excludes from consideration anything closed source, since they very
reasonably only let me run it on condition I absolve them of
responsibility for what it might do, but (IMO) unreasonably expect me to
simply do so with no ability to have a look at what the code might do
myself, or have someone I trust have a look at it for me.

As it happens, I don't personally have the skills to verify the quality and
security of the code.  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.  By contrast, I do NOT trust
authors not willing to take that step, yet still require me to agree they
have no responsibility if the code doesn't work as intended if I choose to
use their programs, so I just choose not to make those agreements, and
consequently can't use their programs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list



  reply	other threads:[~2007-01-18  4:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-15  5:42 [gentoo-amd64] MAKEOPTS values for Athlon 64 X2 PaulNM
2007-01-15  9:17 ` Toshinori Endo
2007-01-15 15:39 ` Thomas Rösner
2007-01-15 18:10   ` [gentoo-amd64] " Duncan
2007-01-15 23:32     ` Thomas Rösner
2007-01-16  8:28       ` Andrei Slavoiu
2007-01-16 10:27         ` Neil Bothwick
2007-01-16 16:15           ` Peter Humphrey
2007-01-17  2:41         ` Thomas Rösner
2007-01-17  7:47           ` Duncan
2007-01-17 12:34             ` Boyd Stephen Smith Jr.
2007-01-17 17:24             ` Hemmann, Volker Armin
2007-01-17 19:02               ` Bernhard Auzinger
2007-01-17 21:22                 ` Hemmann, Volker Armin
2007-01-18  4:50                   ` Duncan [this message]
2007-01-18 16:12                     ` Hemmann, Volker Armin
2007-01-18 16:16                       ` Rob Lesslie
2007-01-18 18:10                         ` Boyd Stephen Smith Jr.
2007-01-18 18:35                           ` Simon Stelling
2007-01-18 19:13                             ` Boyd Stephen Smith Jr.
2007-01-18 19:51                               ` Simon Stelling
2007-01-26  8:49                             ` Peter Humphrey
2007-01-26 23:18                               ` Thomas Rösner
2007-01-18 18:41                       ` Duncan
2007-01-18 18:51                         ` Hemmann, Volker Armin
2007-01-18 19:17                           ` Duncan
2007-01-18 19:36                     ` Bob Young
2007-01-18 19:42                       ` Harry Holt
2007-01-19  7:57                         ` Duncan
2007-01-26  0:46                     ` Peter Humphrey
2007-01-16 11:11       ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='eomuap$q95$1@sea.gmane.org' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-amd64@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox