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 , a tool to make notarization way less painful, including uploading to Apple/polling for completion/stapling/troubleshooting various code signing issues.)
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.
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
Isn't launchd Mac's ‘init’? I.e. run before anything else.
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.
Two posts from Apple dev support (Cmd+F "eskimo") describe this in more detail.
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)
I fail to see how this is a race condition rather than how a screensaver is supposed to work?
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?
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!
His site (http://www.quinn.echidna.id.au/Quinn/WWW/) supports its claim “I'm not a great believer in web” :-)
Here's my benchmarking script:
cat >$tmpfile <<EOF
echo $RANDOM # Use a different script each time in case it makes a difference.
chmod +x $tmpfile
time ( $tmpfile )
time ( $tmpfile )
rm -f $tmpfile
Reached out about this to Apple dev support, hope to get more insight.
Noticed the same; it should come back if you disable it and reboot.