FFmpeg to Google: Fund us or stop sending bugs • Hacker News Board

Re: FFmpeg to Google: Fund us or stop sending bugs

#851

Post by Dylan16807 » Wed, Nov 12, 2025, 9:37 PM UTC

ndriscoll wrote: post #843

Dylan16807 wrote: post #838

Earlier quoted context omitted.

> the very idea that they owe you anything All I'm asking for right here is consistency about whether the library is mostly secure. The ethical requirement is to follow through on your claims and implications, while making claims and implications is completely optional. > Computer security is always contextual, but as a general rule, if you're going to be accepting random input from unknown parties, you should have a…

The library probably is mostly secure, and it might even be the best library out there for what it does. That still leaves them with no ethical requirement at all. People are allowed to make secure, robust software for fun. They can take pride in how good of a job they do at that. They can correctly point out that their software is the best. That still leaves them with no obligations at all for having shared their pr…

> The library probably is mostly secure

It is if they fix bugs like this. Status quo everything is fine with their actions, they don't need to do anything they aren't already doing.

If they decide they don't want to fix bugs like this, I would say they have the ethical obligation to make it clear that the software is no longer mostly secure. This is quite easy to accomplish. It's not a significant burden in any way.

Basically, if they want to go the less-secure route, I want it to be true that they're "effectively saying" that all caps text you wrote earlier. That's all. A two minute edit to their front page would be enough. They could edit the text that currently says "A complete, cross-platform solution to record, convert and stream audio and video." I'll even personally commit $10 to pay for those two minutes of labor, if they decide to go that route.

Re: FFmpeg to Google: Fund us or stop sending bugs

#852

Post by skybrian » Wed, Nov 12, 2025, 9:50 PM UTC

mellosouls wrote: post #674

skybrian wrote: post #181

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

To help those without access to X, the PR thread linked appears to give 2014 as the last time they reported solid contributions to helping fix security issues in ffmpeg. https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...

While technically accurate, this is selective quoting, leaving out other contributions.

Here's an archive link:

https://xcancel.com/argvee/status/1986194852669964528

Re: FFmpeg to Google: Fund us or stop sending bugs

#853

Post by tpmoney » Wed, Nov 12, 2025, 10:37 PM UTC

kastagg wrote: post #806

tpmoney wrote: post #463

Earlier quoted context omitted.

If they contribute nothing back, what are all the `google.com` email addresses in the git history doing? If they contribute nothing back, why are they listed as a customer of `fflabs.eu` which is apparently a private consulting company for ffmpeg run by some of the ffmpeg lead maintainers? What do we think the lesson corporations are going to take from this is? 1) "You should file patches with your bug reports" 2) "E…

The text and context of the complaint can be used to steelman it, adopting the principle of charity. From that perspective, the most likely problem is not that bugs are being reported, nor even that patches are not being included with bug reports. The problem is that a shift from human-initiated bug reports to large-scale LLM generation of bug reports by large corporate entities generates a lot more work and changes…

> Even if you use LLMs to generate bug reports, you should have a human vet and repro them as real and significant and ensure they are written up for humans accurately and concisely, including all information that would be pertinent to a human.

Look at the report that's the center of this controversy. It's detailed, has a clear explanation of the issue at hand, has references and links to the relevant code locations where the submitter believes the issue is and has a minimal reproduction of the issue to both validate the issue and the fix. We can assume the issue is indeed valid and significant as ffmpeg patched it before the 90 day disclosure window. There is certainly nothing about it that screams low effort machine generated report without human review, and at least one commenter in this discussion claims to have inside knowledge that all these reports are written by verified and written by humans before submission to the projects.

I won't pretend that it's a perfect bug report, but I will say if every bug report I got for the rest of my career was of this caliber, I'd be a quite happy with that.

> It isn't unreasonable to ask them to pay for that work which they are, one way or another, asking to have done.

Google quite literally hires some of the ffmpeg maintainers as consultants as attested to by those same maintainer's own website (fflabs.eu). They are very plainly putting cold hard cash directly into the funds of the maintainers for the express purpose of them maintaining and developing ffmpeg. And that's on top of the code their own employees submit with some regularity. As near as I can tell, Google does everything people complaining about this are saying they don't do, and it's still not enough. One has to wonder then what would be enough?

Re: FFmpeg to Google: Fund us or stop sending bugs

#854

Post by izacus » Wed, Nov 12, 2025, 10:45 PM UTC

