[AbrahamParangi]

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.

[woodruffw]

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

[gcr]

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

[woodruffw]

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

[SergeAx]

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

[eddd-ddde]

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

[rsanek]

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.

[jakeydus]

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.

[Brian_K_White]

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.

[rcxdude]

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

[Brian_K_White]

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.

[eptcyka]

Which codec is it?

[tptacek]

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

[Brian_K_White]

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.

[strken]

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?

[zamadatix]

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 :).

[bawolff]

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

[HDThoreaun]

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

[user3939382]

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

[user3939382]

I like how some coward downvoted with no response when my counterpoint is devestating.

[gr4vityWall]

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

[Aurornis]

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.

[KingMob]

> 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?

[watwut]

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

[surajrmal]

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.

[Orygin]

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.

[kllrnohj]

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

[janalsncm]

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.

[kragen]

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

[rocqua]

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.

[walletdrainer]

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!

[rocqua]

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.

[walletdrainer]

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

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

[xign]

Except users can act accordingly to work around the vulnerability.

For one, it lets people understand where ffmpeg is at so they can treat it more carefully (e.g. run it in a sandbox).

Ffmpeg is also open source. After public disclosure, distros can choose to turn off said codec downstream to not expose this attack vector. There are a lot of things users can do to protect themselves but they need to be aware of the problem first.

[raincole]

Security by obscurity. In 2025. On HN.