> a degraded user experience, as the first time a user runs a new executable, Apple delays execution while waiting for a reply from their server.
The way to avoid this behavior is to staple the notarization ticket to your bundle (or dmg/pkg), i.e. "/usr/bin/stapler staple <path>." Otherwise, Gatekeeper will fetch the ticket and staple it for the user on the first run.
(I'm the author of xcnotary [1], a tool to make notarization way less painful, including uploading to Apple/polling for completion/stapling/troubleshooting various code signing issues.)
Xcode (the UI) is able to bypass GateKeeper checks for things it builds.
The "Developer Tool" pane in System Prefs, Security, Privacy is the same power. Drag anything into that list you'd like to grant the same privilege (such as xcodebuild). This is inherited by child processes as well.
The point of this is to avoid malware packing bits of Xcode with itself and silently compiling itself on the target machine, thus bypassing system security policy.
Reminds me of the AV exception folder our corporate IT created for developers. Soon absolutely everything developers needed or created was installed into that folder. Applications, IDEs, you name it.
Guilty as accused. I try to keep to an absolute minimum. Like docker data-dir and IDE. With that i can atleast use my machine.
otherwise this macos notarisation, along with a possibly of cpu heating issues with left thunderbolt usage and corporate av scanning, makes my machine, next to useless
GateKeeper only triggers the check for things downloaded from the internet.
IOW, it checks if your binary has a quarantine flag attached via an extended attribute.
> The way to avoid this behavior is to staple the notarization ticket to your bundle (or dmg/pkg)
Maybe in some cases, but the article says "even if you write a one line shell script and run it in a terminal, you will get a delay!"
Shell scripts don't come in bundles. I don't think this kind of stapling is possible for them? I don't think it'd be reasonable to expect users to do this anyway.
The Gatekeeper behavior is specific to running things from Finder (not Terminal), and only if you downloaded it via a browser that sets the com.apple.quarantine xattr.
Two posts from Apple dev support (Cmd+F "eskimo") describe this in more detail.
I recently learned that `xattr -cr path/to/my.app` solves the “this App is damaged would you like to move it to the trash” you get when you copy an app from one Mac to another.
No, it’s just that they’re becoming more popular. When you become a popular desktop OS, governments and militaries want to start using it which comes with some strange requirements. It also means that you can’t rely on “obscurity” to provide any sort of security, where before you could overlook some things.
I don’t know why grand op is downvoted. DoD requirements literally require a timeout setting for screensavers to begin locking. This has caught systems which have a race condition where you can move your mouse quickly and gain desktop access before it locks.
The long term effects come from the required changes to the development security model to remain productive and profitable (took MSFT a few OOB hotfixes and service packs to fix that example above, look when gnome kde xscreensaver etc introduced that feature etc)
Because it’s not, that’s why I pointed to xscreensaver feature implementation. Lock time is separate from screensaver activation time which is separate from energy saving activation time.
What defines when a locking screen saver is “locked”? 10m? Or 10m1s? You are making assumptions and that is what DISA spells out. Which forces the OS design to change in subtle ways. Like xattrs on files as great grand op was alluding to.
Does that provide clarity into how development security models evolve over the lifetime of an application?
It would appear to mean it's a hacky, over-technical solution to a problem that shouldn't exist in the first place, as copying things from one computer to another should just work™. This is one place where macOS used to shine and seems to be increasingly falling behind in.
> The Gatekeeper behavior is specific to running things from Finder (not Terminal), and only if you downloaded it via a browser that sets the com.apple.quarantine xattr.
The article says the described problem isn't limited in this way:
> This is not just for files downloaded from the internet, nor is it only when you launch them via Finder, this is everything. So even if you write a one line shell script and run it in a terminal, you will get a delay!
If you read the comments of the article and do your own testing, you will find that reality appears to be more complicated than the article suggests. Users have shown using both timing and wireshark that the shell scripts do not appear to be triggering notarization checks.
I mean, when I’m developing in a compiled language with the workflow edit code -> compile -> run (with forced stapling), changing it to edit code -> compile -> staple -> run doesn’t make it any less slow...
An update: flat out denying network access to syspolicyd using Little Snitch could cut down on the delay. (Yes, syspolicyd does send a network request to apple-cloudkit.com for every single new executable. Denying its access to apple-cloudkit.com only isn't sufficient either since it falls back to IP address directly.) Note that this might not be a great idea, and it still has nonzero cost — a network request has to be made and denied by Little Snitch.
Here's my benchmarking script:
#!/bin/zsh
tmpfile=$(mktemp)
cat >$tmpfile <<EOF
#!/bin/sh
echo $RANDOM # Use a different script each time in case it makes a difference.
EOF
chmod +x $tmpfile
setopt xtrace
time ( $tmpfile )
time ( $tmpfile )
unsetopt xtrace
rm -f $tmpfile
If your local terminal emulator is immune with "Developer Tools" access (interestingly, toggling it off doesn't bring back the delay for some reason), you should be able to reproduce the delay over ssh.
I can repro this locally as well. Interesting if it's inconsistent with Apple docs and when Gatekeeper should be firing, as running stuff locally without distributing/downloading is somewhat out of scope for notarization.
Reached out about this to Apple dev support, hope to get more insight.
But TFA and my personal experience do point to a noticeable delay after each recompile in dev workflows, and TFA claims this is due to notarization checks... So I guess I’m confused and you’re talking about something else?
The way to avoid this behavior is to staple the notarization ticket to your bundle (or dmg/pkg), i.e. "/usr/bin/stapler staple <path>." Otherwise, Gatekeeper will fetch the ticket and staple it for the user on the first run.
(I'm the author of xcnotary [1], a tool to make notarization way less painful, including uploading to Apple/polling for completion/stapling/troubleshooting various code signing issues.)
[1] https://github.com/akeru-inc/xcnotary