tombert wrote: post #802

izacus wrote: post #626

Earlier quoted context omitted.

Now count how many libraries you use in your day to day paid work that are opensource and you didn't have to pay anything for them. If you want to think selfishly about how awful it is to contribute to that body of work, maybe also purge them all from your codebase and contact companies that sell them?

Maybe those people shouldn’t be doing free labor to give me free libraries either.

Maybe such sociopath ideas should be shunned in any healthy society.

Re: FFmpeg to Google: Fund us or stop sending bugs

#855

Post by tpmoney » Wed, Nov 12, 2025, 10:46 PM UTC

firefax wrote: post #814

tpmoney wrote: post #431

Earlier quoted context omitted.

Google contributes to ffmpeg on a fairly regular basis https://git.ffmpeg.org/gitweb/ffmpeg.git/search/HEAD?s=@goog... No it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't. They could just not file the bug reports at all, and that is an objectively worse outcome.

>No it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't Your stance seems to be is that it is unreasonable to be annoyed by someone who is being unreasonable. When I searched for synonyms for "unreasonable" in a major English language thesarus, the following synonyms were listed: indefensible, mindless, reasonless, senseless, unjustified, untenable, unwarran…

No, my stance is that it is reasonable for ffmpeg to ask for patches along with bug fixes and that is it simultaneously reasonable for Google to submit bug reports without those patches. Just like it would be reasonable for Google to ask for a feature in ffmpeg and it's equally reasonable for the ffmpeg maintainers to decline to implement the feature. Reasonableness is not a binary thing.

Re: FFmpeg to Google: Fund us or stop sending bugs

#856

Post by tpmoney » Wed, Nov 12, 2025, 10:55 PM UTC

PapstJL4U wrote: post #760

tpmoney wrote: post #417

Earlier quoted context omitted.

If it takes 3 seconds to fix it, then how is this some massive burden on the maintainers? The bug report pointed to the relevant lines, the maintainers are the most familiar with the code and it probably would have taken them 1.5 seconds to not only fix it, but validate the fix. It probably took more time to write up the complaint about the bugs than to implement the fix.

It takes more time to read and understand the bug report, than to fix it. Instead of using googles time, they used ffmpegs voluntary time. If this happens another 1000 times (easily possible with AI) google just got free labour and free publicity for "discovering 1000 critical bugs (but not fixing them even so they were easy to do)"

It takes even more time to read and understand a patch. Not only to you have to do all of the work of reading and understanding the bug report for which the patch is relevant, but you now also have to read and understand the submitted code, which until just this moment you didn't even know was necessary and have no specific context for. Then you have to validate whether or not the code in the patch is sufficient to fix the issue or whether those changes have any additional knock on effects. Yes, you could hope that the Google coders did this, but since you already have such a low opinion of Google's efforts and behavior on this front, I would argue that trusting their submission without validation would be insane.

Then if there's any changes or additional work to be done, you now have to spend time communicating with the patch sumbmitter, either getting them to make the requested changes, or rejecting their patch outright and writing it on your own.

And after all that we'd be right back here, only instead of the complain being "we don't have enough time to review all your bug reports" it would be "we don't have enough time to review all your PRs"

Re: FFmpeg to Google: Fund us or stop sending bugs

#857

Post by tpmoney » Wed, Nov 12, 2025, 11:04 PM UTC

Orygin wrote: post #695

tpmoney wrote: post #414

Earlier quoted context omitted.

> In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. So when the xz backdoor was discovered, you think it would have been better to sit on that quietly and try to both wrest control of upstream away from the upstream maintainers and wait until all the downstream projects had reverted the changes in their copies before making that public?…

The XZ backdoor is not a bug but a malicious payload inserted by malicious actors. The security vulnerability would immediately been used as it was created by attackers. This bug is almost certainly too obscure to be found and exploited in the time the fix can be produced by Ffmpeg. On the other hand, this vuln being public so soon means any attacker is now free to develop their exploit before a fix is available. If…

A bug is a bug, regardless of the intent of the insertion. You have no idea if this bug was or wasn't intentionally inserted. It's of course very likely that it wasn't, but you don't and can't know that, especially given that malicious bug insertion is going to be designed to look innocent and have plausible deniability. Likewise, you don't know that the use of the XZ backdoor was imminent. For all you know the intent was to let it sit for a release or two, maybe with an eye towards waiting for it to appear in a particular down stream target, or just to make it harder to identify the source. Yes, just like it is unlikely that the ffmpeg bug was intentional, it's also unlikely the xz backdoor was intended to be a sleeper vulnerability.

