←back to thread

361 points robenkleene | 7 comments | | HN request time: 0.864s | source | bottom
1. LeoPanthera ◴[] No.23285659[source]
I can't reproduce the exact test specified in the article:

  $ echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
  $ time /tmp/test.sh && time /tmp/test.sh
  Hello
  
  real 0m0.016s
  user 0m0.002s
  sys 0m0.010s
  Hello
  
  real 0m0.006s
  user 0m0.002s
  sys 0m0.004s
I don't believe the 0.01s difference is long enough, and could easily explained by filesystem caching. The article says:

> Some people try to explain away the delay, e.g., "I would put the 300 vs 5 ms down to filesystem caching", but such hand waving doesn't stand up to further scrutiny.

...but does not provide any "further scrutiny", so for me, occam's razor applies.

replies(4): >>23285714 #>>23285750 #>>23285970 #>>23285993 #
2. alexeldeib ◴[] No.23285714[source]
> You can verify that there's an online check by taking packet traces
3. boardwaalk ◴[] No.23285750[source]
It is real; browse the previous thread on this topic: https://news.ycombinator.com/item?id=23273247

It pushed me to buy Little Snitch to block it, so I guess somebody won out.

4. abathur ◴[] No.23285970[source]
A few ideas:

1. confirm the checks are enabled:

    spctl --status
2. Make sure your terminal/shell/etc aren't already exempted System Preferences > Security & Privacy > Developer Tools.

3. If you already ran something that could generate a check in the last minute, the connection is still open. Most of the overhead people are recording is negotiation/handshake. If you're fairly close to the server, it seems plausible your observed time could be enough for the communication minus the negotiation. You can open Console.app and search `process:syspolicyd` in the device log to see the entries for the negotiation; wait for it to terminate.

4. Try removing and re-creating a new file as in the test you did before and check it a little more directly:

    spctl --assess -v --ignore-cache --no-cache /tmp/test.sh
If it's working, you should see a log entry with the text "summary for task success" in it with a detailed breakdown of the request (times taken per phase, bytes sent/received, etc).
replies(1): >>23286696 #
5. _qulr ◴[] No.23285993[source]
There's no such "filesystem caching" phenomenon on macOS Mojave and earlier, so that theory falls apart rather quickly. There's also the consistent difference between timing results with internet connection enabled vs disabled.

I'm not sure why you couldn't reproduce the delay. There are several possibilities I can imagine, but these could only be proved or disproved by more testing. In any case, many people have reproduced the delay, on close to "factory default" Mac installs.

6. userbinator ◴[] No.23286696[source]
I don't have a system to check this on, but Apple seriously named an option "asses"?
replies(1): >>23286730 #
7. abathur ◴[] No.23286730{3}[source]
Ha, no. I'm the ass, here. Fixed :)