What happens if ffmpeg ignores (after triage) the minor CVEs?
Life goes on.
FFmpeg to Google: Fund us or stop sending bugs
261–270 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#262Never work for free. It's a complete market distortion and leads to bad actors taking advantage of you and your work.
Sometimes it's hard: for many kinds of projects, I don't think anyone would use them if they were not open source (or at least source-available). Just like I wouldn't use a proprietary password manager, and I wouldn't use WhatsApp if I had a choice. Rather I use Signal because it's open source.
How to get people to use your app if it's not open source, and therefore not free?
For some projects, it feels better to have some people use it even if you did it for free than to just not do it at all (or do it and keep it in a drawer), right?
I am wondering, I haven't found a solution. Until now I've been open sourcing stuff, and overall I think it has maybe brought more frustration, but on the other hand maybe it has some value as my "portfolio" (though that's not clear).
Re: FFmpeg to Google: Fund us or stop sending bugs
#263Earlier quoted context omitted.
> But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it I think this is the heart of the issue and it boils off all of the unimportant details. If it's a real, serious issue, you want to know about it and you want to fix it. Regardless of who reports it. If it's a real, but unimportant issue, you probably at least want to track it, but are…
But if it's a real, serious issue without an easy resolution, who is the burden on? It's not that the maintainers wouldn't fix bugs if they easily could. FFmpeg is provided "as is"[0], so everyone should be responsible for their side of things. It's not like the maintainers dumped their software on every computer and forced people to use it. Google should be responsible for their own security. I'm not adamant that Go…
Well, it's open source and built by volunteers, so nobody is obligated to fix it. If FFmpeg volunteers don't want to fix it or don't have the time/bandwidth to fix it, then they won't fix it. Like any other bug or CVE in any other open source project. The burden doesn't necessarily need to be on anyone.
Re: FFmpeg to Google: Fund us or stop sending bugs
#264From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and liste…
I've been a proponent of upstreaming fixes for open source software.
Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do.
Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate.
I have a very distinct recollection of talks about hardware aspirations and upstreaming software fixes at a large company. The cultural response was jarring.
Re: FFmpeg to Google: Fund us or stop sending bugs
#265Earlier quoted context omitted.
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.
There should be a "if you use this product in a for-profit environment, and you have a yearly revenue of $500,000,000,000+ ... you can afford to pay X * 100,000/yr" license.
That's the Llama license and yeah, a lot of people prefer this approach, but many don't consider it open source. I don't either.
In fact, we are probably just really lucky that some early programmers were kooky believers in the free software philosophy. Thank God for them. So much of what I do owes to the resulting ecosystem that was built back then.
Re: FFmpeg to Google: Fund us or stop sending bugs
#266Earlier quoted context omitted.
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.
What is the mission of Project Zero? Is it to build a vulnerability database, or is it to fix vulnerabilities?
If it's to fix vulnerabilities, it seems within reason to expect a patch. If the reason Google isn't sending a patch is because they truly think the maintainers can fix it better, then that seems fair. But if Google isn't sending a patch because fixing vulns "doesn't scale" then that's some pretty weak sauce.
Maybe part of the solution is creating a separate low priority queue for bug reports from groups that could fix it but chose not to.
Re: FFmpeg to Google: Fund us or stop sending bugs
#267Earlier 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. That is not an accurate description? Project Zero was using a 90 day disclosure policy from the start, so for over a decade. What changed[0] in 2025 is that they disclose earlier than 90 days that there is an issue ,…
When you publicize a vulnerability you know someone doesn't have the capacity to fix according to the requested timeline, you are simultaneously increasing the visibility of the vulnerability and name-calling the maintainers. All of this increases the pressure on the maintainers, and it's fair to call that a "demand" (quotes-included). Note that we are talking about humans who will only have their motivation dwindle:…
> When you publicize a vulnerability you know someone doesn't have the capacity to fix according to the requested timeline
My understanding is that the bug in question was fixed about 100 times faster than Project Zero's standard disclosure timeline. I don't know what vulnerability report your scenario is referring to, but it certainly is not this one.
> and name-calling the maintainers
Except Google did not "name-call the maintainers" or anything even remotely resembling that. You just made it up, just like GP made up the the "demands". It's pretty telling that all these supposed misdeeds are just total fabrications.
Re: FFmpeg to Google: Fund us or stop sending bugs
#268Earlier quoted context omitted.
All the license means is that I can’t sue them. It doesn’t mean I have to like it. Just because software makes no guarantees about being safe doesn’t mean I want it to be unsafe.
If the software makes no guarantees about being safe, then you should assume it is unsafe.
Have you ever used a piece of software that DID make guarantees about being safe?
Every software I've ever used had a "NO WARRANTY" clause of some kind in the license. Whether an open-source license or a EULA. Every single one. Except, perhaps, for public-domain software that explicitly had no license, but even "licenses" like CC0 explicitly include "Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work ..."
Re: FFmpeg to Google: Fund us or stop sending bugs
#269Earlier 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
This program discloses security issues to the projects and only discloses them after they have had a "reasonable" chance to fix it though, and projects can request extensions before disclosure if projects plan to fix it but need more time. Google runs this security program even on libraries they do not use at all, where it's not a demand, it's just whitehat security auditing. I don't see the meaningful difference bet…
Google is a multi-billion dollar company, which is paying people to find these bugs in the first place.
That's a pretty core difference.
Re: FFmpeg to Google: Fund us or stop sending bugs
#270There are some rhetorical slights of hand. If Google does the work to find and report vulnerabilities, great. Nice contribution regardless of who provides it. The OSS developer can ignore it by accepting the consequences that will be. They are not forced to fix it except by themselves.
The many large corporations should be funding these tools they depend on to increase time allocations and thus ability to be responsive but this isn't an either/or. These type of thinking erode the communities of such projects and minds of the contributors.
FWIW I've totally been that developer trapped in that perspective so I empathize, there are simply better mental stances available.