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.
// Martin
_______________________________________________
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".
