671–680 of 913 posts
Does Google seriously not have a whole team of people who help maintain ffmpeg?
The only reasonable way is for Google and other big corps to either sponsor members of the existing team or donate money to the project. And making it long term not one-shotting for publicity.
Does Google seriously not have a whole team of people who help maintain ffmpeg?
https://github.com/search?q=repo%3AFFmpeg%2FFFmpeg+google.co...
Earlier quoted context omitted.
If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.
It's not a rumor, you literally wrote that on X. The average person would understand it as a threat.
Here's a thread by Google's head of security that notes the ways they've contributed to FFmpeg over the years: https://x.com/argvee/status/1986194852669964528
https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
Earlier quoted context omitted.
From my time working at a Fortune 100 company, if I ever mentioned pushing even small patches to libraries we effing used , I'd just be met "try to focus on your tickets". Their OSS library and policies were also super byzantine, seemingly needing review of everything you'd release, but the few times I tried to do it the official way, I just never heard anything back from the black-hole mailing list you were supposed…
Those aren’t tech giants. They're just shit companies. I agree they greatly outnumber Big Tech, in employees if not talent.
Earlier quoted context omitted.
why are the standards and expectation different for google vs an independent researcher? Just because they are richer, doesn't mean they should be held to a standard that isn't done for an independent researcher. The OSS maintainer has the responsibility to either fix, or declare they won't fix - both are appropriate actions, and they are free to make this choice. The consumer of OSS should have the right to know wha…
They are different because the independent researchers don't make money off the projects that they investigate.
but they make money off the reputational increase they earn for having their name attached to the investigation. Unless the investigation and report is anonymous and their name not attached (which, could be true for some researchers), i can say that they're not doing charity.
The problem is the pressure to fix the bugs in x amount of time otherwise they will be made public. Additionally flooding the team with so many bugs that they can never keep up.
Perhaps the solution is not in do or don't submit but in the way how the patches are submitted. I think a solution would be to have a separate channel for these big companies to submit "flood" bug reports generated by AI, and if those reports won't be disclosed in x amount of time that would also take the pressure of the maintainers, the maintainers can set priories to most pressing issues and keep the backlog of smaller issues that may require attention in the future (or be picked up by small/new contributors).
Earlier quoted context omitted.
And not giving the maintainners reasonable amount of time to fix. This was triggered by recent change of policy on google side.
The timeline is industry standard at this point. The point is make sure folks take security more seriously. If you start deviating from the script, others will expect the same exceptions and it would lose that ability. Sometimes it's good to let something fail loudly to show this is a problem. If ffmpeg doesn't have enough maintainers, then they should fail and let downstream customers know so they have more pressure…
It's not some lone report of an important bug, it's AI spam that put forth security issues at a speed greater than they have resources to fix it.
I 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.