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 |