Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

Post reply on HN
Print view View original

901–910 of 913 posts

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

#901

Post by xign »

danaris wrote: post #247
freedomben wrote: post #152

Earlier quoted context omitted.

I would love to see Google contribute here, but I think that's a different issue. Are the bug reports accurate? If so, then they are contributing just as if I found them and sent a bug report, I'd be contributing. Of course a PR that fixes the bug is much better than just a report, but reports have value, too. The alternative is to leave it unfound, which is not a better alternative in my opinion. It's still there an…

But FFmpeg does not have the resources to fix these at the speed Google is finding them. It's just not possible. So Google is dedicating resources to finding these bugs and feeding them to bad actors. Bad actors who might, hypothetically have had the information before, but definitely do once Google publicizes them. You are talking about an ideal situation; we are talking about a real situation that is happening in t…

What makes you think the bad actors aren't already finding these bugs? From the looks of it, there isn't really any rocket science going on here. There are equally well-funded bad actors who will and do find these issues.

With Google finding these bugs, at least the user can be informed. For this instance for example, the core problem here is the codec is in *active use*. Ffmpeg utilizes a disingenuous argument that it's old and obscure, but omits the fact that it's still compiled in meaning that an attacker can craft a file and send it to you and still works.

A user (it could be a distro who packages ffmpeg) can use this information to turn off the codec that virtually no one uses today and make their distribution of ffmpeg more secure. Not having this information means they can't do that.

If ffmpeg doesn't have the resources to fix these bugs, at least let the public know so we can deal with it.

Also, just maybe, they wouldn't have that many vulnerabilities filed against them if the project took security more seriously to begin with? It's not a good sign for the software when you get so many valid security reports and just ask them to withhold them.

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

#902

Post by xign »

necovek wrote: post #234
jsnell wrote: 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:…

But the vulnerability exists already. You are making it sound like Google invented a problem for the project. Maybe the project should be name called if it has hundreds of vulnerabilities? Whether it's run by volunteers or not does not matter for a user of the software.

No one is forcing anyone to do anything. Ffmpeg does not have to fix this bug, btw. If they don't have time, just let the disclosure happen.

Also, in this case, the simple fix is to turn off the codec. They just didn't want to do that because they want to have all codecs enabled. This is a conscious choice and no one is forcing them to do that. If the CVE was allowed to disclose without ffmpeg fixing the issue, at least the downstream users can turn off the codec themselves.

Just to be clear here: Googles' responsibility here is to the public (aka the users of ffmpeg), not the project.

Also, let's go back to your "cooked a meal" analogy. If I cook a meal for you, for free, that's nice. But that doesn't entitle me to be careless in hygiene and gives you salmonella poisoning because I didn't wash my hands. Doing things for free doesn't absolve me of any responsibility.

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

#903

Post by xign »

xethos wrote: post #341
woodruffw wrote: post #10

I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes per…

From TFA: > The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.” This doesn't feel like a medium-severity bug, and I think "Perhaps reconsider the severity" is…

Whether the codec is from 1995 or 2025 does not matter. What matters is that the codec is compiled in and working by default on ffmpeg as they intend to bundle all codecs for the user. You can just craft a file, send it to a user pretending to be a regular mp4 file, and trigger the bug. It literally wouldn't matter if the codec was this Lucas Arts one of HEVC. An attacker wouldn't care if they walk in the front door or a random broken window in the back.

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

#904

Post by xign »

Msurrow wrote: post #30
danlitt wrote: post #27

Earlier quoted context omitted.

> it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days This is very far from obvious. If google doesn't feel like prioritising a critical issue, it remains irresponsible not to warn other users of the same library.

If that’s the case why give the OSS project any time to fix at all before public disclosure? They should just publish immediately, no? Warn other users asap.

Timed disclosure is just a compromise between giving project time and public interests. People have been doing this for years now. Why are people acting like this is new just because ffmpeg is whining?

