On Mon, Nov 2, 2020 at 3:06 PM Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Mon, Nov 02, 2020 at 11:44:00AM +0100, Paul B Mahol wrote: > > On Mon, Nov 2, 2020 at 11:21 AM Michael Niedermayer > <mich...@niedermayer.cc> > > wrote: > > > > > On Wed, Oct 07, 2020 at 08:19:12PM +0000, Paul B Mahol wrote: > > > > ffmpeg | branch: master | Paul B Mahol <one...@gmail.com> | Fri > Oct 2 > > > 12:16:49 2020 +0200| [da5b3d002862d1e105002a6dc1567e6551860896] | > > > committer: Paul B Mahol > > > > > > > > avcodec/tiff: do not abort decoding if strips are available > > > > > > > > Even if such files are invalid, they can be decoded just fine. > > > > > > Please provide such files so it can be implemented correctly > > > this commit causes security issues > > > Without such invalid-tile+stripe-jpegs which we can decode > > > its plausible that a fix to the security issue will break that > > > class of files again > > > > > > > > FIles are freely available on internet, use your search skills to find > it. > > As you know of a specific file and I do not, you should provide a link. > Or add a fate test ... > Its trivial for you, while searching the internet for a specific broken > tiff > file is not a trivial task. None of the files i have tested are affected by > this > Try harder. If you search user mailing list you would find links to such images. My upload speed is miserable. and files are big, 24 MB even for fate. > > You do not have to of course, but then what else do you imagine should > happen? > Do you want this to be reverted ? > Do you want a open security issue ? > Do you want other developers spend their time searching for a link you > have > but dont tell ? > > Iam sure you realize none of these options really makes sense > > Really. It makes sense to break working files with untested "security fixes". > thx > > PS: a fate test with that invalid tiff file also would be a good argument > for you against a revert > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Rewriting code that is poorly written but fully understood is good. > Rewriting code that one doesnt understand is a sign that one is less smart > then the original author, trying to rewrite it will not make it better. > _______________________________________________ > 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". _______________________________________________ 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".
