Does Google seriously not have a whole team of people who help maintain ffmpeg?
Yes. But they don’t upstream. Why would they?
Great, they can fix the bugs being filed by another part of their company
FFmpeg to Google: Fund us or stop sending bugs
171–180 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#172Looks 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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#173A bunch of people who make era-defining software for free. A labor of love. Another bunch of people who make era-defining software where they extract everything they can. From customers, transactionally. From the first bunch, pure extraction (slavery, anyone?).
> era-defining software for free
chill, nobody knows what ffmpeg is
Re: FFmpeg to Google: Fund us or stop sending bugs
#174Earlier quoted context omitted.
CVEs aren't caused by bugs?
They are not published in project bug trackers and are managed completely differently so no, personally, I don't view CVE as bug reports . Also, please, don't distrort what I say and omit part of my comment, thank you. Some of them are not even bugs in the traditional sense of the world but expected behaviours which can lead to unsecure side effects.
It seems like you might misunderstand what CVEs are? They're just identifiers.
This was a bug, which caused an exploitable security vulnerability. The bug was reported to ffmpeg, over their preferred method for being notified about vulnerabilities in the software they maintain. Once ffmpeg fixed the bug, a CVE number was issued for the purpose of tracking (e.g. which versions are vulnerable, which were never vulnerable, which have a fix).
Having a CVE identifier is important because we can't just talk about "the ffmpeg vulnerability" when there have been a dozen this year, each with different attack surfaces. But it really is just an arbitrary number, while the bug is the actual problem.
Re: FFmpeg to Google: Fund us or stop sending bugs
#175I understand ffmpeg being angry at the workload but this is how it is with large open source projects. Ffmpeg has no obligation to fix any of this. Open source is a gift and is provided as is. If Google demanded a fix I could see this being an issue. As it is right now it just seems like a bad look. If they wanted compensation then they should change the model, there's nothing wrong with that. Google found a bug, the…
[dead]
Re: FFmpeg to Google: Fund us or stop sending bugs
#176Earlier quoted context omitted.
Exactly. That is why I said easily 100~200k. It will be a rounding error for them. It is actually crazy that Google is not already hiring the main dev to work on ffmpeg with all the use they give it on Youtube. I also wonder if it is maybe used by Netflix also.
> I also wonder if it is maybe used by Netflix also. They do and it is. https://netflixtechblog.com/the-making-of-ves-the-cosmos-mic... https://netflixtechblog.com/for-your-eyes-only-improving-net...
It is really sad that none of Netflix or Google had hired a couple of devs to work full time on ffmpeg.
Re: FFmpeg to Google: Fund us or stop sending bugs
#177Fully on FFmpeg team side, many companies approach to FOSS is only doing so when it sounds good on their marketing karma, leech otherwise. Most of them would just pirate in the old days, and most FOSS licences give them clear conscience to behave as always.
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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#178Earlier quoted context omitted.
That is standard practice. It is considered irresponsible to not publicly disclose any vulnerability. The X days is a concession to the developers that the public disclosure will be delayed to give them an opportunity to address the issue.
Here's the question: Why is Google deliberately running an AI process to find these bugs if they're just going to dump them all on the FFmpeg team to fix? They have the option to pay someone to fix them. They also have the option to not spend resources finding the bugs in the first place. If they think these are so damn important to find that it's worth devoting those resources to, then they can damn well pay for fix…
Google is a significant contributor to ffmpeg by way of VP9/AV1/AV2. It's not like it's a gaping maw of open-source abuse, the company generally provides real value to the OSS ecosystem at an even lower level than ffmpeg (which is saying a lot, ffmpeg is pretty in-the-weeds already).
As to why they bother finding these bugs... it's because that's how Google does things. You don't wait for something to break or be exploited, you load your compiler up with santizers and go hunting for bugs.
Yeah this one is kind of trivial, but if the bug-finding infrastructure is already set up it would be even more stupid if Google just sat on it.
Re: FFmpeg to Google: Fund us or stop sending bugs
#179What is the point of Google's Project Zero? I'm not being dismissive. I understand the imperetive of identifying and fixing vulnerabilities. I also understand the detrimental impact that these problems can potentially have on Google. What I don't understand is the choice to have a public facing project about this. Can anyone shine a light on this?
A lot of their research involves stuff they personally benefit from if they were secure. ffmpeg, libxml2, various kinds of mobile device firmware, Linux kernels and userspace components, you name it.
Their security team gaining experience on other projects can teach them some more diversity in terms of (malware) approaches and vulnerability classes, which can in turn be used to secure their own software better.
For other projects there's some vanity/reputation to be gained. Having some big names with impressive resumes publicly talk about their work can help attract talent.
Lastly, Google got real upset that the NSA spied on them (without their knowledge, they can't help against warrants of course).
Then again, there's probably also some Silicon Valley bullshit money being thrown around. Makes you wonder why they don't invest a little bit more to pay someone to submit a fix.
Re: FFmpeg to Google: Fund us or stop sending bugs
#180Earlier quoted context omitted.
This is a fantastic argument for the universe where Google does not disclose vulnerability until the maintainers had had reasonable time to fix it. In this world the user is left vulnerable because attackers can use published vulnerabilities that the maintainers are to overwhelmed to fix
The user is vulnerable while the problem is unfixed. Google publishing a vulnerability doesn't change the existence of the vulnerability. If Google can find it, so can others. Making the vulnerability public makes it easy to find to exploit, but it also makes it easy to find to fix.
If it is so easy to fix, then why doesn't Google fix it? So far they've spent more effort in spreading knowledge about the vulnerability than fixing it, so I don't agree with your assessment that Google is not actively making the world worse here.