Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit : > Well, we need these options for efficient fuzzing
We need SOMETHING, maybe, but not specifically THESE. > There are multiple independant things these options solve > I belive i explained all already, but You were vague. We only start having details now. > 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. Then run the fuzzers with a low address space limit. Problem solved. > 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. Open a ticket, attach the file, we can all discuss what the proper fix is. > 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 ? I do not know. I suppose this is just a misrepresentation of the reality. > 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 > > 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? Both these paragraphs seem awfully ad-hoc. Nobody ever asked to limit the number of pixels until you came up with this feature. > > Third step: we discuss and implement a proper solution. > I already did that and the previously applied solution is the result. It is not a PROPER solution if it brings us into a maintenance nightmare. > If you (singular or plural) dislike how its done, noone stops you from > proposing and implementing a better solution. Yes, somebody is stopping us: you, with these badly designed features. > 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. Then please move on and spend your valuable time (without any kind of sarcasm here, I really believe your time is very valuable to the project) on something else and let the discussion carry on. Please forgive me if I am out of line, but I think I can say it because I consider you as a much better hacker than me: it seems to me that seeing the big picture is not your strongest suit. To give an example, I think Anton, with his "evil plans", is good at seeing the big picture (and also has the courage and stamina to make it work). This is precisely a case where the big picture is needed. We can, collectively, try to see it and find a solution to all you mentioned above. But for that, these commits have to go, they are in the way. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
