21 ms·

Catalina is checking notarization of unsigned executables

361 points by robenkleene 6y ago

thih9 6y ago
The article mentioned at the beginning is already discussed here: https://news.ycombinator.com/item?id=23273247 https://news.ycombinator.com/item?id=23273247
- deleted 6y ago
  [deleted]
  - FriendlyNormie 6y ago
    Why?
verytrivial 6y ago
#include "This is fine meme.h"
rvnx 6y ago
It's great tool for mass-surveillance. Since Apple has a database of all the apps the user has run on their device (but no worries, Google has the same). For your security ;)
- tenebrisalietum 6y ago
  So why mass-surveil Apple computer users this way? My understanding is the only thing exclusive to Apple systems is developing Apple apps. But anything related on a platform like iOS is already going to be public knowledge. Also the latest Mac hardware seems to go through great pains to make sure the primary storage device is both encrypted, unrecoverable if keys are unknown (T2 security chip), and non-removable (SSD soldered to board). So why would they make this back door for surveillance?
  - dannyw 6y ago
    None of those measures you described counteract mass surveillance.
- jmull 6y ago
  > great tool for mass-surveillance It’s not really that great for mass-surveillance. It “phone’s home” only on first run. And it doesn’t look like it sends data about your identity, device or location. They can have your IP address but another mechanism would be needed to relate that to you. (I doubt they are logging the IP address anyway. The only purpose would be to surveil you, but if they wanted to do that they would surely use a more capable mechanism . That makes keeping the IP addresses a burden and risk.)
  - yyyk 6y ago
    >It “phone’s home” only on first run. Do we know that? The cache may well have an expiration date. Does the cache stay after an OS upgrade? I suspect further research will discover it's not just 'first time'. >They can have your IP address but another mechanism would be needed to relate that to you.... if they wanted to do that they would surely use a more capable mechanism. The app profile would already tell a great deal. Once enough of these 'non-capable' surveillance mechanisms add up, you end up with a very capable surveillance mechanism.
londons_explore 6y ago
This must be a blacklist, since it doesn't block my own random scripts which it has never seen before. If it's a global blacklist on apple servers, it should instead be downloaded to the client, and be a local blacklist. Too big? Use a bloom filter. Now you only end up keeping less than one byte per blacklisted item. Update the bloom filter with an autoupdater. Any positive hit you can check against the server just incase it's a false positive.
- daneel_w 6y ago
  Bloom filters are probability-based and come with inaccuracy problems. If you're going to double-check with Apple anyway what does a bloom filter solve compared to the current response caching after querying Apple? How will you protect the locally cached blacklist from being tampered with?
  - w-j-w 6y ago
    Bloomington filters have probabilistic false positives, making it perfect for blacklisting. A negative means that the program can be run immediately, because it is guaranteed to not be on the list. A positive needs to be double checked, though.
- JackC 6y ago
  The k-anonymity scheme used by the haveibeenpwned api seems like a good fit here.
- caf 6y ago
  Doesn't a blacklist also work only until the malware authors figure out how to randomize 8 junk bytes every time they serve an executable?
  - therein 6y ago
    Which they already do.
  - dimator 6y ago
londons_explore 6y ago
So you're telling me that every time I install a program in OSX, it pings apple to let them know what program I'm installing, my IP address, my location, and my OS version? Sounds very Orwellian for a privacy focussed company...
- trashburger 6y ago
  Of course, if they say it's for your privacy, it's fine, and everything is all right. We have won the victory over ourselves. We love Apple.
  - daneel_w 6y ago
    No, they say it's for your security, and we can surmise that's the actual intention in Apple's case, but I definitely understand the privacy concerns that come with this method.
- daneel_w 6y ago
  No, that's not what he's telling you. You're getting ahead of yourself with your question. He's telling us that macOS will consult with Apple regarding the "fingerprint" of an executable when you run it.
  - londons_explore 6y ago
    But the fingerprint of photoshop is the same for everyone. If apple knows what the fingerprint of photoshop is (which they could easily find out), now they have a giant list of who installed photoshop and when, and from which IP address, and which IP location. That data would be a wet dream for some IP lawyer looking for pirate copies of software...
    - daneel_w 6y ago
      I understand the privacy concern. We don't know if they store/log anything from the request, or even what it contains in itself besides the "fingerprint". I'm personally certain that Apple is not in cahoots with Big Software to put a squeeze on users in exchange for small money. It's not their business, and it's not something they are required by law to make their business.
