MacOS Catalina: Slow by Design?

Okay, I've tried this test on my MacBook Air 2020 several times, first by saving the "echo Hello" shell script in an editor and then, because I wasn't getting the results the author experienced, trying again exactly as he wrote it. Essentially the same result:

    airyote% echo $'#!/bin/sh\necho Hello' > /tmp/test.sh
    airyote% chmod a+x /tmp/test.sh
    airyote% time /tmp/test.sh && time /tmp/test.sh
    Hello
    /tmp/test.sh  0.00s user 0.00s system 74% cpu 0.009 total
    Hello
    /tmp/test.sh  0.00s user 0.00s system 75% cpu 0.007 total

Is it possible that Allan Odgaard, as good a programmer as he unquestionably is, has something configured suboptimally on his end? Because it just strikes me as super unlikely that Apple has modified all the Unix shells on macOS to send shell scripts off to be notarized. (From what I've read, while shell scripts can be signed, they can't be notarized, and Gatekeeper is not invoked when you run a shell script in Terminal -- although it is invoked if you launch a "quaurantined" shell script from Finder on the first run, but it treats the shell script as an "executable document." This is the way this has worked for years, as I can find references to it in books from 2014.)

I have my complaints with macOS Catalina, and I know that Apple's "tighten all the screws" approach to security is anathema to a lot of developers (and if there was a big switch that I could click to disable it all, I probably would), but I'm using Macs running Catalina every day and I gotta admit, they just don't seem to be the dystopian, unlivable hellscape HN keeps telling me they are. At least off the top of my head, I can't think of anything I was doing on my Macs ten years ago that I can't do on my Macs today. ("Yes, but doing it today requires an extra step on the first run that it didn't used to" may be inconvenient, but that's not the same thing as an inability to perform a function -- and an awful lot of complaints about modern Macs seem to be "the security makes this less convenient." There's an argument to be had about whether Catalina's security model strikes the right balance, of course.)

I don't experience a delay in Terminal.app either, but I've tried running the script with a fresh install of iTerm2 while capturing with Wireshark and it does look like the script triggers a connection to an Apple server

I just ran the same script on iTerm2 and had no delay.

Obviously I can't say that's impossible, it would just be... very weird, and would seem to contradict what Apple Developer Relations was saying on Apple's devrel forums as recently as this year.

I had no delay neither until I reinstalled iTerm2, I have no idea why

10 to one says this is because you've run something calling /bin/sh before.

if he switched the /bin/sh out to /bin/zsh or /bin/bash which ever his default shell was, he wouldn't have seen the first delay.

Most vendors have separate engines for detecting malicious scripts. I'd assume notarizing is more about executables, in which case it would be checking the signatures around the shell binary.

Also worth noting "echo" doesn't spawn a process but is a routine in the shell itself. If you replaced echo with something that does spawn a process "like scp" it would be interesting to see the results. And if that's doesn't introduce latency then I'd try it with some hello world programs with a UUIDv4 in the binary to ensure they haven't seen the hash before.

That's plausible -- but I'd be (mildly?) surprised if Apple hadn't pre-okayed binaries they supply with the OS. Even if you flip the Super Paranoia switches in privacy settings, you don't need to give macOS explicit permission to launch Apple-supplied binaries from the Finder.

> and if there was a big switch that I could click to disable it all, I probably would

First, disable SIP to allow yourself to modify the system. Then, disable AMFI, the component responsible for code signature checking, entitlement enforcement and all that very useful stuff, with a kernel argument:

    nvram boot-args="amfi_get_out_of_my_way=0x1"

Then you should be done.

So its an actual fact documented that it happens. I agree that overall Mac os x still has a very nice ux and I'll never go back to windows.. But it's very clear apple is platforming their os to the degree they will ios. It's not weird it's happening, it's real life...

> Also worth noting "echo" doesn't spawn a process but is a routine in the shell itself.

In Bash echo is a builtin but /bin/echo also exists if you do actually want to spawn a process.

try again with a randomized filename

Maybe OP edited a few times but it doesn't look like they are doing that to me

I'm not sure I understand?

I might be wrong about this but if you're running a shebang'd script directly as an executable, they wouldn't need to modify the behavior of the shell itself but rather the executable loader. It would be interesting to see whether, e.g., `bash test.sh` doesn't phone home where "./test.sh" does.

I initially saw the delay in Terminal.app, but then it went away! I've made sure Terminal doesn't have the "Developers Tools" permission but the network request delay is still missing.

However, I was able to reproduce this by downloading a whole new terminal app, Alacritty. With the random script and file path I can always reproduce the delay in Alacritty. My guess is Terminal.app might have some special case behavior?

See my comment above on some shell script that does the random file name stuff for you.

That argument reads to me like the implementer knew this stuff was obtrusive.