> jia-tanned the source
I think that is a bit of a misunderstood incident in that the wrong lessons seem to have been taken from it.
The primary takeaway should be "blobs are not acceptable in source", which includes tests.
Yes, it's better for the tests to *dynamically generate* test data if such is necessary (this makes it auditable without resort to all sorts of other tools).
A second lesson is that build artifacts are supposed to be reproducible. The tarfile shenanigans it was doing were very much not reproducible from the source.
Just insisting on source (version tracked) and reproducibility neuters the attack entirely.
In fact, building the compromised version from tracked source-only didn't enable to attack to work because the injection part was in the tarfile.
>> This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf
It's bad, this is literally what `autoreconf` (and `git clean -Xi` & `git clean -xi`) is for.
If you're downloading source you're already building, why not just keep building a bit more?
Whereas end-users that don't want to build are downloading binary blobs (binary packages) entirely to start with.
> but maybe going through the source code for even a super slim chance is better than running it blindly, isn't it? if thousands of people glance at the source code a bit, one of them might catch something.
Yeah, it often takes some very mild heuristics to find things, just with unyielding adherence to principles.
> the bento4 library i mentioned (for mp4 file manipulation when ffmpeg failed) seems to include its structs from their own headers in the crypto part which would probably make patching the codebase extremely painful. maybe the crypto part is needed, since it does decryption schemas that ffmpeg can't seem to handle?
Yeah, that sounds either painful but justified or sus, in either case enough to put it back at the back of the list of possible options to hopefully never come back to.
> it does decryption schemas that ffmpeg can't seem to handle?
[DRM shenanigans](https://www.bento4.com/#features)?
Yeah... at that point you don't really have a choice but to understand what it's doing or execute it in some isolated environment and hoping that's enough.
(Like VM receiving data from a socket, replying to it, and dying immediately after.)
Or disable all the related code and delete it, but then that's probably the crap ffmpeg choked on.
> either way i did replace it with gpac which as far as i know is completely filled with vulnerabilities (and that's why it got dropped from some distros)
I don't know. One probably needs to look at mailing list archives.
> generally feels like any tool that touches video is a hot mess and ffmpeg might be the most user-friendly of them.
It certainly gives that impression and corposcum are largely to blame.
