[cebert]

It looks like the FFmpeg account on X is calling out Google for using AI to mass-report CVEs in obscure volunteer maintained codecs, then expecting unpaid maintainers to rush fixes. Large, profitable firms rely on FFmpeg everywhere, but don’t seem to be contributing much to the project.

[joatmon-snoo]

No, this is the unfortunate reality of “ffmpeg is maintained by volunteers” and “CVE discovered on specific untrusted input”.

Google’s AI system is no different than the oss-fuzz project of yesteryear: it ensures that the underlying bug is concretely reproducible before filing the bug. The 90-day disclosure window is standard disclosure policy and applies equally to hobby projects and Google Chrome.

[haskellshill]

Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?

[hdgvhicv]

“This is broken, here’s how I fixed it”

Vs “this is broken, you gave 90 days to fix it”

If you can’t see the difference you’re the existential threat to Free software that stems from the trillion dollar industries that just take.

[haskellshill]

> you have 90 days to fix it

Or else what? They release the report? That's standard and ffmpeg is open source anyway, anybody can find the bug on their own. There's no threat here.

If you're mad about companies using your software, then don't release it with a license allowing them to use it. Simple as that. I don't understand how people can complain about companies doing exactly what you allowed them to do.

[socalgal2]

A quick search of the ffmpeg commit history shows google has made plenty of contributions to ffmpeg. They may or may not provide a patch for this CVE but reporting it is the first step so people can then decide what action to take (like don't compile that codec in for example)

[blueg3]

I don't think Google is expecting anything here.

They run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe.

The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse.

It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it.

The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.

[TZubiri]

You think google uses ffmpeg for youtube?

[Telaneo]

They did once upon a time atleast.[1] Most videos probably go through dedicated hardware nowadays, but it wouldn't surprise me if some videos still have to go the FFmpeg route that catches all the videos that the dedicated hardware can't handle.

[1] https://web.archive.org/web/20110315155125/https://multimedi...

[joatmon-snoo]

They do.

[defrost]

Full build with all the codecs, or a custom build with a limited vetted set?

[Telaneo]

Does it matter?

Like, I don't expect Google to deliver patches for FFmpeg beyond bug fixes or features that directly benefit them, but that's the least you can expect.

[defrost]

It matters to Google if they process public submitted videos using FFmpeg codecs that can be exploited.

One would expect Google to only use FFmpeg with vetted codecs and to either reject videos with codecs that have untrusted FFmpeg modules or to sandbox any such processing, both for increased safety and perhaps to occassionally find new malware "in the wild".