FFmpeg to Google: Fund us or stop sending bugs

If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.

So your claim is that buggy software is better than documented buggy software?

I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.

Yeah it's more effort, but I'd argue that security through obscurity is a super naive approach. I'm not on Google's side here, but so much infrastructure is "secured" by gatekeeping knowledge.

I guess the question that a person at Google who discovers a bug they don’t personally have time to fix is, should they report the bug at all? They don’t necessarily know if someone else will be able to pick it up. So the current “always report” rule makes sense since you don’t have to figure out if someone can fix it.

The same question applies if they have time to fix it in six months, since that presumably still gives attackers a large window of time.

In this case the bug was so obscure it’s kind of silly.

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, instead of dumping an ASan log and calling it a day. If all they cared about was shoveling labor onto OSS maintainers, they could make things a lot easier for themselves than they currently do!)

I don't think you should try to invoke the idea of naivete when you fail to address the unhappy but perfectly simple reality that the ideal option doesn't exist, is a fantasy that isn't actually available, and among the available options, even though none are good, one is worse than another.

"obscurity isn't security" is true enough, as far as it goes, but is just not that far.

And "put the bugs that won't be fixed soon on a billboard" is worse.

The super naive approach is ignoring that and thinking that "fix the bugs" is a thing that exists.

it’s not a claim it’s common sense that’s why we have notice periods

If I know it's a bug and I use ffmpeg, I can avoid it by disabling the affected codec. That's pretty valuable.

More fantasy. Presumes the bug only exists in some part of ffmpeg that can be disabled at all, and that you don't need, and that you are even in control over your use of ffmpeg in the first place.

Sure, in maybe 1 special lucky case you might be empowered. And in 99 other cases you are subject to a bug without being in the remotest control over it since it's buried away within something you use and don't even have the option not to use the surface service or app let alone control it's subcomponents.

The bug in question revolves around support for codec that has never been in wide use, and was only in obscure use over 25 years ago.

The bug exists whether it's reported to the maintainers or not, so yeah, it's pretty naive.

It's a heck of a lot better than being unaware of it.

(To put this in context: I assume that on average a published security vulnerability is known about to at least some malicious actors before it's published. If it's published, it's me finding out about it, not the bad actors suddenly getting a new tool)

Given that Google is both the company generating the bug reports and one of the companies using the buggy library, while most of the ffmpeg maintainers presumably aren't using their libraries to run companies with a $3.52 trillion dollar market cap, would you argue that going public with vulnerabilities that affect your own product before you've fixed them is also a naive approach?

It doesn't matter how obscure it is if it's a vulnerability that's enabled in default builds.

This is a weird argument. Basically condoning security through obscurity: If nobody reports the bug then we just pretend it doesn’t exist, right?

There are many groups searching for security vulnerabilities in popular open source software who deliberately do not disclose them. They do this to save them for their own use or even to sell them to bad actors.

It’s starting to feel silly to demonize Google for doing security research at this point.

There is no "the bug". The discussion is about what to do with the power of bug-finding tools.

Sorry, but this states a lot of assumption as fact to ask a question which only makes sense if it's all true. I feel Google should assist the project more financially given how much they use it, but I don't think Google shipping products using every codec they find bugs for with their open source fuzzer project is a reasonable guess. I certainly doubt YouTube/Chrome let's you upload/compiles ffmpeg with this LucasArts format, as an example. For security issues relevant to their usage via Chrome CVEs etc, they seem to contribute on fixes as needed. E.g. here is one via fuzzing or a codec they use and work on internally https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb...

In regards whether it's a bad idea to publicly document security concerns found regardless whether you plan on fixing them, it often depends if you ask the product manager what they want for their product or what the security concerned folks in general want for every product :).

> It’s starting to feel silly to demonize Google for doing security research at this point.

Aren't most people here demonizing Google for dedicating the resources to find bugs, but not to fix them?

it's only better if you can act on it equal to the bad guys. If the bad guys get to act on it before you, or before some other good guys do on your behalf, then no it's not better

remember we're not talking about keeping a bug secret, we're talking about using a power tool to generate a fire hose of bugs and only doing that, not fixing them

This was not a case of stumbling across a bug. This was dedicated security research taking days if not weeks of high paid employees to find.

And after all that, they just drop an issue, instead of spending a little extra time on producing a patch.

And not giving the maintainners reasonable amount of time to fix. This was triggered by recent change of policy on google side.

It’s possible that this is a more efficient use of their time when it comes to open source security as a whole, most projects do not have a problem with reports like this.

If not pumping out patches allows them to get more security issues fixed, that’s fine!

The timeline is industry standard at this point. The point is make sure folks take security more seriously. If you start deviating from the script, others will expect the same exceptions and it would lose that ability. Sometimes it's good to let something fail loudly to show this is a problem. If ffmpeg doesn't have enough maintainers, then they should fail and let downstream customers know so they have more pressure to contribute resources. Playing superman and trying to prevent them from seeing the problem will just lead to burn out.

Is it industry standard to run automatic AI tools and spam the upstream with bug reports? To then expect the bugs to be fixed within a 90 days is a bit much.

It's not some lone report of an important bug, it's AI spam that put forth security issues at a speed greater than they have resources to fix it.

> I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.

That just means the script kiddies will have more trouble, while more scary actors like foreign intellegence agencies will have free reign.

"AI tools" and "spam" are knee jerk reactions, not an accurate picture of the bug filed: https://issuetracker.google.com/issues/440183164?utm_source=...

whether or not AI found it, clearly a human refined it and produced a very high quality bug report. There's no AI slop here. No spam.

Security by obscurity. In 2025. On HN.

From the perspective of Google maybe, but from the perspective of open source projects, how much does this drain them?

Making open source code more secure and at the same time less prevalent seems like a net loss for society. And if those researchers could spare some time to write patches for open source projects, that might benefit society more than dropping disclosure deadlines on volunteers.

> it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg

At least, if this information is public, someone can act on it and sandbox ffmpeg for their use case, if they think it's worth it.

I personally prefer to have this information be accessible to all users.

Which codec is it?

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

"The bug" in question refers to the one found by the bug-finding tool the article claims triggered the latest episode of debate. Nobody is claiming it's the only bug, just that this triggering bug highlighted was a clear example of where there is actually such a clear cut line.

Google does contribute some patches for codecs they actually consume e.g. https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb..., the bug in question was just an example of one the bug finding tool found that they didn't consume - which leads to this conversation.

My understanding from adjacent threads in this discussion is that Google does in fact make significant upstream contributions to FFmpeg. Per policy those are often made with personal emails, but multiple people have said that Google’s investment in FFmpeg’s security and codec support have been significant.

(But also, while this is great, it doesn’t make an expectation of a patch with a security report reasonable! Most security reports don’t come with patches.)

I’m specifically talking from the perspective of everybody but Google.

High quality bug reports like this are very good for open source projects.

You observe that it is better to be informed than ignorant.

This is true. Congratulations. Man we are all so smart for getting that right. How could anyone get something so obvious and simple wrong?

What you leave out is "in a vacuum" and "all else being equal".

We are not in a vacuum and all else is not equal, and there are more than those 2 factors alone that interact.

Foreign intelligence has free rein either way. The script kiddies are the only ones that can be stopped by technological solutions.

I believe it's: sanm LucasArts SANM/SMUSH video