We have posted about this topic before: https://x.com/FFmpeg/status/19...

A 1990s game codec is not the same as a mainstream codec like H.264.

@FFmpeg I like most of the stuff you post but this line of reasoning doesn't make sense. The code was already broken before Google found the bug. Finding security vulnerabilities and reporting them publicly is valuable for the world. It's better than Google *not* doing that, and

@DavidEGrayson It's someone's hobby project of an obscure 1990s decoder. A trillion dollar company is tasking an AI to find bugs and is assigning CVEs. Yet expects volunteers to fix it.

@FFmpeg People's hobby code? Ffmpeg is used everywhere. Also don't they contribute financially to the cause?

@TeachableAI LucasArts Smush is from 1990s video games and implementing it is someone's hobby project

@FFmpeg How can you say you take security very seriously and then get upset that you received a detailed, accurate bug report complete with code to reproduce the issue? And again, Google's OSS Patch Rewards will pay people for patching code like FFMpeg.

@AHJohnston The author of Lucasfilm Smash, a 1990s video game codec is writing this as a hobby. A trillion dollar corporation like Google should be the one sending fixes. If Deepmind is that good, surely it should be doing it.

@FFmpeg Change your policy so low usage toy decoders don't get assigned any cves, only bugs

@PhantomStnd It's Google getting the CVEs assigned, not us

@FFmpeg If the AI can generate such a detailed report, it can submit a PR with the fix.

@FFmpeg FFmpeg : Powers the internet

@FFmpeg Safety has assumptions of use, does security have anything similar where it can be stated FFmpeg should be considered appropriately when used. For Google, it seems like they just need a paper trail of known issues, then they can ensure they don’t use the tool in an insecure way.

@FFmpeg perhaps deactivating old and obscure codecs and hiding them ander an "--use-untrusted-codecs" flag could be an option? I mean there is very high value in being able to read old video files, but ffmpeg is often called with untrusted input in webapps etc. so this could be a

@FFmpeg The lone comment (from a Google email) indicates that this was fixed in 8.0. Not clear if that's in reaction to the report or not. Is this the sum total of human interaction from Google on this?

@FFmpeg You are making the assertion that they expect anyone to fix it. A bug report is not a “fix this now, or else.” Stop treating every single bug report - especially if it comes from a major corporation - as a demand of action. This behavior makes you sound unfit for FOSS.

@FFmpeg The amount of people not understanding your point and the whole situation is a show of pure retardation. And they call themselves engineers, etc, etc... Fucking stupids... They need to be locked for an year listening Mark Atwood so we can see if there is any salvation for these

@FFmpeg “How dare you not make something perfect! Try harder, peasant, and also use my pronouns!”

@FFmpeg In reality, they’re also just using your repo and how you interact with their pts to train their ai. This is simply using open source for yet more free money unless they have a legally binding set of terms that prohibits that.

@FFmpeg No one is forcing you to do anything about it. Simply close the issue and respond with "patches or nothing" If they want it fixed so bad, they should do it themselves

@FFmpeg WHY would they be fair? Corporations only do profit If we want to push back then there needs to be unions or strikes or something like that - only way to fight big corporations is even bigger people power ✊

@FFmpeg Google is correct, but it’s close. It has a proof of concept and isn’t an AI slop report. High-quality reports provide better information. 90-day disclosures are crucial for open source reputation. Including a fix would enter AI slop territory for performance and add other bugs

@FFmpeg Would it be better if they didn’t report on it? This way you at least know and can prioritize?

@FFmpeg I see it in a few ways: 1. It is ultimately "just" a CVE disclosure. 2. Anyone is welcome to contribute a fix if they care about this decoder. 3. If the decoder is not widely used, leaving the issue open is perfectly reasonable. Or drop support, if maintaining is not realistic?

@FFmpeg I don’t think this implies that they “expect a hobbiest to fix it”? The CVE is a warning that this is indeed a hobby project that should not be used in production.

@FFmpeg Yes, I think it’s fair. They leave the work to fix the issues to experts, not to a stochastic parrot.