Gentoo Archives: gentoo-dev

From: John Helmert III <ajak@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Last rites: www-servers/boa
Date: Fri, 02 Dec 2022 20:46:41
Message-Id: Y4pkKrHWDn4nSQzA@gentoo.org
In Reply to: Re: [gentoo-dev] Last rites: www-servers/boa by Peter Stuge
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 >

Attachments

File name MIME type
signature.asc application/pgp-signature