On Sun, Dec 11, 2016 at 05:47:34PM +0100, Nicolas George wrote: > Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit : > > we need these limit paramters for fuzzing to be practical. > > Maybe, but we can take a few days to do it properly instead of rushing a > badly-designed "fix" that does not fix anything and then being forced > into a maintenance nightmare because of it. >
> First step: these commits and options must go away immediately; Well, we need these options for efficient fuzzing > > Second step: you show us exactly what problem you are trying to solve. There are multiple independant things these options solve I belive i explained all already, but Fuzzers search and find issues like out of array accesses but also hangs and oom conditions. Fuzzers find hangs and OOM conditions by executing code until it runs out of memory or reaches a timeout. These cases are then reported and need to be checked by a human (that being me in practice it seems) ATM almost all of reported issues are false positives, going through them takes significant amounts of time. the max_pixels parameter should fix this as all the cases i looked at where hitting out of memory or timeout because of very high resolutions. The 2nd issue this fixes is a CVE that was reported about a crafted file with i belive 26k streams hitting OOM. If you belive this CVE is invalid and not a security issue iam totally the wrong to discuss that with. But i like to fix issues instead of arguing about why they are or are not a security issue. The 3rd is that as a user i like to be able to set limits on pixels and streams to limit resource use and avoid crashes The 4th is that it seems to me everyone else on oss-fuzz can avoid this issue, why is something so basic so hard on ffmpeg-devel ? It is very likely there are more problems this fixes maybe a browser loading a image that it knows should be 256x256 ? i dont know, but why shouldnt the user be able to limit the number of pixels? > > Third step: we discuss and implement a proper solution. I already did that and the previously applied solution is the result. If you (singular or plural) dislike how its done, noone stops you from proposing and implementing a better solution. as said, from my point of view the solution is what is needed. and ive spend many times the time on this (mostly discussions) that i would have wanted to. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
