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