On Sat, Jan 04, 2020 at 10:35:59PM +0100, Michael Niedermayer wrote: > On Sat, Jan 04, 2020 at 09:25:40PM +0200, Martin Storsjö wrote: > > On Sat, 4 Jan 2020, Michael Niedermayer wrote: > > > > >On Sat, Jan 04, 2020 at 12:06:55AM +0100, Henrik Gramner wrote: > > >>On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick <barsn...@gmx.net> wrote: > > >>>On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote: > > >>>>I think this was discussed on this list in the past. > > >>>>Not sure what the conclusion was, but I think an unconditional flag like > > >>>>this being added wasn't all that well received. > > >>> > > >>>Yes, discussed in this thread in November: > > >>>http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253193.html > > >> > > >>Lmao "security feature". Just disable that flag and call it a day, it > > >>adds nothing of value (unless you consider crashing to be a "security > > >>feature"?). > > > > > >I dont know how effective this is or what exactly this option does, i > > >couldnt find documentation for it quickly what it does in clang on macosx. > > >google keeps pointing to gcc > > >but > > > > > >a crash is better than arbitrary code execution, which IIUC is the idea > > >here, if the stack of a thread grows too much, crash instead of overwriting > > >something that comes after it. > > >Not crashing when the stack overlapps another threads stack or heap is > > >unlikely to be better. > > > > The point here is, disabling this "feature" is not a security regression - > > it's a new feature in apple's clang, which only is enabled when you target a > > new enough version of macOS. And that new security feature is broken to the > > point that the process crashes before you even get to code which may be > > misbehaving. > > > > So disabling it isn't a regression, it just takes things back to how things > > were before, before this was introduced. > > Is it difficult to detect if the compiler has this bug ? > Iam asking because disabling this feature only when needed avoids the > questions related to "what happens when it is fixed". >
> We could wait for it being fixed and then add a check on the > version number and then backport that to any release which may need it. > If it is difficult to add a check now Clarifying this slightly as re-reading sounds ambigous What i meant is to disable it for apple/clang now and then if its fixed replace that by a version check. (if adding a check now is difficult) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
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".