Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2
Date: Thu, 18 Jan 2007 04:52:44
Message-Id: eomuap$q95$1@sea.gmane.org
In Reply to: Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2 by "Hemmann
1 "Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted
2 200701172222.16480.volker.armin.hemmann@××××××××××××.de, excerpted below,
3 on Wed, 17 Jan 2007 22:22:16 +0100:
4
5 > NVIDIA was made aware of a problem with our 1.0-8774 driver that caused an X
6 > Server crash on July 2006 through a posting on nvnews.net. The problem was
7 > not identified as a security risk.
8
9 This is the core of the problem, right here.
10
11 Putting it in non-technical terms, if the program is caused to crash, by
12 definition, it performed an action the programmer hadn't anticipated, or
13 it would have been tested for and dealt with. Since a non-trivial number
14 of these crashes are known to have security implications, and we've just
15 demonstrated that the programmer hadn't anticipated the issue and thus
16 couldn't protect against it, any such crash must be treated as a potential
17 security issue until proven otherwise. Since it's generally easier, for
18 someone who has the code anyway, to just find and fix the bug than to
19 demonstrate whether it's a security issue or not, that's what usually
20 happens, and it's never known whether it was a security issue.
21
22 Any crash of a native machine coded binary must be assumed to have
23 security implications unless it is demonstrable that's not the case, and
24 prioritized accordingly. Since this one WAS a security issue, that could
25 not be demonstrated, and NVidia erred in treating it as a
26 non-security-issue bug. Had they acted correctly, they would have treated
27 it as a potential security issue, giving it according priority while
28 fixing it, and released the bug-fix as a potential security fix, even if
29 the issue had never been confirmed as a security vuln.
30
31 This demonstrates quite well one of the issues with binary-only code, too.
32 First, virtually all non-trivial code, proprietary source or FLOSS, very
33 reasonably comes with a disclaimer absolving the author of responsibility
34 if the code does something unintended. It would be insane to do
35 otherwise, given the difficulty of anticipating all possible situations
36 under which the code might be used. That's not a problem and as I said is
37 pretty much universal in the software industry, open source or not.
38
39 However, while open code (viewable without NDA or the like) gives the user
40 the ability to verify for themselves the degree of risk, or have someone
41 they trust do it if they don't have the skills themselves to do it,
42 "black-box" proprietary code not only disclaims any responsibility for
43 problems, but provides no way for the user to do his own evaluation (or
44 arrange for a party he trusts to do so). The user is asked to agree to
45 absolve the author of responsibility, while no method is provided for same
46 user to intelligently ascertain for themselves what's in that black box
47 they are being asked to take responsibility for themselves! IMO, that's
48 INSANE, and one reason I can never agree to the EULA most proprietary
49 software requires one agree to.
50
51 While I agree it's unreasonable to NOT have a disclaimer absolving the
52 author of responsibility for damages, I'm not going to absolve someone
53 from responsibility for their code without first having the ability to
54 check it myself, or have someone of my choosing do so. That by definition
55 then excludes from consideration anything closed source, since they very
56 reasonably only let me run it on condition I absolve them of
57 responsibility for what it might do, but (IMO) unreasonably expect me to
58 simply do so with no ability to have a look at what the code might do
59 myself, or have someone I trust have a look at it for me.
60
61 As it happens, I don't personally have the skills to verify the quality and
62 security of the code. However, that "someone I trust" is the FLOSS
63 community, including the authors willing to put their source code out
64 there for examination in the first place. By contrast, I do NOT trust
65 authors not willing to take that step, yet still require me to agree they
66 have no responsibility if the code doesn't work as intended if I choose to
67 use their programs, so I just choose not to make those agreements, and
68 consequently can't use their programs.
69
70 --
71 Duncan - List replies preferred. No HTML msgs.
72 "Every nonfree program has a lord, a master --
73 and if you use the program, he is your master." Richard Stallman
74
75 --
76 gentoo-amd64@g.o mailing list

Replies

Subject Author
Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2 "Hemmann
RE: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2 Bob Young <BYoung@××××××××××.com>
Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2 Peter Humphrey <prh@××××××××××.uk>