On Fri, Dec 02, 2022 at 06:29:28PM +0000, Peter Stuge wrote: > John Helmert III wrote: > > So much yapping on the mailing lists, and no response in the bug which > > triggered the last rites... > > Apologies if I responed in the wrong forum. I thought on list would > be good, why are those mails on the list if not? > > > > So, Peter, do you use Boa? > > Not right now, but I have before and I might again. > > > > If you do, what niche does it fill that isn't filled by anything else? > > That's a strange question. Why should I agree with or even > reconfigure because of something that is in fact an error? > > I ask you to revert the lastrite not because it would break a use > case of mine but because the CVEs do not apply to boa itself but to > some unknown appliance that uses boa to serve unknown buggy CGI scripts. > > > > There are multiple CVEs for it, is it really on us to discriminate > > between which CVEs are valid and which are not? > > Yes. > > You are obviously /not/ responsible for what bogus CVEs people may > report, but we're all responsible for the commits we create. > > I assume that everyone wants to improve the overall state with each > commit - that we want to make things more correct since that's what > enables reliability, hence yes: it really is on every one of us to > verify our inputs before taking action on them. > > > > We can't possibly hope to do that accurately in all cases. > > Some times it will be easy, other times less easy. > > In this case the CVEs could be dismissed by searching the source code > for the file names in the CVEs. Or by having experience with what the > package provides, in particular that it doesn't include any CGI scripts. > > Maybe the accurate bigger picture is that no (current) Gentoo developer > knows enough about the package and thus can't be expected to action > such bogus CVEs correctly without a couple of minutes of investigation, > which would be too long, then I guess maintainer-needed is the most honest?
No, when a package is believed to be vulnerable, it is not responsible for us to just leave it as maintainer-needed, that's not an accurate reflection of the situation. If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? Or anybody that isn't only a CVE downstream? I also note that very few distributions package Boa: https://repology.org/project/boa/versions This is a good way to measure how many people care about the package (and thus, its security health). If the commercial distributions don't carry a package, nobody cares for it, and thus security issues are unlikely to be tracked and handled well. > The mere existance of CVEs can not be reason enough for any change, > that would mean resignation to fear instead of encouraging rational > behavior as required to actually improve technology. It would also > create incentive for permanent denial-of-service attacks by way of > bogus CVEs manipulating people into incorrect lastrites and other > changes. I don't want that to become common. That's not a real concern. We're not going to last rite something like nginx simply because there's a CVE against it. In the case of Boa, which doesn't seem to have been touched in approaching 20 years, the impact of last rites is minimal. > My question about the lastriting process was not an attack but a > genuine inquiry. The answer I receive so far is something like > "it can't work better because we react indiscriminately to CVEs", > that's an honest answer (thank you!) but not great quality. Does > everyone mostly agree with that policy? It generally can't work better with MITRE being useless in many cases. Yes, the CVEs seem garbage, but I can't say that authoritatively, so I don't. > > Thanks > > //Peter >
signature.asc
Description: PGP signature
