On the one hand, this one Microsoft employee was probably in a bind and actually blocked by this bug. On some level, it's hard to blame them as an individual.
On the other hand, Microsoft has no leverage here and pays somewhere between a pittance and nothing for FFmpeg, while getting enormous use out of it. If they regularly donated with either money or patches, then there'd be no beef, but it's the expectation of getting something more for free while already getting so damn much for for zero cents that really grinds both mine and FFmpeg's gears.
That reminds me that I should probably throw some money at FFmpeg, if only to clear my conscience.
The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.
Google has literally billions of dollars in profits (in part because they use FFmpeg in a bunch of commercial products like Youtube and Chrome), and one of the largest software workforces in the world, including expertise on secure software and vulnerability remediation.
If anyone can afford to contribute back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.
That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?
The organisation who ships software to paying customer may have a duty to fix security issues. If they didn’t, it could be seen as negligent, violate regulations or the contract they have with their customers. But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
if “a duty” exists at all in this situation, it’s on the 4th wealthiest company in the world who is using that free software to serve its customers and raking in billions of dollars. (i want to be clear tho, that company does contribute a lot to the open source community. a whole lot. i’m just saying, if someone is hunting for a “duty” to fling around re: an open source project)
i was once naively saying some undeserved similar nonsense to a well known open source dev regarding some software package they were working on years ago, and he responded absolutely appropriately, [paraphrasing] “go ahead, you should absolutely do it, see if it’s better. none of us here are stopping you. we genuinely hope it is, truly. let us know. until then we’re working on other stuff.”
he was absolutely correct and i should have known better. not snotty at all, just, “you should totally do it!” that’s the appropriate answer every single time someone behaves as if your open source project owes them something. even more so when it’s the 4th richest company in the world.
so if you feel “a duty” exists somewhere to change something with ffmpeg, do it yourself. literally no one is stopping you. it’s _open source_.
If you want the security issue to be fixed, make a PR or offer the price you are willing to pay for them to fix.
I'm somewhat with you but we're also talking about a $3.4T company that's depending on an OSS project with what... under a $1m budget? It seems they're pretty resource constrained.
I'm pretty sure Google makes more through Chrome's usage of libav than ffmpeg's entire budget. So yeah, I think Google should put effort back in and I think it's in their best interest.
Trillion dollar companies standing on top of open source projects and giving little to nothing back is not okay. It's also just stupid since they're eating their own foundations
> because they use FFmpeg in a bunch of commercial products like Youtube and Chrome
I'm not sure why this is an unpopular idea, but contribute back to your upstream dependencies. If they're a dependency, they're part of *your code*.
Yes, i think there is a moral duty if you are presenting the software for the general public to use. Or if you dont to at least make it clear how you handle stuff so that users can make their own decisions.
> But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
In your view would it be acceptable to backdoor open source software to sell user's data to the highest bidder? That's obviously not what happened here, but seems like the obvious conclusion of your argument.
Correct me if im wrong, but based on the report this looks like something that would affect regular users of ffmpeg but not google's use.
> If you want the security issue to be fixed,
There is no indication that google actually cared much whether the issue got fixed or not. It seems like the course of events is that they noticed something looked wrong with the code so they filed a bug. That's it.
> willing to pay for them to fix.
Should ffmpeg pay for security researchers time to find these issues? The market price for that is much much much higher than the price to fix bugs.
If you were to pay someone to do vulnerability testing in ffmpeg with sufficient skill to find this issue, it would probably cost you in the hundreds of thousands of dollars at least.
https://github.com/search?q=repo%3AFFmpeg%2FFFmpeg+%40google...
And they have done large pushes in the past: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
But don't take it further that the maintainers have the duty to fix the issues. They choose that career, don't make it sound like ffmpeg is forcing them to disclosure. Maintainers don't "deal" with any security researchers about those, and don't put the confidence that it "benefits maintainers" than "benefit researchers", unless the maintainers declare that themselves. In this case there's no patch, no fix, no PR either, just issue-submission. "You have more benefits" are the claims of the researchers who think that their issue-submission contributions top everything else.
Finding and disclosing the security are issue-submission contributions, and that's it. Don't make it as a gift or something. ffmpeg doesn't have the need to find these issues, and they don't pay for it for it either. And vice versa, they have no duties to fix the issues. They don't force the security researchers to find and disclose things. If security researchers want to do it themselves, they can do whatever they want, but stop at forcing duties to the maintainers. The only thing I don't agree with ffmpeg is bringing those issues social while they can just ignore them, that's it.
It is up to you, the end user of the software to evaluate whether those terms, risks, and options are good enough for you. If not, don't use it. You have it completely backwards, and frankly, sound quite entitled.
Although perhaps my previous comment went a little too far. I think its fine to not fix issues as long as you publish them so that users can make an informed decision. Where i think it would be morally wrong is if a project pretends it fixes security issues but doesn't or if it tries to cover them up - insisting external reporters dont talk about them while also having no intention of fixing them.
Basically i think open source projects (like everyone) have a moral duty to be honest and not try and decieve people, regardless of what the license says.
My biggest gripe though is that ffmpeg does seem to value these sorts of reports highly. If i'm reading the timestamps right, they fixed this report within 1 day: https://github.com/FFmpeg/FFmpeg/commit/c41a70b6bb79707e1e3a...
How often do you get your bug reports fixed that fast? When i file bugs in open source projects it usually takes at least weeks if im lucky to get a response. People almost never respond within 1 day. I think that demonstrates how valuable ffmpeg views these reports.
If the report was a garbage report (like e.g. the ones the curl maintainer complains about) i'd have more sympathy, but clearly ffmpeg views this issue submission as valuable. The whole thing makes me think of choosing-beggars. They want the google report but also are trying to use social pressure to make google contribute even more.
If they didn't want google's reports that's one thing - just reject them, but both wanting them while also demanding more is scummy in my opinion. Either accept or reject them.
But I think Google would still be concerned. Even if they're running ffmpeg in a sandbox you can escape sandboxes. The sandbox is a security layer, not what makes the thing safe. You should be using it as a layer of defense for unknown vulns, and try to resolve vulns. I mean Google is much more likely to have an attacker trying to chain a vuln with a sandbox escape than the average user.
Btw:
ffmpeg -codecs | cat | grep SANM 2&>/dev/null
ffmpeg version n8.0 Copyright (c) 2000-2025 the FFmpeg developers
... ffmpeg flags ...
D.V.L. sanm LucasArts SANM/SMUSH video
[0] Will expire soon https://0x0.st/KL6K.log
[DISCLOSURE]: I AM NOT A SECURITY PROFESSIONAL. If I am wrong please correct me