HugoDaniel 6y ago
Im running my dev environment in a OpenBSD vm. This makes me wanna use it for more stuff besides dev.
abathur 6y ago
late edit (2): added 3 notes including performance impact observation I'm concerned about this behavior (both from privacy and performance perspectives), but I'm also not (quite) convinced this is working as described/implied here. Before I get started: If you poke at this, open Console.app first. You can see recent logged "assessment" checks logged in "Mac Analytics Data" with the search "process:syspolicyd". You can use the same search to watch log messages (including all of the TLS negotiation etc.) for the checks in the device log. The part that seems weird is that, if it is transmitting a hash (which seems possible/logical) the caching behavior doesn't appear to care or respect it? The article suggests the following test: echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh time /tmp/test.sh && time /tmp/test.sh I tried this test and got real runtimes of 0m0.289s and 0m0.006s. Then, I changed the file: echo $'#!/bin/sh\necho Hellok' > /tmp/test.sh && chmod a+x /tmp/test.sh When I re-ran the script, both runs are under 10ms. The content changed, but it didn't bother re-checking. I wrote the original script to a new file path: echo $'#!/bin/sh\necho Hello' > /tmp/test2.sh && chmod a+x /tmp/test2.sh This ran with runtimes similar to the original (0m0.232s and 0m0.006s). Same content, new path, new check. Here too, if it cares about the hash, it either isn't bothering to use it for caching decisions or the hash includes the path. Then I tried rming the file, writing it again, and running it. Once again, it checks on the first request. I think this suggests it may be caching the result by inode? The author said they saw new checks after saving changes in TextEdit--I don't know much about TextEdit, but I'd guess it is doing atomic write/rename here. Other random details I noticed: 1. it holds the connection open for a minute, presumably to minimize connection overhead for executions that'll generate many checks. My first checks were all in the 280-300ms range, but I tried one additional check within the minute and it only took 72ms. Making multiple requests in less than a minute may make it harder to notice 2. The device log has a "summary for task success" entry with pretty precise timing details on all parts of the request. 3. On my system, each of these attempts produces a "os_unix.c:43353: (2) open(/var/db/DetachedSignatures) - No such file or directory" error in the log from the libsqlite3 subsystem after the response comes back. 4. The "Mac Analytics Data" log entry for each request has a good summary that looks like: assessment denied for test.sh com.apple.message.domain: com.apple.security.assessment.outcome2 com.apple.message.signature2: bundle:UNBUNDLED com.apple.message.signature3: test.sh com.apple.message.signature5: UNKNOWN com.apple.message.signature4: 1 com.apple.message.signature: denied:no usable signature SenderMachUUID: ...snip... 5. When I add Terminal to the Developer Tools exemption on the privacy tab it does appear to kill the check. I'm not sure if there's genuine protection this check provides at some level, but I'll be considering adding either Terminal or at least some specific build tools to the exemptions I add on a new system. 6. After adding the Developer Tools exemption, if you have the app open, it'll ask if it can quit it for you. I took the hint and restarted Terminal. It'll do the same thing when you remove it from the list. But I didn't see the checks actually return until I rebooted. Also, my system froze during reboot. Hopefully a coincidence. :) 7. To put a better number on how this performance impact can compound for the kinds of builds I do all of the time, I ran `nix-build ci.nix` in the local directory for one of my projects before and after enabling the Developer Tools exemption for ~/.nix-profile/bin/nix. The run took 1m22s before, 45.5s after. 8. Looks like this is the same check as is run by `spctl --asses -v <path>` (at least, per the Console.app logs). That may make it easier to play with.
mokus 6y ago
I guess the list of things keeping me off catalina (and, by extension, new Mac hardware) just got one item longer. I recently bought a new System76 laptop as a stopgap, but it might end up becoming permanent. Kind of a sad end for 25+ years of Mac use.
- rimliu 6y ago
  I upgraded my 2015 MBP 13" to Catalina and happily continue to Mac stint since 2006.
  - 72deluxe 6y ago
    What does df -h in the terminal say? It'll show the total of each partition (the normal, and the new read-only system partition) on their own line, thereby giving a false total. e.g. 1x 100GB disk, 50GB normal, 50GB system partition will show as capacity 100GB for both partitions which would mean a 200GB disk. Small things like this just make me completely lose faith in Catalina. EDIT: Other "fun" things I noticed within half an hour: a. Text search in PDF no longer works b. I can't create anything under / c. I have to use synthetic.conf to map paths from / to my real partition, but the parser of synthetic.conf is very particular to tabs/spaces unlike any other /etc/ file format d. Xcode wants to ask for my password to debug every single time I reboot and debug a C++ app. This is incredibly incredibly incredibly incredibly annoying. Safari is faster in general use. But that's so far the only good point. I'll keep it on a SSD for App Store submissions and keep my machine on an older decent version thanks
    - Marsymars 6y ago
      > a. Text search in PDF no longer works Oh is this macOS? I'd just assumed all the PDFs I've tried to search for the past while have been poorly formatted with the text as images, but that makes more sense. > I'll keep it on a SSD for App Store submissions and keep my machine on an older decent version thanks FYI it's pretty easy to integrate binary upload to App Store Connect on the CLI of your CI system.
      - 6y ago
