Security vulnerabilities are different, especially when they also put a 90 day disclosure period in it which is more severe for a security exploit.
That disclosure bit, not in the article, is really what tipped this all over the edge. If it was just hey, here’s a bug then its really just flooding the backlog for the maintainers who need to triage that. Disclosures are often used so people are aware that they’re using libraries that the maintainer has refused to patch, but in this case its really just holding the maintainers hostage so they end up wasting their time going through irrelevant issues.
Ideally, they would either use their supposedly capable and powerful AI code gen to just make a fix and send over a patch, or at least use LLMs on their own end to triage the issues and only send over the most sever X periodically.
Taldan@lemmy.world 3 weeks ago
The truth can absolutely be a bad thing. If google reports an important vulnerability, then buries it in CVE slop for 90 days, and publicly announces details of the important vulnerability that hasn’t been fixed yet, it would be worse than if they had never reported it
The 90-day publishing window is tough when OSS projects are getting buried in AI slop reports
lmmarsano@lemmynsfw.com 3 weeks ago
Then Google would have to put out of the fire of that vulnerability in their dependent software.
Not disclosing a vulnerability doesn’t stop attackers from exploiting it. A report simply indicates someone who noticed bothered to report it.
The problem is the vulnerability. False urgency is nothing more: the maintainers don’t need to “meet the window”. Companies will be left with their pants on fire if they don’t act, too: it’s everybody’s problem. Maintainers can just ignore the window to shift the burden back on moneyed interests as I explained before.
nandeEbisu@lemmy.world 2 weeks ago
Kind of, in this case its a vulnerability in a portion of code that you need to compile with special flags to even include in the library (ie its not in the default build, you need to rebuild it and opt-in) so its super low impact and just ends up giving the maintainers excessive paperwork.
lmmarsano@lemmynsfw.com 2 weeks ago
Again, ignoring/postponing is an option. At work, we’d just move that to the backlog of shit we may never touch: having it there is good as a reminder & for tracking the issue & gathering notes on our thoughts regarding it, which saves time approaching it like new each time it comes up. It’s no different for open source maintainers. Marking an item as won’t fix, deferred, or help wanted or closing redundant items isn’t much paperwork.
Again, the objective reality is the defect exists, and that reality doesn’t change with our awareness of that fact: it’s better to know & track for planning even if the plan is to do nothing.