Clarify restrictions / security as applied to development on Apple Sillicon?

I develop mainly UNIX-style command line applications without Xcode and use plenty of open-source software that isn't necessarily Mac-specific or signed (e.g. from GitHub repositories). Given the new security enforced at the hardware level, I'm concerned what this means for my development cycle. On Catalina, you can re-enable "download from anywhere" via command line. Since I'm not able to get an Apple Silicons development kit, I can't test behavior myself.

if someone knows already or is expecting a development kit, it would be great to get more information. These are some of my questions:

Will I still be able to compile code locally and run it without code-signing? Might I be able to re-enable download from anywhere like on Catalina, so people in my own group can run binaries I might send securely (not via the App Store)? I am wondering, also, if the tagged pointer memory in the WWDC presentation will be optional, or if the idea is that it will be mandatory once Apple gets them working for user-level programs.

I currently use home-brew to download the latest versions of clang and packages, again not for Xcode Mac apps, but rather command line programs. Will I still be able to do this once home-brew/llvm update to build to arm Macs?

Lastly, can I always just disable SIP at my own risk to restore full freedom, or is this unrelated?

Note that I understand all of the security risks. I just want to know about all options. For Development purposes and research, it's sometimes beneficial to enable easy non-signed development and sharing and simply be a responsible programmer/computer user.

Thanks.


I can’t talk about Apple Silicon stuff. I recommend that you review the WWDC sessions on this topic, which I think you’ll find pretty reassuring (especially WWDC 2020 Session 10686 Explore the new system architecture of Apple Silicon Macs).



I do, however, want to talk about your current practices. You wrote:

Will I still be able to compile code locally and run it without code-signing?

IMO this is a mistake, even on 10.15. Many macOS subsystems expect to be able to reliably identify code. If you don’t sign your code, or sign it ad hoc, your code doesn’t have a stable identity and these subsystems start behaving weirdly.

A classic example of this is the keychain. I regularly field reports from developers where the keychain is continually throwing up authorisation prompts, and the most common cause is that their code doesn’t have a stable identity.

On Catalina, you can re-enable "download from anywhere" via command line.

Yikes! Please done do that. On 10.15 Gatekeeper only checks code when it’s quarantined. If you want to run random code you download from the ’net, you can just un-quarantine it. That’s much better than disabling this setting globally.

so people in my own group can run binaries I might send securely (not via the App Store)?

If this secure channel sets quarantine, the recipients can just remove that. However, many UNIX-y channels, like sync and scp, don’t set quarantine and thus even this isn’t necessary.

Lastly, can I always just disable SIP at my own risk to restore full freedom, or is this unrelated?

Why are you disabling SIP? Don’t get me wrong, there are good reasons for this, but it’s not something you should do lightly [1]. Personally, I never disable SIP on my main machine (that’s what VMs are for).

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

[1] For example, it exposes you to stuff like this…

daringfireball.net/linked/2019/09/25/mr-macintosh-chrome-updater
I appreciate the concerns about doing or not doing those practices, but really I just wanted to know if they’re possible.
With all due respect, I am careful. Also, the programs I’m referring to are UNIXy and don’t really use system services, so that’s less of a concern.

By securely, I meant, I hand a usb drive physically to the person and watch them try my application, or I send via some secure service that isn’t e-mail. The idea is that right now the computer blocks unless I disable “download from anywhere” even if I self-sign.

Can you elaborate on what disabling SIP actually does? Am I mistaken that it disables signing restrictions?

In any case, regardless of the safety of these practices, can I always go ahead with them in the worst case, or so we simply not know yet when it comes to Apple sillicon?

I think you quoted a 2019 wwdc talk here
suggesting that Apple has committed to letting you re-enable things, but I’m not sure—is this no longer a guarantee?

If it makes people more at-ease, I would typically only do something like this with the internet off or with some LAN where I’m not exposing the system to malicious software.
You'll always be to choose to run any software you want on a Mac, even if it's not a good idea.

With disabling SIP and using spctl to disable security features, you are using an incredible set of sledgehammers for things that aren't even likely necessary.

I'd also like to note that when macOS blocks an app from running, there's always a help button in the dialog that appears that tells you how to approve that specific app.

Apps you compile yourself on your local machine don't have the quarantine bit set when run on your local machine, so they don't hit anything you're trying to disable. As Quinn noted, these should still be ad hoc codesigned, if possible:

codesign -s - -vvvv --options=runtime <my app or binary>

(passing - to the -s arg means Ad Hoc)

Might I be able to re-enable download from anywhere like on Catalina, so people in my own group can run binaries I might send securely (not via the App Store)?

All of your other points were addressed above, but not this one. This is a distribution. You are now asking that other people disable their security for your convenience. How do they, or you for that matter, know that homebrew hasn't been compromised and you are now distributing malware? Because your security is disabled, it isn't possible for you to send anything securely.

Just sign and notarize your software. Problem solved.
Clarify restrictions / security as applied to development on Apple Sillicon?
 
 
Q