Here's a thread by Google's head of security that notes the ways they've contributed to FFmpeg over the years:
FFmpeg to Google: Fund us or stop sending bugs
181–190 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#182Earlier quoted context omitted.
Sounds like it would be a lot of churn for nothing; if they can fund a fork, then they could fund the original project, no?
They COULD, but history has shown they would rather start and maintain their own fork. It might not make sense morally, but it makes total sense from a business perspective… if they are going to pay for the development, they are going to want to maintain control.
If they want that level of control, reimburse for all the prior development too. - ie: buy that business.
As it stands, they're just abusing someone's gift.
Like jerks.
Re: FFmpeg to Google: Fund us or stop sending bugs
#183Is it time for FFmpeg to relicense as AGPL? That'd be fun to witness.
It'll just get forked (see terraform)
Re: FFmpeg to Google: Fund us or stop sending bugs
#184Never work for free. It's a complete market distortion and leads to bad actors taking advantage of you and your work.
[dead]
Re: FFmpeg to Google: Fund us or stop sending bugs
#185Earlier quoted context omitted.
Google is, at no cost to FFMPEG: 1) dedicating compute resources to continuously fuzzing the entire project 2) dedicating engineering resources to validating the results and creating accurate and well-informed bug reports (in this case, a seriously underestimated security issue) 3) additionally for codecs that Google likely does not even internally use or compile, purely for the greater good of FFMPEG's user base Nee…
Then they can surely also provide a pull request for said CVE.
Where do you draw the line? Do you want Google to just not inspect any projects that it can't fully commit to maintaining?
Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor.
Re: FFmpeg to Google: Fund us or stop sending bugs
#186Earlier quoted context omitted.
If you're going to fix the bug, why not in the main project?
Any time I have tried to fix a bug in an open source project I was immediately struck down with abusive attitudes about how I didn't do something exactly the way they wanted it that isn't really documented. If that's what I have to expect, I'd rather not even interact with them at all.
[deleted]
Re: FFmpeg to Google: Fund us or stop sending bugs
#187Earlier quoted context omitted.
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’…
On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? I mean someone could already be using the vulnerability regardless of what Google does.
As clearly stated, most users of ffmpeg are unaware of them using it. Even them knowing about a vulnerability in ffmpeg, they wouldn't know they are affected.
Really, the burden is on those shipping products that depend on ffmpeg: they are the ones who have to fix the security issues for their customers. If Google is one of those companies, they should provide the fix in the given time.
Re: FFmpeg to Google: Fund us or stop sending bugs
#188Earlier quoted context omitted.
Irrespective of what Google does, security research is still useful for all of us. They could adopt a more flexible policy for FOSS though.
Or they could contribute solutions to said bugs? Its not like they would distract that much from their bottom line
Google is a major contributor to open-source video, to the point where it would not be viable without them.
Re: FFmpeg to Google: Fund us or stop sending bugs
#189Looks like this was a security issue. I don't consider a security issue to be a "standard bug." I need to look at it, and [maybe] fix it, regardless of who reported it. But in my projects, I have gotten requests (sometimes, demands) that I change things like the published API (a general-purpose API), to optimize some niche functionality for one user. I'll usually politely decline these, and respond with an explanatio…
It’s a security issue for a stream type almost nobody uses. It’s a little like saying your graphics program in 2025 is exploitable by a malformed PCX file, or your music player has a security bug only when playing an Impulse Tracker module. Sure, triage it. It shouldn’t be publicly disclosed within a week of the report though, because the fix is still a relatively low priority.
Security is adversarial. It doesn't matter whether the users intentionally use the vulnerable codec. What matters is whether an adversary can make the users to use it. Given the codec is compiled in by default on Ubuntu, and given that IIUC the bug would already be triggered by ffmpeg's file format probing, it seems pretty likely that the answer to that is yes.