usmannk 6y ago
There is so much confusion here. The OP and most others are missing one of the biggest points: Look at the packet trace. There is _no data_, not even a hash, being sent. It's a TLS negotiation and then the connection ends. I have to suspect it's a bug...
- takeda 6y ago
  In prior article "slow by design", this was reported to Apple and the bug was closed that it works like that by design.
  - usmannk 6y ago
    I did see the previous article (another comment of mine should be easy to find on its HN post). Do you know how to find the issue that was referenced? There was an ID given but I have no clue what tracker that was on.
    - Gaelan 6y ago
      It's probably Radar, which is Apple's internal issue tracker, which isn't public (you can see issues you submitted, but nothing else). Sometimes people cross-post issues they submit to http://openradar.appspot.com http://openradar.appspot.com, so you might be able to find it there.
      - takeda 6y ago
        The issue is FB7674490 but it is not on the OpenRadar. Looks like OpenRadar is not Apple's services and issues appear there only if author (which has access to the issue in the Apple system) submits them there.
        saagarjha 6y ago
        Open Radar is community maintained and fairly poorly at that these days :(
      - 6y ago
nojito 6y ago
What's the exact data being sent? There is a lot of arguing going on here, but what is the data?
- azinman2 6y ago
  Seems to be a hash of the executable.
huslage 6y ago
This is a specious problem _at best_. We have a very secure operating system doing things that others don't even try to do (notary) and we are complaining because our shell scripts take n seconds to run? Really people? If you are running signed and notarized (stapled) binaries, the system never even reports them to Apple in the first place. This is the height of insanity to think that Apple or anyone else would want this data or use it for some nefarious purposes...anonymous hashes of junk data are essentially useless outside of this purpose. It's fine to claim not to trust anyone for anything, but most of us aren't willing or able to build our own hardware, write our own operating system, and write our own applications. We have asked our vendors for devices and code that are more trustworthy, and when they give them to us we COMPLAIN about it incessantly. This makes no sense to me.
- frou_dh 6y ago
  Scripts becoming noticeably slow to start every time they're edited is a notable regression for programmers. Simple as that.
- saagarjha 6y ago
  > We have a very secure operating system doing things that others don't even try to do Perhaps because such a system is extremely centralized? > we are complaining because our shell scripts take n seconds to run? Yes? If I buy a computer and it spends time doing stupid stuff, then I think I am fairly justified in being angry. > If you are running signed and notarized (stapled) binaries, the system never even reports them to Apple in the first place. Great, let's notarize and staple tickets to every little piece of software you write… > This is the height of insanity to think that Apple or anyone else would want this data or use it for some nefarious purposes...anonymous hashes of junk data are essentially useless outside of this purpose. Executable hashes tell you if someone is running a specific piece of code. > It's fine to claim not to trust anyone for anything, but most of us aren't willing or able to build our own hardware, write our own operating system, and write our own applications. That's why I buy them from other people and would desire them to be good. > We have asked our vendors for devices and code that are more trustworthy, and when they give them to us we COMPLAIN about it incessantly. How exactly does this make the device more trustworthy?
kimi 6y ago
I am not sure of what is the whole point of this notarization thing. It would be great (ahem, let's say so) if there was a big and closed list of executables, but every shell / ruby / perl / python script can do many funny things, and you cannot notarize them all. Often, as in bash, by design. So?
MintelIE 6y ago
Why don't companies come out and tell people what they're doing these days? Telemetry is getting to the point where people such as doctors and lawyers might be violating the law by using a modern computer. And people in the defense industry? Doesn't Apple employ thousands of forns? Who's audited their datasystems and ensured that this stuff stays private? Much easier and better to just stop using it all and move to a system like Linux or BSD. 99% of people do everything in a browser these days anyhow.
- FpUser 6y ago
  >"99% of people do everything in a browser these days anyhow." This exaggeration is clearly absurd.
  - MintelIE 6y ago
    Are you certain about this? I think I was being conservative. It's easy for us tech nerds in our little gadget bubbles to suppose that everybody is like us. But most people are simple browser users, and Office 365 and Google Docs have all but killed off office software on the desktop for many users.
    - jeremyjh 6y ago
      > Office 365 and Google Docs have all but killed off office software on the desktop for many users. That hasn't been my experience at all. While those tools are definitely used - especially for collaboration - most people on my company's Office 365 subscription are downloading and using the full products for their daily work. This is true in both very large companies and the (non-tech) startup I work at now.
      - dathinab 6y ago
        Honestly my experience with collaboration with Office 365 last year was pretty beer bad. At least for sight technical cases people they are many better solutions.
    - 6y ago
msie 6y ago
I was watching a Linus YouTube video on the upgradeability of Alienware Laptops. So envious! Now you can't upgrade anything on the newest MacBook Pros. https://www.youtube.com/watch?v=J-RXqNafscs https://www.youtube.com/watch?v=J-RXqNafscs And if something breaks on your MacBook Pro, most likely you will have to replace the entire motherboard or display. PS: I own lots of Macs but sad to see the direction Apple is heading in.
LeoPanthera 6y ago
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.
- alexeldeib 6y ago
  > You can verify that there's an online check by taking packet traces
- boardwaalk 6y ago
  It is real; browse the previous thread on this topic: https://news.ycombinator.com/item?id=23273247 https://news.ycombinator.com/item?id=23273247 It pushed me to buy Little Snitch to block it, so I guess somebody won out.
- abathur 6y ago
  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).
mthoms 6y ago
Does anyone know if adding the Apple domain in question to piHole (or your hosts file pointing to 0.0.0.0) will suppress these checks?
- MintelIE 6y ago
  It appears as if OS X will revert to using an IP address if a domain lookup fails according to the thread we had on this issue yesterday.
- TheRealPomax 6y ago
  If you're on MacOS, you want Little Snitch installed at all times, even if you have a pihole: a process that is denied network access is far stronger than juping DNS requests.
crazygringo 6y ago
I'm still trying to understand what the problem here is. Nobody seems to have an issue with checking this for apps -- it's a good security feature to protect from malware, right? And which everyone knows about? And it only happens the first time you run something, so it's not a performance issue in everday usage. And the article even states that there seems to be a valid reason for checking shell scripts, because they can be used to compile malware. The original complaint was about slowness, but how often do you run something for the first time? The only scenario in which I can imagine this would become a practical peformance problem is if, somehow, you have an app that spawns new shell scripts all day long to execute, every few seconds, and a really flaky internet connection. Or new shell scripts hundreds of times a second, even with a good internet connection. Is that something anyone ever needs to do? Programs can run shell commands directly, without a file, so it seems unlikely. Also, another comment here suggests that even if a shell script is modified, it isn't re-verified, so there would seem to be a trivial workaround anyways. Or is the issue just that this is undocumented behavior? Or what am I missing here?
TheRealPomax 6y ago
Little Snitch is a god-send for users of MacOS, be they voluntary users or forced into using it because their employer won't allow them to use anything else.
- mindfulhack 6y ago
  I've found Objective-See's LuLu to be even better in catching every application and obscure binary daemon that ever makes a connection to the network and allowing me to set a temp or permanent block/allow rule for it - and it's FOSS. Try it out: https://objective-see.com/products/lulu.html https://objective-see.com/products/lulu.html
  - brigandish 6y ago
    I didn't know about LuLu, thanks. I'm trying it out now and it's not been too bothersome (so far), which is always nice. I used Little Snitch for a few years but not only was it always in my face with the pop-up dialog (poor UI choice) but because it uses plist files for its database it became incredibly slow. Had to give up on it. I tried Murus/Vallum[1] too for a while but it was still a bit too complicated and demanding. There's still a space for a firewall with a decent UI available. Won't be a Mac for me after this machine though. [1] https://www.vallumfirewall.com/ https://www.vallumfirewall.com/
  - TheRealPomax 6y ago
    I also hadn't heard of LuLu, great suggestion!
sjellis 6y ago
It has to be said: if Apple published their source code, we wouldn't have to rely on reverse-engineering and speculation.
jbverschoor 6y ago
Great! They can block malware as soon as they find out. Love it!
david-cako 6y ago
macOS has quite a few built-in antivirus features: https://support.apple.com/guide/security/app-security-overview-sec35dd877d0/1/web/1 https://support.apple.com/guide/security/app-security-overvi... IMO, you have to pick a security vendor to trust (only as far as you can throw them). Apple is incentivized to provide better end-user experiences as a matter of having end to end authority for their products. They’ve built a robust (albeit prescriptive) security/sandboxing ecosystem to avoid just pointing at software vendors if a customer is unhappy. I like these features, but the fact that they’re not always optional is frustrating. Note also that soon macOS will be running on Apple ARM SoCs; similar trade off. Buy any other computer, and you now have Microsoft or Google, a CPU vendor, a consumer hardware vendor, and possibly also an antivirus company installing background services.

361 points by robenkleene 6y ago

The article mentioned at the beginning is already discussed here: https://news.ycombinator.com/item?id=23273247 https://news.ycombinator.com/item?id=23273247

deleted 6y ago
[deleted]
- FriendlyNormie 6y ago
  Why?

verytrivial 6y ago

#include "This is fine meme.h"

rvnx 6y ago

It's great tool for mass-surveillance. Since Apple has a database of all the apps the user has run on their device (but no worries, Google has the same). For your security ;)

tenebrisalietum 6y ago
So why mass-surveil Apple computer users this way? My understanding is the only thing exclusive to Apple systems is developing Apple apps. But anything related on a platform like iOS is already going to be public knowledge. Also the latest Mac hardware seems to go through great pains to make sure the primary storage device is both encrypted, unrecoverable if keys are unknown (T2 security chip), and non-removable (SSD soldered to board). So why would they make this back door for surveillance?
- dannyw 6y ago
  None of those measures you described counteract mass surveillance.
jmull 6y ago
> great tool for mass-surveillance It’s not really that great for mass-surveillance. It “phone’s home” only on first run. And it doesn’t look like it sends data about your identity, device or location. They can have your IP address but another mechanism would be needed to relate that to you. (I doubt they are logging the IP address anyway. The only purpose would be to surveil you, but if they wanted to do that they would surely use a more capable mechanism . That makes keeping the IP addresses a burden and risk.)
- yyyk 6y ago
  >It “phone’s home” only on first run. Do we know that? The cache may well have an expiration date. Does the cache stay after an OS upgrade? I suspect further research will discover it's not just 'first time'. >They can have your IP address but another mechanism would be needed to relate that to you.... if they wanted to do that they would surely use a more capable mechanism. The app profile would already tell a great deal. Once enough of these 'non-capable' surveillance mechanisms add up, you end up with a very capable surveillance mechanism.

londons_explore 6y ago

This must be a blacklist, since it doesn't block my own random scripts which it has never seen before. If it's a global blacklist on apple servers, it should instead be downloaded to the client, and be a local blacklist. Too big? Use a bloom filter. Now you only end up keeping less than one byte per blacklisted item. Update the bloom filter with an autoupdater. Any positive hit you can check against the server just incase it's a false positive.

daneel_w 6y ago
Bloom filters are probability-based and come with inaccuracy problems. If you're going to double-check with Apple anyway what does a bloom filter solve compared to the current response caching after querying Apple? How will you protect the locally cached blacklist from being tampered with?
- w-j-w 6y ago
  Bloomington filters have probabilistic false positives, making it perfect for blacklisting. A negative means that the program can be run immediately, because it is guaranteed to not be on the list. A positive needs to be double checked, though.
JackC 6y ago
The k-anonymity scheme used by the haveibeenpwned api seems like a good fit here.
caf 6y ago
Doesn't a blacklist also work only until the malware authors figure out how to randomize 8 junk bytes every time they serve an executable?
- therein 6y ago
  Which they already do.
- dimator 6y ago

londons_explore 6y ago

So you're telling me that every time I install a program in OSX, it pings apple to let them know what program I'm installing, my IP address, my location, and my OS version? Sounds very Orwellian for a privacy focussed company...

trashburger 6y ago
Of course, if they say it's for your privacy, it's fine, and everything is all right. We have won the victory over ourselves. We love Apple.
- daneel_w 6y ago
  No, they say it's for your security, and we can surmise that's the actual intention in Apple's case, but I definitely understand the privacy concerns that come with this method.
daneel_w 6y ago
No, that's not what he's telling you. You're getting ahead of yourself with your question. He's telling us that macOS will consult with Apple regarding the "fingerprint" of an executable when you run it.
- londons_explore 6y ago
  But the fingerprint of photoshop is the same for everyone. If apple knows what the fingerprint of photoshop is (which they could easily find out), now they have a giant list of who installed photoshop and when, and from which IP address, and which IP location. That data would be a wet dream for some IP lawyer looking for pirate copies of software...
  - daneel_w 6y ago
    I understand the privacy concern. We don't know if they store/log anything from the request, or even what it contains in itself besides the "fingerprint". I'm personally certain that Apple is not in cahoots with Big Software to put a squeeze on users in exchange for small money. It's not their business, and it's not something they are required by law to make their business.

HugoDaniel 6y ago

Im running my dev environment in a OpenBSD vm. This makes me wanna use it for more stuff besides dev.

abathur 6y ago

late edit (2): added 3 notes including performance impact observation I'm concerned about this behavior (both from privacy and performance perspectives), but I'm also not (quite) convinced this is working as described/implied here. Before I get started: If you poke at this, open Console.app first. You can see recent logged "assessment" checks logged in "Mac Analytics Data" with the search "process:syspolicyd". You can use the same search to watch log messages (including all of the TLS negotiation etc.) for the checks in the device log. The part that seems weird is that, if it is transmitting a hash (which seems possible/logical) the caching behavior doesn't appear to care or respect it? The article suggests the following test: echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh time /tmp/test.sh && time /tmp/test.sh I tried this test and got real runtimes of 0m0.289s and 0m0.006s. Then, I changed the file: echo $'#!/bin/sh\necho Hellok' > /tmp/test.sh && chmod a+x /tmp/test.sh When I re-ran the script, both runs are under 10ms. The content changed, but it didn't bother re-checking. I wrote the original script to a new file path: echo $'#!/bin/sh\necho Hello' > /tmp/test2.sh && chmod a+x /tmp/test2.sh This ran with runtimes similar to the original (0m0.232s and 0m0.006s). Same content, new path, new check. Here too, if it cares about the hash, it either isn't bothering to use it for caching decisions or the hash includes the path. Then I tried rming the file, writing it again, and running it. Once again, it checks on the first request. I think this suggests it may be caching the result by inode? The author said they saw new checks after saving changes in TextEdit--I don't know much about TextEdit, but I'd guess it is doing atomic write/rename here. Other random details I noticed: 1. it holds the connection open for a minute, presumably to minimize connection overhead for executions that'll generate many checks. My first checks were all in the 280-300ms range, but I tried one additional check within the minute and it only took 72ms. Making multiple requests in less than a minute may make it harder to notice 2. The device log has a "summary for task success" entry with pretty precise timing details on all parts of the request. 3. On my system, each of these attempts produces a "os_unix.c:43353: (2) open(/var/db/DetachedSignatures) - No such file or directory" error in the log from the libsqlite3 subsystem after the response comes back. 4. The "Mac Analytics Data" log entry for each request has a good summary that looks like: assessment denied for test.sh com.apple.message.domain: com.apple.security.assessment.outcome2 com.apple.message.signature2: bundle:UNBUNDLED com.apple.message.signature3: test.sh com.apple.message.signature5: UNKNOWN com.apple.message.signature4: 1 com.apple.message.signature: denied:no usable signature SenderMachUUID: ...snip... 5. When I add Terminal to the Developer Tools exemption on the privacy tab it does appear to kill the check. I'm not sure if there's genuine protection this check provides at some level, but I'll be considering adding either Terminal or at least some specific build tools to the exemptions I add on a new system. 6. After adding the Developer Tools exemption, if you have the app open, it'll ask if it can quit it for you. I took the hint and restarted Terminal. It'll do the same thing when you remove it from the list. But I didn't see the checks actually return until I rebooted. Also, my system froze during reboot. Hopefully a coincidence. :) 7. To put a better number on how this performance impact can compound for the kinds of builds I do all of the time, I ran `nix-build ci.nix` in the local directory for one of my projects before and after enabling the Developer Tools exemption for ~/.nix-profile/bin/nix. The run took 1m22s before, 45.5s after. 8. Looks like this is the same check as is run by `spctl --asses -v <path>` (at least, per the Console.app logs). That may make it easier to play with.

mokus 6y ago

I guess the list of things keeping me off catalina (and, by extension, new Mac hardware) just got one item longer. I recently bought a new System76 laptop as a stopgap, but it might end up becoming permanent. Kind of a sad end for 25+ years of Mac use.

rimliu 6y ago
I upgraded my 2015 MBP 13" to Catalina and happily continue to Mac stint since 2006.
- 72deluxe 6y ago
  What does df -h in the terminal say? It'll show the total of each partition (the normal, and the new read-only system partition) on their own line, thereby giving a false total. e.g. 1x 100GB disk, 50GB normal, 50GB system partition will show as capacity 100GB for both partitions which would mean a 200GB disk. Small things like this just make me completely lose faith in Catalina. EDIT: Other "fun" things I noticed within half an hour: a. Text search in PDF no longer works b. I can't create anything under / c. I have to use synthetic.conf to map paths from / to my real partition, but the parser of synthetic.conf is very particular to tabs/spaces unlike any other /etc/ file format d. Xcode wants to ask for my password to debug every single time I reboot and debug a C++ app. This is incredibly incredibly incredibly incredibly annoying. Safari is faster in general use. But that's so far the only good point. I'll keep it on a SSD for App Store submissions and keep my machine on an older decent version thanks
  - Marsymars 6y ago
    > a. Text search in PDF no longer works Oh is this macOS? I'd just assumed all the PDFs I've tried to search for the past while have been poorly formatted with the text as images, but that makes more sense. > I'll keep it on a SSD for App Store submissions and keep my machine on an older decent version thanks FYI it's pretty easy to integrate binary upload to App Store Connect on the CLI of your CI system.
    - 6y ago

usmannk 6y ago

There is so much confusion here. The OP and most others are missing one of the biggest points: Look at the packet trace. There is _no data_, not even a hash, being sent. It's a TLS negotiation and then the connection ends. I have to suspect it's a bug...

takeda 6y ago
In prior article "slow by design", this was reported to Apple and the bug was closed that it works like that by design.
- usmannk 6y ago
  I did see the previous article (another comment of mine should be easy to find on its HN post). Do you know how to find the issue that was referenced? There was an ID given but I have no clue what tracker that was on.
  - Gaelan 6y ago
    It's probably Radar, which is Apple's internal issue tracker, which isn't public (you can see issues you submitted, but nothing else). Sometimes people cross-post issues they submit to http://openradar.appspot.com http://openradar.appspot.com, so you might be able to find it there.
    - takeda 6y ago
      The issue is FB7674490 but it is not on the OpenRadar. Looks like OpenRadar is not Apple's services and issues appear there only if author (which has access to the issue in the Apple system) submits them there.
      - saagarjha 6y ago
        Open Radar is community maintained and fairly poorly at that these days :(
    - 6y ago

nojito 6y ago

What's the exact data being sent? There is a lot of arguing going on here, but what is the data?

azinman2 6y ago
Seems to be a hash of the executable.

huslage 6y ago

This is a specious problem _at best_. We have a very secure operating system doing things that others don't even try to do (notary) and we are complaining because our shell scripts take n seconds to run? Really people? If you are running signed and notarized (stapled) binaries, the system never even reports them to Apple in the first place. This is the height of insanity to think that Apple or anyone else would want this data or use it for some nefarious purposes...anonymous hashes of junk data are essentially useless outside of this purpose. It's fine to claim not to trust anyone for anything, but most of us aren't willing or able to build our own hardware, write our own operating system, and write our own applications. We have asked our vendors for devices and code that are more trustworthy, and when they give them to us we COMPLAIN about it incessantly. This makes no sense to me.

frou_dh 6y ago
Scripts becoming noticeably slow to start every time they're edited is a notable regression for programmers. Simple as that.
saagarjha 6y ago
> We have a very secure operating system doing things that others don't even try to do Perhaps because such a system is extremely centralized? > we are complaining because our shell scripts take n seconds to run? Yes? If I buy a computer and it spends time doing stupid stuff, then I think I am fairly justified in being angry. > If you are running signed and notarized (stapled) binaries, the system never even reports them to Apple in the first place. Great, let's notarize and staple tickets to every little piece of software you write… > This is the height of insanity to think that Apple or anyone else would want this data or use it for some nefarious purposes...anonymous hashes of junk data are essentially useless outside of this purpose. Executable hashes tell you if someone is running a specific piece of code. > It's fine to claim not to trust anyone for anything, but most of us aren't willing or able to build our own hardware, write our own operating system, and write our own applications. That's why I buy them from other people and would desire them to be good. > We have asked our vendors for devices and code that are more trustworthy, and when they give them to us we COMPLAIN about it incessantly. How exactly does this make the device more trustworthy?

kimi 6y ago

I am not sure of what is the whole point of this notarization thing. It would be great (ahem, let's say so) if there was a big and closed list of executables, but every shell / ruby / perl / python script can do many funny things, and you cannot notarize them all. Often, as in bash, by design. So?

MintelIE 6y ago

Why don't companies come out and tell people what they're doing these days? Telemetry is getting to the point where people such as doctors and lawyers might be violating the law by using a modern computer. And people in the defense industry? Doesn't Apple employ thousands of forns? Who's audited their datasystems and ensured that this stuff stays private? Much easier and better to just stop using it all and move to a system like Linux or BSD. 99% of people do everything in a browser these days anyhow.

FpUser 6y ago
>"99% of people do everything in a browser these days anyhow." This exaggeration is clearly absurd.
- MintelIE 6y ago
  Are you certain about this? I think I was being conservative. It's easy for us tech nerds in our little gadget bubbles to suppose that everybody is like us. But most people are simple browser users, and Office 365 and Google Docs have all but killed off office software on the desktop for many users.
  - jeremyjh 6y ago
    > Office 365 and Google Docs have all but killed off office software on the desktop for many users. That hasn't been my experience at all. While those tools are definitely used - especially for collaboration - most people on my company's Office 365 subscription are downloading and using the full products for their daily work. This is true in both very large companies and the (non-tech) startup I work at now.
    - dathinab 6y ago
      Honestly my experience with collaboration with Office 365 last year was pretty beer bad. At least for sight technical cases people they are many better solutions.
  - 6y ago

msie 6y ago

I was watching a Linus YouTube video on the upgradeability of Alienware Laptops. So envious! Now you can't upgrade anything on the newest MacBook Pros. https://www.youtube.com/watch?v=J-RXqNafscs https://www.youtube.com/watch?v=J-RXqNafscs And if something breaks on your MacBook Pro, most likely you will have to replace the entire motherboard or display. PS: I own lots of Macs but sad to see the direction Apple is heading in.

LeoPanthera 6y ago

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.

alexeldeib 6y ago
> You can verify that there's an online check by taking packet traces
boardwaalk 6y ago
It is real; browse the previous thread on this topic: https://news.ycombinator.com/item?id=23273247 https://news.ycombinator.com/item?id=23273247 It pushed me to buy Little Snitch to block it, so I guess somebody won out.
abathur 6y ago
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).

mthoms 6y ago

Does anyone know if adding the Apple domain in question to piHole (or your hosts file pointing to 0.0.0.0) will suppress these checks?

MintelIE 6y ago
It appears as if OS X will revert to using an IP address if a domain lookup fails according to the thread we had on this issue yesterday.
TheRealPomax 6y ago
If you're on MacOS, you want Little Snitch installed at all times, even if you have a pihole: a process that is denied network access is far stronger than juping DNS requests.

crazygringo 6y ago

I'm still trying to understand what the problem here is. Nobody seems to have an issue with checking this for apps -- it's a good security feature to protect from malware, right? And which everyone knows about? And it only happens the first time you run something, so it's not a performance issue in everday usage. And the article even states that there seems to be a valid reason for checking shell scripts, because they can be used to compile malware. The original complaint was about slowness, but how often do you run something for the first time? The only scenario in which I can imagine this would become a practical peformance problem is if, somehow, you have an app that spawns new shell scripts all day long to execute, every few seconds, and a really flaky internet connection. Or new shell scripts hundreds of times a second, even with a good internet connection. Is that something anyone ever needs to do? Programs can run shell commands directly, without a file, so it seems unlikely. Also, another comment here suggests that even if a shell script is modified, it isn't re-verified, so there would seem to be a trivial workaround anyways. Or is the issue just that this is undocumented behavior? Or what am I missing here?

TheRealPomax 6y ago

Little Snitch is a god-send for users of MacOS, be they voluntary users or forced into using it because their employer won't allow them to use anything else.

mindfulhack 6y ago
I've found Objective-See's LuLu to be even better in catching every application and obscure binary daemon that ever makes a connection to the network and allowing me to set a temp or permanent block/allow rule for it - and it's FOSS. Try it out: https://objective-see.com/products/lulu.html https://objective-see.com/products/lulu.html
- brigandish 6y ago
  I didn't know about LuLu, thanks. I'm trying it out now and it's not been too bothersome (so far), which is always nice. I used Little Snitch for a few years but not only was it always in my face with the pop-up dialog (poor UI choice) but because it uses plist files for its database it became incredibly slow. Had to give up on it. I tried Murus/Vallum[1] too for a while but it was still a bit too complicated and demanding. There's still a space for a firewall with a decent UI available. Won't be a Mac for me after this machine though. [1] https://www.vallumfirewall.com/ https://www.vallumfirewall.com/
- TheRealPomax 6y ago
  I also hadn't heard of LuLu, great suggestion!

sjellis 6y ago

It has to be said: if Apple published their source code, we wouldn't have to rely on reverse-engineering and speculation.

jbverschoor 6y ago

Great! They can block malware as soon as they find out. Love it!

david-cako 6y ago

macOS has quite a few built-in antivirus features: https://support.apple.com/guide/security/app-security-overview-sec35dd877d0/1/web/1 https://support.apple.com/guide/security/app-security-overvi... IMO, you have to pick a security vendor to trust (only as far as you can throw them). Apple is incentivized to provide better end-user experiences as a matter of having end to end authority for their products. They’ve built a robust (albeit prescriptive) security/sandboxing ecosystem to avoid just pointing at software vendors if a customer is unhappy. I like these features, but the fact that they’re not always optional is frustrating. Note also that soon macOS will be running on Apple ARM SoCs; similar trade off. Buy any other computer, and you now have Microsoft or Google, a CPU vendor, a consumer hardware vendor, and possibly also an antivirus company installing background services.