Its a special kind of irony to post AI slop complaining about someone's ai slop that isn't actually ai slop just devs whining about being expected to maintain their code instead of being able to extort the messengers to do the work for them.
FFmpeg to Google: Fund us or stop sending bugs
21–30 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#22Not too fond of maintainers getting too uppity about this stuff. I get that it can be frustrating to receive bug report after bug report from people who are unwilling or unable to contribute to the code base, or at the very least to donate to the team. But the way I see it, a bug report is a bug report, no matter how small or big the bug or the team, it should be addressed. I don’t know, I’m not exactly a pillar of t…
It’s not bug reports. It’s CVE. There is a convergence of very annoying trends happening: more and more are garbage found and written using AI and with an impact which is questionable at best, the way CVE are published and classified is idiotic and platform founding vulnerability research like Google are more and more hostile to projects leaving very little time to actually work on fixes before publishing. This is le…
CVEs aren't caused by bugs?
Re: FFmpeg to Google: Fund us or stop sending bugs
#23Not too fond of maintainers getting too uppity about this stuff. I get that it can be frustrating to receive bug report after bug report from people who are unwilling or unable to contribute to the code base, or at the very least to donate to the team. But the way I see it, a bug report is a bug report, no matter how small or big the bug or the team, it should be addressed. I don’t know, I’m not exactly a pillar of t…
When you already work 40+ hours a week and big companies suddenly start an AI snowblower that shoots a dozen extra hours of work every week at you without doing anything to balance that (like, for instance, also opening PRs with patches that fix the bugs), the relationship starts feeling like being an unpaid employee of their project.
What's the point of just showering these things with bug reports when the same tool (or a similar one) can also apparently fix the problem too?
Re: FFmpeg to Google: Fund us or stop sending bugs
#24I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes per…
My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it.
To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’m sure you better than me, that that’s not who volunteering works
Re: FFmpeg to Google: Fund us or stop sending bugs
#25I get the idea of publicly disclosing security issues to large well funded companies that need to be incentivized to fix them. But I think open source has a good argument that in terms of risk reward tradeoff, publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward.
> publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward.
Not publicly disclosing it also carries risk. Library users get wrong impression that library has no vulnerabilities, while numerous bugs are reported but don't appear due to FOSS policy.
Re: FFmpeg to Google: Fund us or stop sending bugs
#26Earlier quoted context omitted.
Do you have evidence of ai slop, or are you just spreading fud? The linked bug was acknowledged as real.
That is completely irrelevant, the gross part is that (if true) they are demanding them to be fixed in a given time. Sounds like the epitome of entitlement to me, to say the least.
No one is demanding anything, the report itself is a 90 day grace period before being publicly published. If the issues are slop then what exactly is your complaint?
Re: FFmpeg to Google: Fund us or stop sending bugs
#27I get the idea of publicly disclosing security issues to large well funded companies that need to be incentivized to fix them. But I think open source has a good argument that in terms of risk reward tradeoff, publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward.
In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. The security issue should certainly be disclosed - when its responsible to do so. Now, if Google or whoever really feels like fixing fast is so important, then they could very well contribute by submitting a patch along with their issue report. Then everybody wins.
> it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days
This is very far from obvious. If google doesn't feel like prioritising a critical issue, it remains irresponsible not to warn other users of the same library.
Re: FFmpeg to Google: Fund us or stop sending bugs
#28Earlier quoted context omitted.
> it can be frustrating to receive bug report after bug report from people As the article states, these are AI-generated bug reports. So it's a trillion-dollar company throwing AI slop over the wall and demanding a 90-day turn around from unpaid volunteers.
Do you have evidence of ai slop, or are you just spreading fud? The linked bug was acknowledged as real.
google literally tells them it's an ai generated report
Re: FFmpeg to Google: Fund us or stop sending bugs
#29Re: FFmpeg to Google: Fund us or stop sending bugs
#30Earlier quoted context omitted.
In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. The security issue should certainly be disclosed - when its responsible to do so. Now, if Google or whoever really feels like fixing fast is so important, then they could very well contribute by submitting a patch along with their issue report. Then everybody wins.
> it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days This is very far from obvious. If google doesn't feel like prioritising a critical issue, it remains irresponsible not to warn other users of the same library.
If that’s the case why give the OSS project any time to fix at all before public disclosure? They should just publish immediately, no? Warn other users asap.