[FFmpeg-devel] [PATCH 1/3] Revert "avcodec: Add max_pixels options"

[Nicolas George]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161211/0e2563c2/attachment.sig>