But ultimately that's my point. You as an individual do not know who else has access or information about the bug/vulnerability you have found, nor do you have any insight into how quickly they intend to exploit that if they do know about it. So the right thing to do when you find a vulnerability is to make it public so that people can begin mitigating it. Private disclosure periods exist because they recognize there is an inherent tradeoff and asymmetry in making the information public and having effective remediations. So the disclosure period attempts to strike a balance, taking the risk that the bug is known and being actively exploited for the benefit of closing the gap between public knowledge and remediation. But inherently it is a risk that the bug reporter and the project maintainers are forcing on other people, which is why the end goal must ALWAYS be public disclosure sooner rather than later.

Re: FFmpeg to Google: Fund us or stop sending bugs

#858

Post by tpmoney » Wed, Nov 12, 2025, 11:07 PM UTC

troupo wrote: post #594

tpmoney wrote: post #385

Earlier quoted context omitted.

Great, so Google is actively spending money on making open source projects better and more secure. And for some reason everyone is now mad at them for it because they didn't also spend additional money making patches themselves. We can absolutely wish and ask that they spend some money and resources on making those patches, but this whole thing feels like the message most corporations are going to take is "don't do a…

> so Google is actively spending money on making open source projects better and more secure It looks like they are now starting to flood OSS with issues because "our AI tools are great", but don't want to spend a dime helping to fix those issues. xkcd 2347

According to the ffmpeg maintainer's own website (fflabs.eu) Google is spending plenty of dimes helping to fix issues in ffmpeg. Certainly they're spending enough dimes for the maintainers to proudly display Google's logo on their site as a customer of theirs.

Re: FFmpeg to Google: Fund us or stop sending bugs

#859

Post by tpmoney » Wed, Nov 12, 2025, 11:11 PM UTC

etiennebausson wrote: post #702

tpmoney wrote: post #618

Earlier quoted context omitted.

So when someone finds a bug in software, in your mind the only acceptable options are: 1) Fix it yourself 2) Sit on it silently until the maintainers finally get some time to fix it That seems crazy to me. For one, not everyone who discovers a bug can fix it themselves. But also a patch doesn't fix it until it's merged. If filing a public bug report is expecting the maintainers to "drop everything and do free labor"…

xz was a fundamentally different problem, it was code that had been maliciously introduced to a widespread library and the corrupted version was in the process of being deployed to multiple distributions. The clock was very much ticking.

The clock is always ticking. You have no idea when you find a vulnerability who knows about it or how or whether it is currently being actively exploited. A choice to delay disclosure is a choice to take on the risk that the bug is being actively exploited in order to reduce the gap (and risk in that gap) between public disclosure and remediations being available. But critically, it is a risk that is being forced on the users of the software. They are unable to make an informed decision about accepting the risk because they don't know there is a risk. Public disclosure, sooner rather than later MUST be the goal of all bug reports, no matter how serious and no matter how overworked the maintainers.

Re: FFmpeg to Google: Fund us or stop sending bugs

#860

Post by tpmoney » Wed, Nov 12, 2025, 11:13 PM UTC

naasking wrote: post #757

tpmoney wrote: post #618

Earlier quoted context omitted.

So when someone finds a bug in software, in your mind the only acceptable options are: 1) Fix it yourself 2) Sit on it silently until the maintainers finally get some time to fix it That seems crazy to me. For one, not everyone who discovers a bug can fix it themselves. But also a patch doesn't fix it until it's merged. If filing a public bug report is expecting the maintainers to "drop everything and do free labor"…

Responsible disclosure policies for contributor-driven projects can differ from commercial projects. Also, if Google has the funds to pay for bug finding, they also have the funds for bug fixing the community projects they depend on.

> Responsible disclosure policies for contributor-driven projects can differ from commercial projects.

The can, but there's not an obvious reason why they should. If anything, public disclosure timelines for commercial closed source projects should be much much longer than for contributor-driven projects because once a bug is public ANYONE can fix it in the contributor-driven project, where as for a commercial project, you're entirely at the mercy of the commercial entities timelines.

> Also, if Google has the funds to pay for bug finding, they also have the funds for bug fixing the community projects they depend on.

They do. And they do. They literally higher the ffmpeg maintainers via the maintainer's consulting business (fflabs.eu) and they routinely contribute code to the ffmpeg project.