And occasionally you do see immediate disclosures (see below). This usually happens for vulnerabilities that are time-sensitive or actively being exploited where the user needs to know ASAP. It's very context dependent. In this case I don't think that's the case, so there's a standard delayed disclosure to give courtesy for the project to fix it first.

Note the word "courtesy". The public interest always overrides considerations for the project's fragile ego after some time.

(Some examples of shortened disclosures include Cloudbleed and the aCropalypse cropping bug, where in each case there were immediate reasons to notify the public / users)

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

#905

Post by tpmoney »

Orygin wrote: post #889
tpmoney wrote: post #881

Earlier quoted context omitted.

> Absolutely, but should the patch be done asap at the cost of other maybe more important security patches? Maybe, maybe not. Not all bugs are security vulns, and not all security vulns are exploitable I fully agree which is why I really don’t understand why everyone is all up in arms here. Google didn’t demand that this bug get fixed immediately. They didn’t demand that everything be dropped to fix a 25 year old bug…

In the end, a report saying "fix this within 90 days or this gets public" for small-ish bugs like this is a kind of demand. Do this or this gets out and you'll have to make an express release to fix it anyway. I can understand that stance for serious bugs and security vulnerabilities. I can understand such delays for a company with a big market cap to put pressure on them. But these delays are exactly like a demand p…

> In the end, a report saying "fix this within 90 days or this gets public" for small-ish bugs like this is a kind of demand. Do this or this gets out and you'll have to make an express release to fix it anyway.

I think this is where the disconnect is. To my mind there is no "do this or else" message here, because there is no "or else". The report is a courtesy advance notice of a bug report that WILL be filed, no matter what the ffmpeg developers do. It's not like this is some awful secret that Google is promising not to disclose if ffmpeg jumps to their tune.

