Earlier quoted context omitted.
You think google uses ffmpeg for youtube?
They do.
Full build with all the codecs, or a custom build with a limited vetted set?
FFmpeg dealing with a security researcher
51–60 of 174 posts
Re: FFmpeg dealing with a security researcher
#52Rather unprofessional for an official project twitter account to complain about "slop" > We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix. Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just be…
This is a volunteer-run open source project. Your expectations are unrealistic and, to be quite frank, offensive.
If a volunteer-run project wants to be full of CVEs and inevitably bleed users because of it, fine, but to whine about someone reporting a CVE in the first place is ridiculous. I'm not annoyed they haven't fixed it, I'm annoyed they're complaining about the problem being acknowledged.
Re: FFmpeg dealing with a security researcher
#53The comments from the public.. Just wow we are doomed.. To explain, Googles vulnerability scanner found a problem in an obscure decoder for a 1990s game files (Lucasfilm Smush). Devs are not happy they get timewasting reports on stuff that rarely anyone ever uses except an exceptionally tiny group. Then people start berating them without even knowing the full story...
>rarely anyone ever uses It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4
If only Google had the ability to custom compile FFmpeg to only include robust mainstream codecs.
In such a would they might even handball submitted obscure codecs to a full build in a sandbox to track bleeding edge malware.
Re: FFmpeg dealing with a security researcher
#54Rather unprofessional for an official project twitter account to complain about "slop" > We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix. Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just be…
Nah, I think they can rant as much about it as they want, nothing is unprofessional on Twitter - have you seen the state of of it?
Actually I think they are using correctly, you are suppose to post something to provoke the most reactions you can.
But getting back to the point, I agree, it is not really a problem if you actually verified your input before blindly running ffmpeg on it - like people are not just downloading random files and running ffmpeg on it are they?! You would think if you are rolling ffmpeg into production code you would know the ins and outs of it.
Anyways I feel for those open-source maintainers, they must have so deal with so much noise.
Re: FFmpeg dealing with a security researcher
#55Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/
Wow these people have a lot of free time... shouldn't they be programming?
Re: FFmpeg dealing with a security researcher
#56Earlier quoted context omitted.
>rarely anyone ever uses It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4
If only Google had the ability to custom compile FFmpeg to only include robust mainstream codecs. In such a would they might even handball submitted obscure codecs to a full build in a sandbox to track bleeding edge malware.
To my understanding this bug would affect anyone using ffmpeg on untrusted input. Google may already be limiting to certain codecs in their own use, but should still report the issue (as they have here).
Re: FFmpeg dealing with a security researcher
#57[flagged]
The one nice thing is Google had submit a real bug at least.
The human idiot "researchers" will send paragraph long automatically generated extortion threats over not sending HSTS header
Re: FFmpeg dealing with a security researcher
#58Not sure why the Twitter account is complaining about this now. Maybe it's part of a bigger sequence of issues? This particular one was resolved pretty quickly, back in August.
The Google bug report is dated August 21: https://issuetracker.google.com/issues/440183164
There are FFmpeg commits apparently fixing the sanm codec problem within a day or so: https://github.com/FFmpeg/FFmpeg/commits/140fd653aed8cad774f...
Earlier, on August 20, there are FFmpeg fixes for other issues in the same codec apparently also found by Google (by fuzzing not AI?): https://github.com/FFmpeg/FFmpeg/commit/5f8cb575e83a05bc95b8..., https://github.com/FFmpeg/FFmpeg/commit/e726f7af17b3ea160b6c...
Re: FFmpeg dealing with a security researcher
#59Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/
it’s very… sad, i guess, watching a lot of software engineering discourse on social media (at least, what I see from Twitter) just become this attention grabbing shitposting. ffmpeg is very much a big player in this field, and it has paid off handsomely - those tweets are often popular on site, and shared across other social media.
> paid off handsomely
Paid off how? Did they get more funding? More contributors?
Re: FFmpeg dealing with a security researcher
#60Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/
The most interesting part of that is the admission that they used decompilers to reverse engineer the codecs. I wonder if makign that output freely available is legal.