91–100 of 216 posts
Earlier quoted context omitted.
I'm glad to see their sense of humour :-) https://nitter.net/ffmpeg/status/2039115531744334180
> Assembly is a human readable version of machine code. It's exactly the same. goddamn, and this is a project that prides itself on having had-written assembly in it
Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... So, while it's a demo of the capabilities of LLMs, this should not be at all surprising.…
Time to RIIR, then?
A few months ago I started working on a system that finds critical security issues and opens PRs instead of just filing reports. The acceptance rate is sitting at roughly 94% so far. Most of the failures were due to project-specific kill switches or other internal mechanisms that weren’t documented, not because the vulnerability itself was misidentified.
Developers generally seem to prefer this approach. A bug report creates work. A good PR removes work. That sounds obvious, but a lot of security products still stop at the report and call it a day.
Earlier quoted context omitted.
> Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. You would change your opinion quickly if your browser, apps and TV suddenly stopped supporting videos due to relying on FFmpeg.
What prevents running a data stream in, transcoded data out sandbox with no access to unlimited resources, system files, system stacks, etc. It's okay for a sandbox to fall over due to bad inputs and poor memory security if it can just be restarted and move onto other streams.
Thus:
1. Code which processes untrusted input
2. Code written in unsafe languages like C or C++
3. Code that runs without a sandbox
So ffmpeg should be sandboxed, same as the network code and GPU process are sandboxed.
Earlier quoted context omitted.
> Ok but who is going to sift through it all to triage the good bits when you're working on something for free? Its like anything else in open source. Maintainers will do so if they care. Maybe they decide they don't care. That is always their decision to make but there are consequences for the project. Maybe those consequences make sense. Being a maintainer is all about making cost-benefit trade offs. > Who gives a…
Yes, and people will sit there and sip tea while waiting for "someone"? For how long?
Until someone cares enough to do it. This is open source software. When it comes to open source, the golden rule is you either do the things you care about yourself or stfu.
Given the libav fork wasn't all that long ago, it can obviously happen to ffmpeg just as much as it can happen to any other project.
Earlier quoted context omitted.
> Assembly is a human readable version of machine code. It's exactly the same. goddamn, and this is a project that prides itself on having had-written assembly in it
There's certainly assembly that maps directly to the machine language bytes, I assume you are talking about the version of assembly with the high level loop macros
I think the industry is optimizing for the wrong thing. Generating thousands of AI-written bug reports is easy, at least with Mythos (preview 1) or GPT-5.5. Getting bugs fixed is the hard part. A few months ago I started working on a system that finds critical security issues and opens PRs instead of just filing reports. The acceptance rate is sitting at roughly 94% so far. Most of the failures were due to project-sp…
Earlier quoted context omitted.
They're also extremely hostile to security researchers who report these issues.
https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw... Security is the punch line for ffmpeg.
Earlier quoted context omitted.
What prevents running a data stream in, transcoded data out sandbox with no access to unlimited resources, system files, system stacks, etc. It's okay for a sandbox to fall over due to bad inputs and poor memory security if it can just be restarted and move onto other streams.
I think Chromium already does sandbox ffmpeg in the renderer process because of their "Rule of Two": https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s... Thus: 1. Code which processes untrusted input 2. Code written in unsafe languages like C or C++ 3. Code that runs without a sandbox So ffmpeg should be sandboxed, same as the network code and GPU process are sandboxed.
Cheap arse low resource TVs should either include some form of sandboxing OR the entire device should be treated as a "can fall over" sandbox .. well isolated from any household LAN of consequence, etc.
It seems unlikely that BoxStore Brand Android TVs will be well designed with an eye to security so they're an exercise for home net admin masochists and/or an opportunity to market sensible easy to use IoT age routers that come preconfigured to handle bad-device(s).
Earlier quoted context omitted.
Funny, John Carmack was just admiring the creator of ffmpeg the other day for being a better programmer. https://x.com/id_aa_carmack/status/2064095424420487226?s=46
[flagged]
Except yourself, presumably, to me it almost seems nobody is perfect.