On Fri, Dec 2, 2022 at 12:30 PM Peter Stuge <pe...@stuge.se> wrote: > > John Helmert III wrote: > > > > There are multiple CVEs for it, is it really on us to discriminate > > > > between which CVEs are valid and which are not? > > > > > > Yes. > .. > > > > We can't possibly hope to do that accurately in all cases. > > > > > > Some times it will be easy, other times less easy. > .. > > > 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. > > Do you continue to believe that boa has vulnerabilites involving files > and functionality (as mentioned by the maintainer mgorny in #882773#c1) > which do not exist in the package? > > I wanted my mail to change that belief. If I've failed so far can you > tell me how I can accomplish it, ie. what it would take for you to > please revert the lastrite commit?
I'll repaint a narrative: Currently mgorny is the listed maintainer of boa. What if instead of a bunch of CVEs he just decided he had better things to do with his time. He last-rites the package, giving a 90d deadline for the package to find a new owner. No one cares to maintain boa, so no one steps up, and the package is removed after 90d. The fact is that in Gentoo, packages need a maintainer that will do the work to keep the package around. Packages that don't have maintainers have no advocate in the development community, and get removed. Gentoo has taken strides to make things easier (e.g. packages can move to GURU, or be proxy-maintained by community members and stay in ::gentoo.) However, the existing project structure gives maintainers and committers a lot of power to do ..basically whatever. I do not expect these facts to change. The last rights process relies on someone stepping up to care for the package. Either its you (and you find someone to commit your proxy commits), it's some other volunteer, or it's no one (in which case the package goes away.) > > > > If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? > > The CVEs are obviously invalid and yes someone could contribute time > to clean up NVD but I honestly don't think that either upstream or > myself can reasonably be made responsible for invalid CVEs submitted > by third parties. > > > > Or anybody that isn't only a CVE downstream? > > I expect every downstream of everything to apply themselves in order to > improve quality of what they consume, not reduce it. To be clear: It's > also not your job to improve NVD but at least don't lastrite in Gentoo > because of invalid CVEs. > > > > 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). > > I disagree, that's only a good way to measure how many distributions care. > > Each distribution has its own dynamic (but actually distributions also > tend to herd behavior) and especially commercial distributions are more > often than not bound by law to be driven only by profit, with *everything* > else secondary. This includes software quality and/or "security health". I think the current state is that no one with commit access to ::gentoo cares, so it will be removed unless someone changes their mind. > > > > 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. > > This seems based on an assumption that only commercial software has > high value? I could not disagree more with that. > > But if we play out the argument then CVEs for packages not in many > distributions would more likely be invalid than others. While true > in this case I don't find it convincing as a general conclusion. > > These things can all be true at once: > > 1. a package is secure > 2. the package is not popular > 3. a CVE for the package is invalid but not (yet) rejected > 4. another CVE for the package is valid (low severity; still secure) > > Only 1. says something about "security health" (whatever that means). > > I think it's both irresponsible and wrong to indiscriminately give > authority to CVEs. People are wrong on the internet all the time, > some even intentionally, it's not correct to blindly believe CVEs > any more than tweets. > > > > > 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. > > > > 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. > > All packages are equal but some are more equal than others? ;) > > Again: Impact shouldn't matter, correctness should. > > > > > 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. > > What would convince you? > > > Thanks a lot > > //Peter >
