Gentoo Archives: gentoo-dev

From: Peter Stuge <peter@×××××.se>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Last rites: www-servers/boa
Date: Fri, 02 Dec 2022 23:40:29
Message-Id: 20221202234020.25988.qmail@stuge.se
In Reply to: Re: [gentoo-dev] Last rites: www-servers/boa by Alec Warner
1 Alec Warner wrote:
2 > Currently mgorny is the listed maintainer of boa. What if instead of a
3 > bunch of CVEs he just decided he had better things to do with his
4 > time.
5 > He last-rites the package, giving a 90d deadline for the package to
6 > find a new owner.
7 > No one cares to maintain boa, so no one steps up, and the package is
8 > removed after 90d.
9
10 That would be perfectly fine of course.
11
12 Note that mgorny protested in the lastrite bug way before my mail.
13
14
15 > I think the current state is that no one with commit access to
16 > ::gentoo cares, so it will be removed unless someone changes their
17 > mind.
18
19 That seems accurate.
20
21
22 John Helmert III wrote:
23 > > Do you continue to believe that boa has vulnerabilites involving files
24 > > and functionality (as mentioned by the maintainer mgorny in #882773#c1)
25 > > which do not exist in the package?
26 >
27 > Just like it isn't your responsibility to "cleanup NVD", it's not my
28 > responsibility to authoritatively verify every CVE that Gentoo
29 > Security acts upon.
30
31 Of course not by others in Gentoo Security, but I think it is for
32 inputs that you yourself act on. (Everyone of course and I am mindful
33 to do it too.)
34
35
36 > Even if I did make such a judgement, I will *not* risk my being
37 > wrong and exposing Gentoo users to vulnerabilities unecessarily,
38 > even when prompted to by users on mailing lists.
39
40 Your nginx example seemed to say otherwise.
41
42 It's good to be afraid of being wrong but then please work with
43 trusted peers to feel confident about being right instead of racing
44 to bottom quality.
45
46 Since you don't trust my analysis of both versions of the source code
47 published by upstream please do collect further analysis from peers,
48 so as to not be wrong in the opposite.
49
50
51 > > The CVEs are obviously invalid and yes someone could contribute time
52 > > to clean up NVD but I honestly don't think that either upstream or
53 > > myself can reasonably be made responsible for invalid CVEs submitted
54 > > by third parties.
55 >
56 > Again, we're not making judgements about "obviously invalid".
57
58 I do think Gentoo Security needs to validate. *scratches head*
59
60 This is obviously the most interesting part of this thread.
61
62
63 > The time you've spent arguing with us on gentoo-dev could've been
64 > easily spent asking upstream about the issue.
65
66 I verified the three CVEs to be non-issues, what is there for me to
67 ask upstream about?
68
69 I analyzed the source code before sending my first mail and confirmed
70 that the CVEs do not exist in boa. That's why I sent the mail saying
71 that the reports are false.
72
73 A lastrite commit in Gentoo based on invalid CVEs has little to do
74 with upstream.
75
76 You're reversing the burden of proof based on a false claim.
77
78
79 > > I disagree, that's only a good way to measure how many distributions care.
80 >
81 > Which is *precisely* the point I'm making. If distributions with many
82 > times the resources of Gentoo don't care to package it, that's a bad
83 > indicator of how well the package is taken care of.
84
85 How can you know why someone else does or *doesn't* do something?
86 That's absurd.
87
88
89 > > Each distribution has its own dynamic (but actually distributions also
90 > > tend to herd behavior)
91
92 You really leaned into the herd behavior there. :\
93
94
95 > > Again: Impact shouldn't matter, correctness should.
96 >
97 > And again, I'm generally not going to be validating every CVE ever for
98 > correctness.
99
100 Only those you act on.
101
102
103 > > > It generally can't work better with MITRE being useless in many
104 > > > cases. Yes, the CVEs seem garbage, but I can't say that
105 > > > authoritatively, so I don't.
106 > >
107 > > What would convince you?
108 >
109 > Anything from upstream, or a withdrawal of the CVEs, or a notice from
110 > the CVE reproters that they're invalid. But I really don't understand
111 > why anybody cares about this leaf package that nobody actually seems
112 > to use, including you.
113
114 Imagine that I fork boa to a project called boah, change nothing but
115 the version number, create a release and then tell you again that the
116 three CVEs are invalid for both boa and boah.
117
118
119 //Peter