[FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions

[Lynne]

Jul 24, 2019, 11:08 AM by michael at niedermayer.cc:

>
> What did you expect ? IIRC you have asked for whole classes of security
> issues to be not fixed.
>
> Something like that would require a vote and majority of developers.
>

The way I interpret this: "Of course I ignored you, you're mental!", doesn't help. And I don't think its just me.
And you do remember incorrectly in saying that I want this whole class of security issues not fixed. In this thread I specifically raised the issue of what is considered to be a security issue by asking whether a speedup of failing to decode from 2 to 0.4 seconds is considered such or what's considered acceptable in general.
And I think I'll disagree that it is. 16 seconds to 2 seconds I can accept, but not 2 to 0.4.



>> These patches affect decoding of real world broken files in favor of fixing specially crafted fuzzed files.
>>
>
> Iam happy to look into such cases. Can you provide me with such
> "real world broken files"?
> Its not intended to worsen the output from such files
>

Simple logical analysis, "if file is somewhat broken, don't try decoding" does very well indicate that it won't only apply for _this_ broken file, but in general.
Thus, this is for you to prove. I've said it before that otherwise its a burden to other developers to have to screen all of these patches.



>> Sure, protecting against ddos attacts is important, but not important enough to make decoders give up early and return nothing. Especially in cases where the timeout speedup is of the order of 2s to 400ms.
>> Yet in all of those timeout patches all you've cared about is shutting up the tool. You've never once shown any figures if this could affect decoding, because its a lot harder than just showing they fix something some tool calls a timeout and forgetting about it. You haven't even commented on this when I asked you on IRC.
>> You also sneak this type of patches in when there's an overflow later on during decoding, which is completely incorrect in almost all cases, for the same reason above.
>>
>
> if you know of issues in a patch or commit you should report this
> during patch review or as soon as you find out about the issue
> as a reply to that patch or commit or as mail to the author.
>

That's what I'm doing.
That aside, you've completely ignored my statements on what's considered acceptable, showing figures, and sneaking this type of patches to fix undefined behavior.
Making your reply a simple refutation, rather than addressing anything I've said.
So I'm asking you again, what is considered a security issue and what is considered acceptable? And what is considered not a security issue but a complaint from an overzealous automated tool.



> So the author or any other developer can fix it or the patch is on hold
> until its fixed.
>

Is not commiting it at all because there is no issue, adds unnecessary code which makes things worse, only to speed failing to decode by milliseconds for a very specific crafted input to silence an automated tool completely not an option?



> Complaining out of context about unspecified issues. Or well IRC  (i dont
> know what you refer to here at all either)
> Is just guranteed to lead to frustration because that wont and cant lead to
> issues being fixed
>

I am complaining in the context of this thread about specific issues that I'm worried all of these patches have, and I'm not alone, despite you trying to label someone else's concerned reply as a personal attack.
I'm sure other developers would agree if asked, just probably not like this in a situation where a reply is labelled as an attack.



> PS: Again, i strongly suggest we work together to find acceptable solutions
> to these issues. Because that would lead to good solutions, and everyone
> being non frustrated. When one demands "dont fix it" that is what leads
> to a fight and frustration and a blocked patch so really both sides are
> unhappy and frustrated
>

We are. Or I'm trying to, but being simply refuted only goes so far.