|
> What we do to combat that is
All patches going into FFmpeg are > reviewed with security in mind > > The codebase was repeatledly tested with fuzzed files to uncover all > kinds of anomalies, all such found anomalies where fixed. Also > independant of googles fuzzing efforts, some of our users have done > their own fuzzing. And during google code in several students have as > well manually tried to find security issues. > > FFmpeg is regularly tested with static code analyzsers like coverity > and most issues found get quickly fixed > > FFmpeg is tested regularly with runtime memory checkers like > valgrind, address sanitizer and others and all reproduceable issues > are fixed, iam not aware of any open and reproduceable one > > Almost all of the internal APIs used in FFmpeg are designed to be > secure, always passing array sizes and checking them instead of > assuming the caller knows they are large enough, exceptions to this > are just the most speed critical parts. > > Codecs which are WIP and arent up to security standards can be and > are marked as experimental and will not be selected during > autodetection unless overriden by the user. Something else to add to this list is that ffmpeg has a far larger base of installed users bring the "more eyes" principle into play. I can't speak as to how many linux distros use which fork, though I believe the vast majority of all libav installs are debian and its derivatives. Ffmpeg, meanwhile, has a huge install base in the Windows and to a lessor degree Macintosh worlds as the backend to nearly every free video player or transcoder out there. Virtually no upstreams with a choice are adopting libav, and I expect the number of those supporting it to dwindle as it continues drift away from ffmeg. I don't see this as being much different from the imagemagik/graphicsmagic situation. Sorry if my message formatting is screwed up. I'm on windows and have no idea what I'm doing. |