Further, the reality is most bug reports are never going to be given a 90 day window. Their site requests that if you find a security vulnerability you email their security team, but it doesn't tell you not to also file a bug report, and their bug report page doesn't tell you not to file anything you think might be a security or vulnerability bug to the tracker. And a search through the bug tracker shows more than a few open issues (sometimes years old) reporting segfault crashes, memory leaks, un-initialized variable access, heap corruption, divide by zero crashes, buffer overflows, null pointer dereferences and other such potential safety issues. It seems the ffmpeg team has no problems generally with having a backlog of these issues, so certainly one more in a (as we've been repeatedly reminded) 25 year old obscure codec parser is hardly going to tank their reputation right?

> In the end, had these reports been made by random security researchers, no drama would have happened.

And now we get to what is really the heart of the matter. If anyone else has reported this bug in this way, no one would care. It's not that Google did anything wrong, it's that Google has money so everyone is mad that they didn't do even more than they already do. And frankly that attitude stinks. It's hard enough getting corporations to actually contribute back to open source projects, especially when the license doesn't obligate them to at all. I'm not advocating holding corporations to some lesser standard, if the complaint was that Google was shoving unvalidated, and un-validatable low effort reports into the bug tracker, or that they actually were harassing the ffmpeg developers with constant followups on their tickets and demands for status updates then that would be poor behavior that we would be equally upset about if it came from anyone. But like you said, any other security researcher behaving the same way would be just fine. Shitting on Google this way for behaving according to the same standards outlined on ffmpeg's own website because of who they are and not what they've done just tells other corporations that it doesn't matter if you contribute code and money in addition to bug reports, if you don't do something to someone's arbitrary standard based on WHO you are, rather than WHAT you do, you'll get shit on for it. And that's not going to encourage more cooperation and contributions from the corporations that benefit from these projects.

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

#906

Post by SergeAx »

I don't get the logic behind the FFmpeg stance. They have no obligation to fix any bugs, and they are not liable if someone exploits those vulnerabilities, as per the license. Thus, the parties interested in fixes are free to patch bugs at their own expense or pay someone else to do it. Anyways, fixes will end up in the FFmpeg codebase or in other GNU-licensed fork of it, available to cherry-pick.

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

#907

Post by SergeAx »

gcr wrote: post #748
woodruffw wrote: post #249

Earlier quoted context omitted.

I don’t think vulnerability researchers are having trouble finding exploitable bugs in FFmpeg, so I don’t know how much this actually holds. Much of the cost center of vulnerability research is weaponization and making an exploit reliable against a specific set of targets. (The argument also seems backwards to me: Google appears to use a lot of not-inexpensive human talent to produce high quality reports to projects,…

Internally, Google maintains their own completely separate FFMpeg fork as well as a hardened sandbox for running that fork. Since they keep pace with releases to receive security fixes, there’s potentially lots of upstreamable work (with some effort on both sides…)

Shouldn't this fork be publicly available as per GPL license?

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

#908

Post by troupo »

tpmoney wrote: post #882
troupo wrote: post #878

Earlier quoted context omitted.

Here's ffmpeg's site: https://www.ffmpeg.org I fail to see a single Google logo. I also didn't know that Google sonehow had a contract with ffmpeg to be their customer.

Yes and if you look on ffmpeg’s site you’ll find a link where they promote hiring their devs independently as consultants for ffmpeg work. Note the names of those maintainers. Now go to fflabs.eu, observe that they are an ffmpeg consulting firm, scroll down on the main page and observe the Google logo among their promoted list of customers. Now click on the “team” link and check out the names of the people that run f…

> if you look on ffmpeg’s site you’ll find a link

> Note the names of those maintainers. Now go to fflabs.eu

> Now click on the “team” link and check out the names

Quite an investigative work you've done there: some maintainers may do some work that surely... means sonething?

Meanwhile actual maintainer actually patching thousands of vulnerabilities in ffmpeg, including the recent ones reported by Google:

--- start quote ---

so far i got 7560€ before taxes for my security work in the last 7 months. And thats why i would appreciate that google, facebook, amazon and others would pay me directly. Also that 7560 i only got after the twitter noise.

https://x.com/michael__ni/status/1989391413151518779

--- end quote ---

Hint: just because people do some consulting for a customer doesn't mean that they are continuously paid to work on something.

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

#909

Post by jsnell »

Orygin wrote: post #889
tpmoney wrote: post #881

Earlier quoted context omitted.

> Absolutely, but should the patch be done asap at the cost of other maybe more important security patches? Maybe, maybe not. Not all bugs are security vulns, and not all security vulns are exploitable I fully agree which is why I really don’t understand why everyone is all up in arms here. Google didn’t demand that this bug get fixed immediately. They didn’t demand that everything be dropped to fix a 25 year old bug…

In the end, a report saying "fix this within 90 days or this gets public" for small-ish bugs like this is a kind of demand. Do this or this gets out and you'll have to make an express release to fix it anyway. I can understand that stance for serious bugs and security vulnerabilities. I can understand such delays for a company with a big market cap to put pressure on them. But these delays are exactly like a demand p…

But this isn't a "small-ish bug". What gave you that impression? It's a vulnerability in code that is both compiled in by default, and that is reachable when ffmpeg is run with its default settings when run on a file crafted to trigger the bug.

And if you believe this is a "small-ish" bug just because the ffmpeg Twitter account's gaslighting about "20 frames of a single video in Rebel Assault", then surely it being disclosed would be irrelevant? The only way the disclosure timeline makes a difference is if ffmpeg too think that the bug is serious.

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

#910

Post by iscoelho »

Espressosaurus wrote: post #885
iscoelho wrote: post #142

It’s a reproducible use-after-free in a codec that ships by default with most desktop and server distributions. The recent iOS zero-day (CVE-2025-43300) targeted the rarely used DNG image format. How long before this FFMPEG vulnerability is exploited to compromise legacy devices in the wild, I wonder? I’m not a fan of this grandstanding for arguably questionable funding. (I surely would not fund those who believe the…

DNG isn't exactly rarely used, it's Adobe's open raw format and lots of image processing programs read and write it. It's not a codec made for one game back in 1994, it's still in very active use today if you're using such a rare and uncommon program as Photoshop.

I agree it is a widely used format, however, it is rarely used on iOS devices.
Post reply on HN