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

Putting Terminal (and your favorite text editor) in this category and in "Full Disk Access" will change your life.

How does "Full Disk Access" help?

You can browse Time Machine backup directory trees from the CLI again.

Yes, falling victim to ransomware is definitely lifechanging if you don’t have good backups.

That is a non-sequitur.

It's not; they are stating that if you bypass these security checks, you open the machine up to ransomware.

better not turn on it at all, to be extra safe

So since these permissions apply to process trees, what happens if you put launchd in there?

The computer will probably hang while it tries to solve the chicken-egg problem.

Isn't launchd Mac's ‘init’? I.e. run before anything else.

Yes, and that's the point — everything you run will theoretically inherit the permission from it.

Can you advise on how to make the "Developer Tool" panel in "System Prefs, Security, Privacy" appear if it is not present? Cant find a way: https://stackoverflow.com/questions/60176405/macos-catalina-...

Thanks for the link. Tried it, but that did not work

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.

That is not correct starting with Catalina.

How do I get a "Developer Tool" pane in System Prefs? Do I have to install X-Code? I would really rather not

This is life-changing. Thank you!

What did you notice?

> 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.

https://forums.developer.apple.com/thread/127709

https://forums.developer.apple.com/thread/127694

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.

That might be the Windows-iest feature of OSX I've ever heard of.

It seems macOS is going downhill fast these days.

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.

Can you cite any sources for your claim that these things are being implemented to satisfy government/military requirements?

DISA?

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)

> This has caught systems which have a race condition where you can move your mouse quickly and gain desktop access before it locks.

I fail to see how this is a race condition rather than how a screensaver is supposed to work?

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?

What would that mean?

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.

Quinn The Eskimo at Apple's forums is a 10x support engineer, his posts have helped me fix dozens of problems.

Unless somebody took over his name he’s been at Apple for almost 25 years, and was already being interviewed as such 20 years ago (http://preserve.mactech.com/articles/mactech/Vol.16/16.06/Ju...)

His site (http://www.quinn.echidna.id.au/Quinn/WWW/) supports its claim “I'm not a great believer in web” :-)

It's interesting to see a time when Apple seemed to allow employees to have side projects…

He needs to be, because Apple Developer Technical Support is chronically understaffed.

This is the way things worked prior to Catalina but is no longer the case.

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.

> interestingly, toggling it off doesn't bring back the delay for some reason

Noticed the same; it should come back if you disable it and reboot.

Notarization/stapling/etc. is for distribution only, not generally part of your dev workflow.

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?

How does mac identify a dev workflow and normal workflow?

When you use XCode you have different compilation options.

I'm confused. does macbook send executable to apple servers or just the hash?

Just the hash.

The way to avoid this behavior is to not buy a machine from a company that actively hates it's users.