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