On 7/24/19, James Almer <jamr...@gmail.com> wrote: > On 7/23/2019 9:39 PM, Kieran Kunhya wrote: >>> >>> What was the cause of the slow decoding? Does this actually fix it, or >>> does it just swipe it "under the carpet"? >>> If someone ever found a sample with a different solution, how would they >>> know that they shouldn't just remove this again? Without any kind of >>> comment on the point of this call, people might assume it's pointless >>> nonsense. >>> >> >> A significant proportion of these patches sweep the issue under the >> carpet. >> Not to mention the swathes of annoyed developers >> >> Kieran > > The only very vocal people so far that i could see have been you and > Lynne. Everyone else at most didn't find these patches useful, but Lynne > especially has been very aggressive to communicate their displeasure > about fuzzing related fixes, and unjustifiably so. > If some of these patches affect code you're interested into, then > suggest nicer looking alternatives, like i did for the recent mpc8 patch. > > Patches like this one that fixes timeouts during fuzzing are usually > validation checks to abort on invalid data early, and in this case they > actually force an spec constrain in the correct place. They are hardly > clutter. And if they use what you consider magic numbers or heuristics, > or "sweep the issue under the carpet", you can always just request a > comment to be placed next to them, like Reimar just did, or use some > configurable value, like the recently added > AVCodecContext.discard_damaged_percentage > > My point is, instead of complaining about UB fixes, try to be > constructive about how to implement them better. Campaigning to migrate > the codebase to something else than C and cut the issue from the root is > more productive than replying to every other fuzzing fix like this.
This are not UB fixes, this are bandaids for some cases of too big frame width & height sizes given as invalid input to decoder. Instead of adding broken heuristic for every and each decoder one should simply limit video sizes which are being fuzzed. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
