1 |
John Helmert III wrote: |
2 |
> > > There are multiple CVEs for it, is it really on us to discriminate |
3 |
> > > between which CVEs are valid and which are not? |
4 |
> > |
5 |
> > Yes. |
6 |
.. |
7 |
> > > We can't possibly hope to do that accurately in all cases. |
8 |
> > |
9 |
> > Some times it will be easy, other times less easy. |
10 |
.. |
11 |
> > Maybe the accurate bigger picture is that no (current) Gentoo developer |
12 |
> > knows enough about the package and thus can't be expected to action |
13 |
> > such bogus CVEs correctly without a couple of minutes of investigation, |
14 |
> > which would be too long, then I guess maintainer-needed is the most honest? |
15 |
> |
16 |
> No, when a package is believed to be vulnerable, it is not responsible |
17 |
> for us to just leave it as maintainer-needed, that's not an accurate |
18 |
> reflection of the situation. |
19 |
|
20 |
Do you continue to believe that boa has vulnerabilites involving files |
21 |
and functionality (as mentioned by the maintainer mgorny in #882773#c1) |
22 |
which do not exist in the package? |
23 |
|
24 |
I wanted my mail to change that belief. If I've failed so far can you |
25 |
tell me how I can accomplish it, ie. what it would take for you to |
26 |
please revert the lastrite commit? |
27 |
|
28 |
|
29 |
> If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? |
30 |
|
31 |
The CVEs are obviously invalid and yes someone could contribute time |
32 |
to clean up NVD but I honestly don't think that either upstream or |
33 |
myself can reasonably be made responsible for invalid CVEs submitted |
34 |
by third parties. |
35 |
|
36 |
|
37 |
> Or anybody that isn't only a CVE downstream? |
38 |
|
39 |
I expect every downstream of everything to apply themselves in order to |
40 |
improve quality of what they consume, not reduce it. To be clear: It's |
41 |
also not your job to improve NVD but at least don't lastrite in Gentoo |
42 |
because of invalid CVEs. |
43 |
|
44 |
|
45 |
> I also note that very few distributions package Boa: |
46 |
> |
47 |
> https://repology.org/project/boa/versions |
48 |
> |
49 |
> This is a good way to measure how many people care about the package |
50 |
> (and thus, its security health). |
51 |
|
52 |
I disagree, that's only a good way to measure how many distributions care. |
53 |
|
54 |
Each distribution has its own dynamic (but actually distributions also |
55 |
tend to herd behavior) and especially commercial distributions are more |
56 |
often than not bound by law to be driven only by profit, with *everything* |
57 |
else secondary. This includes software quality and/or "security health". |
58 |
|
59 |
|
60 |
> If the commercial distributions don't carry a package, nobody cares for |
61 |
> it, and thus security issues are unlikely to be tracked and handled well. |
62 |
|
63 |
This seems based on an assumption that only commercial software has |
64 |
high value? I could not disagree more with that. |
65 |
|
66 |
But if we play out the argument then CVEs for packages not in many |
67 |
distributions would more likely be invalid than others. While true |
68 |
in this case I don't find it convincing as a general conclusion. |
69 |
|
70 |
These things can all be true at once: |
71 |
|
72 |
1. a package is secure |
73 |
2. the package is not popular |
74 |
3. a CVE for the package is invalid but not (yet) rejected |
75 |
4. another CVE for the package is valid (low severity; still secure) |
76 |
|
77 |
Only 1. says something about "security health" (whatever that means). |
78 |
|
79 |
I think it's both irresponsible and wrong to indiscriminately give |
80 |
authority to CVEs. People are wrong on the internet all the time, |
81 |
some even intentionally, it's not correct to blindly believe CVEs |
82 |
any more than tweets. |
83 |
|
84 |
|
85 |
> > The mere existance of CVEs can not be reason enough for any change, |
86 |
> > that would mean resignation to fear instead of encouraging rational |
87 |
> > behavior as required to actually improve technology. |
88 |
> |
89 |
> That's not a real concern. We're not going to last rite something like |
90 |
> nginx simply because there's a CVE against it. In the case of Boa, |
91 |
> which doesn't seem to have been touched in approaching 20 years, the |
92 |
> impact of last rites is minimal. |
93 |
|
94 |
All packages are equal but some are more equal than others? ;) |
95 |
|
96 |
Again: Impact shouldn't matter, correctness should. |
97 |
|
98 |
|
99 |
> > The answer I receive so far is something like |
100 |
> > "it can't work better because we react indiscriminately to CVEs", |
101 |
> > that's an honest answer (thank you!) but not great quality. Does |
102 |
> > everyone mostly agree with that policy? |
103 |
> |
104 |
> It generally can't work better with MITRE being useless in many |
105 |
> cases. Yes, the CVEs seem garbage, but I can't say that |
106 |
> authoritatively, so I don't. |
107 |
|
108 |
What would convince you? |
109 |
|
110 |
|
111 |
Thanks a lot |
112 |
|
113 |
//Peter |