Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

391–400 of 913 posts

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

#391
post #185

Earlier quoted context omitted.

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.

> 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-read the article. There's CVEs and then there's CVEs . This is the former, and they're shoving tons of those down the throats of unpaid volunteers while contributing nothing back. What Google's effectively doing is like a food safety inspection company going to the local food bank to…

I am unsure why this untruth is being continuously parroted. It is false.

This is exploitable on a majority of systems as the codec is enabled by default. This is a CVE that is being severely underestimated.

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

#392

Earlier 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…

Google is: - choosing to do this of their own volition - are effectively just using their resources to throw bug reports over the wall unprompted. - benefiting from the bugs getting fixed, but not contributing to them.

Google is a contributor to FFMPEG.

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

#393
post #60

Earlier 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, you are simultaneously increasing the visibility of the vulnerability and name-calling the maintainers.

So how long should all bug reporters wait before filing public bugs against open source projects? What about closed source projects? Anyone who works in software knows to ship software is to always have way more things to do than time to do it in. By this logic, we should never make bug reports public until the software maintainers (whether OSS, Apple or Microsoft) has a fix ready. Instead of "with enough eyeballs, all bugs are shallow" the new policy going forward I guess will be "with enough blindfolds, all bugs are low priority".

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

#394
post #78
post #42

Earlier 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.

> That is standard practice. It's standard practice for commercially-sponsored software, and it doesn't necessarily fit volunteer maintained software. You can't have the same expectations.

So no one should file public bug reports for open source software?

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

#395
post #178

Earlier quoted context omitted.

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 exp…

Then they can damn well pay for fixing them too .

So to be clear, if Google doesn't include patches, you would rather they don't make bugs they find in software public so other people can fix them?

That is, you'd rather a world where Google either does know about a vulnerability and refuses to tell anyone, or just doesn't look for them at all, over a world where google looks for them and lets people know they exist, but doesn't submit their own fix for it.

Why do you want that world? Why do you want corporations to reduce the already meager amounts of work and resources they put into open source software even further?

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

#396
post #305

Earlier quoted context omitted.

Personally, I want the $3.5 Trillion company to do more. So the line should be somewhere else.

So you don't have a line, you just want to move the goalposts and keep moving them?

It is my understanding that the commenters in FFMPEG's favor believe that Google is doing a disservice by finding these security vulnerabilities, as they require volunteer burden to patch, and that they should either:

1) allow the vulnerabilities to remain undiscovered & unpatched zero-days (stop submitting "slop" CVEs.)

2) supply the patches (which i'm sure the goalpost will move to the maintainers being upset that they have to merge them.)

3) fund the project (including the maintainers who clearly misunderstand the severity of the vulnerabilities and describe them as "slop") (no thank you.)

This entire thread defies logic.

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

#397
post #63

Fully 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.

This is why many have warned against things like MIT licence. Yes, it gives you source code and does easily get incorporated into a lot of projects but it comes at the cost of potential abuse. Yes, GPL 3 is a lot ideologically but it was trying to limit excessive leeching. Now that I have opened the flood gates of a 20 year old debate, time to walk away.

ffmpeg is already LGPL / GPLv2. How does the license choice factor into this at all?

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

#398

I am fairly confident that this article is largely AI-generated. More generally, the whole site appears to be heavy on AI slop, e.g.: https://thenewstack.io/how-ai-is-pushing-kubernetes-storage-... And maybe it's fine to have AI-generated articles that summarize Twitter threads for HN, but this is not a good summarization of the discussion that unfolded in the wake of this complaint. For one, it doesn't mention a rep…

Like the bug report in question... poetic.

The bug report in question is obviously written by a human:

https://issuetracker.google.com/issues/440183164?pli=1

It's of excellent quality. They've made things about as easy for the FFmpeg devs as possible without actually fixing the bug, which might entail legal complications they want to avoid.

AI was only used to find the bug.

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

#399

It'd be a silly license or condition, but, a license that says employees of companies in the S&P500 cant file bugs without an $X contribution, and cant expect a response in under Y days without a larger one, would be a funny way to combat it. Companies have no problem making software non-free or AGPL when it becomes inconvenient so maybe they can put up or shut up.

Where in this bug report was there any expectation for a response? They filed a private bug report and have a policy of making private reports public in 90 days whether or not they get a response. How did the OSS world go from "with enough eyes all bugs are shallow" to "filing a bug report is demanding I respond to you"?

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

#400
post #289

Earlier quoted context omitted.

It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable. The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as t…

Sure, it's a valid bug report. But I don't understand why there has been so much drama over this when all the ffmpeg folks have to do is say "sorry, this isn't a priority for us so we'll get to it as soon as we can" and put the issue in the backlog as a low priority. If Google wants the issue fixed faster, they can submit a fix. If they don't care enough to do that, they can wait. No big deal either way. Instead, ffm…

FFMPEG is upset because Google made the exploit public. They preferred that it remained a zero-day until they decided it was a priority.

I don't understand how anyone believes that behavior is acceptable.

Post reply on HN