[FFmpeg-devel] [PATCH] Workaround to build ffmpeg on MacOs 10.15

Martin Storsjö martin at martin.st
Sat Jan 4 21:25:40 EET 2020


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 <barsnick at 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



More information about the ffmpeg-devel mailing list