On Sun, Aug 18, 2019 at 11:04:20AM +0200, Paul B Mahol wrote: > On Sun, Aug 18, 2019 at 10:25 AM Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > > On Sun, Aug 18, 2019 at 09:21:25AM +0200, Paul B Mahol wrote: > > > NAK > > > > What problem do you see in this patch ? > > > > What change do you suggest ? > > or what alternative fix for the issue do you suggest ? > > > > a DOS issue in png will have to be fixed, otherwise major > > users would have to use different libraries for *png and > > disable it in their libavcodec. > > > > What other png libraries do this thing?
which libraries do you want me to check ? libpng seems to support incremental decoding of images so that pixels "sparkle in" as they are decoded. I dont think it rejects based on a user parameter. such a sparkle in feature doesnt exist in libavcodecs API in this form Iam not sure how this information above helps us with this patch We can reject every image that has any pixel missing, this would break decoding of real files probably which are truncated We can reject no image based on missing pixels, this would make the decoder more vulnerable to DOS attacks. We can honor the user parameter intended for this purpose and reject images missing most pixels, this is what the patch does We can hardcode some arbitrary threshold of how much can be missing before rejection We could do something completely different, but i need to know what exactly is preferred What does the community prefer ? Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn
signature.asc
Description: PGP signature
_______________________________________________ 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".
