On 18/01/2019 11:46, Carl Eugen Hoyos wrote: > No, you are completely missing the point.
I am not. I fully understand the argument in favour of these, I just don't agree. > Possible security issues in this decoder will only be > searched (and therefore found) if the decoder doesn't > timeout quickly on damaged files. I am aware, and I disagree with the premise of dumping all over the code and its complexity/readability in order to make a particular fuzzer happy, so we can be 100% sure it won't miss an issue. To that end, I've opened a bug with oss-fuzz for some guidance: https://github.com/google/oss-fuzz/issues/2095 > I assume this is the result of a (simple) cost-benefit- > analysis by the people running the fuzzing systems. Yes, the cost of them running the tests, not dev/complexity costs for downstream. > Nobody asks you to fix the issues, blocking them is an > interesting concept security-wise. It makes plenty of code horrible and unnecessarily complex, so you cannot simply argue "well you're not the one fixing them so bugger off". - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel