[0x0]

Do you think you'll be able to use those tools in a gatekeeper-MAS-only world? Or if Apple ships prebuilt versions, how well supported will they be by the authors of those tools if they can't develop and compile new versions on the platform on their own?

For a preview of the future, try this one on macOS 10.12 today:

% lldb --one-line run /usr/bin/python

spoiler:

  Current executable set to '/usr/bin/python' (x86_64).
  error: process exited with status -1 (cannot attach to process due to System Integrity Protection)

[acdha]

Your example is just showing that Apple picked decent security defaults for binaries which they ship. SIP can be disabled any time you want and it doesn't apply to things you compile.

There is a genuine argument about control but overselling it just lowers your credibility, especially since it reveals tunnel vision: statistically very few Mac users need to run a debugger but more are at risk for malware which uses sensitive APIs.

[0x0]

I don't feel like I'm overselling this for developers (which this thread is all about). I've hit the SIP block several times trying to genuinely debug my python and ruby scripts. Sure I can disable SIP on today's intel macbooks, but what about the ARM toys that the story is all about?

Also, if you have malware getting far enough to try to ptrace binaries running on your uid, I would imagine things are still game over despite being prevented from debugging a new interpreter process. I'm not buying the malware scare when it comes to debugging newly forked processes on a non-root uid.

I think your argument would have been valid if I'd never clicked "enable debugging for this mac" in xcode.