Get the top HN stories in your inbox every day.
usmannk
varenc
Here's some shell script to use a random file name and have friendlier output.
RAND_FILE="/tmp/test-$RANDOM.sh";
time_helper() { /usr/bin/time $RAND_FILE 2>&1 | tail -1 | awk '{print $1}'; } # this just returns the real run time
echo $'#!/bin/sh\necho Hello' $RANDOM > $RAND_FILE && chmod a+x $RAND_FILE;
echo "Testing $RAND_FILE";
echo "execution time #1: $(time_helper) seconds";
echo "execution time #2: $(time_helper) seconds";
example output:
Testing /tmp/test-24411.sh
execution time #1: 2.32 seconds
execution time #2: 0.00 seconds
varenc
I tried just blocking "api.apple-cloudkit.com" with /etc/hosts. This reduces the delay but doesn't eliminate it. A connection attempt is still made every time. (I don't recommend making this change permanent. Just give your terminal app the "Developers Tools" permission instead)
After blocking that domain I can see that tccd and syspolicyd are logging some error messages to the console related to the failed connection. I don't recommend blocking because my guess is that'll put syspolicyd/tccd in some unexpected state and they'll repeatedly keep trying to make requests.
Try this for watching security related console log messages:
sudo log stream --debug --info --predicate "processImagePath contains 'tccd' OR processImagePath contains 'syspolicyd' OR processImagePath Contains[c] 'taskgated' OR processImagePath contains 'trustd' OR eventMessage Contains[c] 'malware' OR senderImagePath Contains[c] 'security' "
syspolicyd: cloudkit record fetch: https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, 2/2/23de35......
saagarjha
Enabling private logging is fairly annoying these days, unfortunately. (Interestingly, if macOS thinks you're AppleInternal, it will make it just as annoying to disable private logging…)
krferriter
Huh this is crazy. 2 seconds is way slow and this shouldn't involve any network activity. Seems like a real problem.
Erlich_Bachman
He/she added an artificial network latency/delay into the config, just like they describe. That is the reason for the delay. It is made artificially long on purpose.
rurban
It's called lockdown for a reason. Apple was just the very first to implement centralized binary blacklisting, revocation. They call it notarization.
Problem is, that they did it unannounced. There must be really some weird stuff going on in those managers heads. How can they possibly think to go away with that?
dagmx
There were announcements about notarization around WWDC last year. They didn't seem to get a lot of media traction however, but there were specific pages detailing what's required from a developer and some basic details on how it would work
From April 10, 2019: https://developer.apple.com/news/?id=04102019a
https://developer.apple.com/documentation/xcode/notarizing_m...
rurban
For each and every shell or perl script that I create and use privately? No, certainly not.
john_alan
Command line apps aren't affected by Notarization.
If you're compiling something yourself, the compiler won't put a quarantine bit on it and it will execute fine. Same with homebrew/friends.
Scripts don't need to be signed. There is something else going on here.
john_alan
Seems that in fact even though scripts aren't signed, IF YOU DONT have devTooling enabled for a given terminal, scripts are hashed and checked against bad known digests.
not a big deal, assuming no data is kept.
Also I wonder what it looks like if a script is deemed bad...
kevinh456
There was nothing "unannounced" about it. Notarization was introduced at WWDC 2018 and announced as required at WWDC 2019. Every macOS developer should have been aware of this requirement. It was a special project for my apps.
ghayes
I believe the concern here is that this is affecting not just macOS developers, but all developers who use macOS. That's an important distinction.
make3
developer who uses MacOS != MacOS developer. I couldn't care less about what is announced at WWDC
la_oveja
First? Windows SmartScreen has checked for malicious binaries since Windows 8.
yariik
> Problem is, that they did it unannounced.
No, the entire thing is the problem. Windows 10 can still open applications that were compiled in 1994, and it doesn't make it less secure.
m463
Once you start something, it's hard to stop it.
Every software place I've worked gives a special urgency to security stuff.
And even if features don't come out regularly, security updates do. This is more of that.
jules
Isn't this what bloom filters are for?
ComodoHacker
>Apple was just the very first to implement centralized binary blacklisting
No, AV vendors did it for decades. In a more efficient way though.
andy_ppp
Not sure it’s more efficient given how sluggish most AV software used to make my machine...
kccqzy
OCSP is Online Certificate Status Protocol, generally used for checking the revocation status of certificates. You used to be able to turn it off in keychain access, but that ability went away in recent macOS releases.
VonGuard
Ah, Apple. When you can no longer innovate, just start removing features and call it simplicity...
throwaway851
Another way to look at it is that Apple is making it harder to run the system in an insecure fashion. You may not agree with that decision, but I certainly appreciate how Apple is looking out for the safety and security of the user.
Tangent: as much as some developers hate that the only way to distribute apps for the iPhone is through the App Store, as a user I consider that walled garden of apps to be a real security benefit. When John Gruber says “If you must use Zoom or simply want to use it, I highly recommend using it on your iPad and iPhone only. The iOS version is sandboxed and reviewed by the App Store.” There’s a reason why he can say things like that and it’s because Apple draws a hard line in the sand that not everyone will be happy with.
monadic2
Honestly I'm trying to think of a reason you would WANT to disable OCSP, I'm having enough problems thinking of more than 2 developers I know who can actually articulate how it works enough to evaluate this. Not that it's complicated—it's just mostly invisible.
Even when OCSP is a problem, generally you're more worried about issuing a new certificate than an immediate workaround. What are you going to do, ask all your customers to go into keychain access to work around your problem?
This behavior of slowing down appears to be because apple is making HTTPS connections apparently synchronously (probably unnecessarily) and you'd only be potentially harming yourself by disable OCSP.
Though, I am often frustrated FLOSS desktops and Windows don't allow the behavior I want—maybe this is just cultural.
D-Coder
Feature-removal has been the most aggravating part of my Mac life for the past several years. Admittedly I tend to use unusual features, but it's just another PITA when they go away.
ngcc_hk
Not sure they have removed anything, but add something.
torstenvl
What happens if you edit /private/etc/hosts to point ocsp.apple.com to 0.0.0.0 and flush the DNS cache?
Myrmornis
This seems like an interesting line of inquiry.
AIUI doing what you said would permit the network request to proceed, and it would fail because nothing is listening on port 80 [1] We already know that the phone-home bails out when there's no network connection, so perhaps that code also bails out on connection failure?
Alternatively, is there some way to make DNS lookup itself fail for ocsp.apple.com?
Last resort, if we know how to fake the response, running a dummy server listening on localhost would be faster than allowing the request to go over the internet.
[1] Empirically, `curl http://0.0.0.0` yields a connection failure. I think I know that 0.0.0.0 is used in a listening context to mean "listen on all interfaces" but tbh I don't really know what it means in a sending context. Maybe someone can educate me?
IncRnd
Sending to 0.0.0.0 will fail immediately. This differs from sending to 127.0.0.0/8 that may connect to a server on the local machine.
usmannk
0.0.0.0 is non-routable and generally only valid as a src not a dest
saagarjha
I think it is fairly likely that your system would not work at all.
saagarjha
I believe it's just Base64 encoded DER information, based on the code that seems to be similar: https://github.com/apple-open-source-mirror/Security/blob/70...
caf
Yes, that base64 decodes to:
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 3381D1EFDB68B085214D2EEFAF8C4A69643C2A6C
Issuer Key Hash: 5717EDA2CFDC7C98A110E0FCBE872D2CF2E31754
Serial Number: 7D86ED91E10A66C2usmannk
I can't edit anymore but it seems like the OCSP link could potentially be a red herring just checking the cert for the next request to https://api.apple-cloudkit.com/. It's worth looking further!
Darkstryder
I'm surprised nobody mentioned that Windows Defender does something very similar (checking for never-seen-before binaries at runtime, uploading them to Microsoft servers, then running them there) : https://news.ycombinator.com/item?id=21180019
pinopinopino
God, this shit makes me laugh. Why are they doing this.
But from Edit2: Your hash is some sort of base64
let str = Then we see weird random gaps in the alphabet used, not so weird, because not every character will be used in every string:
Prelude Data.List> map head $ group $ sort $ str
"+0246789=ABCDEFGIKLMOPQRSTUVXYZ_abefghiklmpstuwxyz"
Prelude Data.List> let xs = "+0123456789=ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz"
Prelude Data.List> length xs
65
saagarjha
It decodes cleanly as base64.
davidvartan
> a degraded user experience, as the first time a user runs a new executable, Apple delays execution while waiting for a reply from their server.
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 [1], a tool to make notarization way less painful, including uploading to Apple/polling for completion/stapling/troubleshooting various code signing issues.)
xenadu02
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.
indemnity
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.
kunday
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
LeoPanthera
Putting Terminal (and your favorite text editor) in this category and in "Full Disk Access" will change your life.
MrBuddyCasino
How does "Full Disk Access" help?
sneak
Yes, falling victim to ransomware is definitely lifechanging if you don’t have good backups.
grishka
So since these permissions apply to process trees, what happens if you put launchd in there?
aasasd
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.
acecilia
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-...
wila
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.
xenadu02
That is not correct starting with Catalina.
make3
How do I get a "Developer Tool" pane in System Prefs? Do I have to install X-Code? I would really rather not
scottlamb
> 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.
davidvartan
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.
nemosaltat
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.
JadeNB
> 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!
reuben_scratton
Quinn The Eskimo at Apple's forums is a 10x support engineer, his posts have helped me fix dozens of problems.
xenadu02
This is the way things worked prior to Catalina but is no longer the case.
oefrha
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...
oefrha
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
davidvartan
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.
abathur
> 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.
davidvartan
Notarization/stapling/etc. is for distribution only, not generally part of your dev workflow.
oefrha
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?
rgrs
How does mac identify a dev workflow and normal workflow?
ihiulll
I'm confused. does macbook send executable to apple servers or just the hash?
saagarjha
Just the hash.
dahfizz
The way to avoid this behavior is to not buy a machine from a company that actively hates it's users.
jaimehrubiks
In our company many of us have similar issues. I have always loved OSX but this time it is driving me crazy. I though the issue was some sort of company antivirus/firewall, or it could even be a combination of that and this issue (maybe my vpn + path to company firewall is what magnifies the issue in this post). The thing is that some commands take 1 second, some others take 2 minutes or even more. Actually, some commands slow down the computer until they are finished (more likely, until they just decide to start).
For example, I can run "terraform apply" and it could take up to 5 minutes to start, leaving my computer almost unusable until it runs. The weird thing is that this only happens sometimes. In some cases, I restart the laptop and it starts working a little bit faster, but the issue comes back after some time.
It's already been a few months since I try to run every command from a VM in a remote location, since I am tired of waiting for my commands to start.
I have a macbook air from 2013 which never had this issue.
Any easy fix that I could test? Disconnecting from the internet is not an option. Disabling SIP could be tried, but I think I already did and didn't seem to fix it, plus it is not a good idea for a company laptop.
Don't we have some sort of hosts file or firewall that we can use to block or fake the connectivity to apple servers?
derefr
IIRC the big thing that changed with 10.15 for CLI applications is that BSD-userland processes (i.e. ones that don't go through all the macOS Frameworks, but just call libc syscall wrappers like fopen(2)) now also deal with sandboxing, since the BSD syscall ABI is now reimplemented in terms of macOS security capabilities.
Certain BSD-syscall-ABI operations like fopen(2) and readdir(2) are now not-so-fast by default, because the OS has to do a synchronous check of the individual process binary's capabilities before letting the syscall through. But POSIX utilities were written to assume that these operations were fast-ish, and therefore they do tons of them, rather than doing any sort of batching.
That means that any CLI process that "walks" the filesystem is going to generate huge amounts of security-subsystem request traffic; which seemingly bottlenecks the security subsystem (OS-wide!); and so slows down the caller process and any other concurrent processes/threads that need capabilities-grants of their own.
To find a fix, it's important to understand the problem in fine detail. So: the CLI process has a set of process-local capabilities (kernel tokens/handles); and whenever it tries to do something, it first tries to use these. If it turns out none of those existing capabilities let it perform the operation, then it has to request the kernel look at it, build a firewall-like "capabilities-rules program" from the collected information, and run it, to determine whether it should grant the process that capability. (This means that anything that already has capabilities granted from its code-signed capabilities manifest doesn't need to sit around waiting for this capabilities-ruleset program to be built and run. Unless the app's capabilities manifest didn't grant the specific capability it's trying to use.)
Unlike macOS app-bundles, regular (i.e. freshly-compiled) BSD-userland executable binaries don't have a capabilities manifest of their own, so they don't start with any process-local capabilities. (You can embed one into them, but the process has to be "capabilities-aware" to actually make use of it, so e.g. GNU coreutils from Homebrew isn't gonna be helped by this. Oh, and it won't kick in if the program isn't also code-signed, IIRC.)
But all processes inherit their capabilities from their runtime ancestors, so there's a simple fix, for the case of running CLI software interactively: grant your terminal emulator the capabilities you need through Preferences. In this case, the "Full Disk Access" capability. Then, since all your all CLI processes have your terminal emulator as a runtime ancestor-process, all your CLI processes will inherit that capability, and thus not need to spend time requesting it from the security subsystem.
Note that this doesn't apply to BSD-userland executable binaries which run as LaunchDaemons, since those aren't being spawned by your terminal emulator. Those either need to learn to use capabilities for real; or, at least, they need to get exec(2)ed by a shim binary that knows how.
-----
tl;dr: I had this problem (slowness in numerous CLI apps, most obvious as `brew upgrade` suddenly taking forever) after upgrading to 10.15 as well. Granting "Full Disk Access" to iTerm fixed it for me.
saagarjha
> IIRC the big thing that changed with 10.15 for CLI applications is that BSD-userland processes (i.e. ones that don't go through all the macOS Frameworks, but just call libc syscall wrappers like fopen(2)) now also deal with sandboxing, since the BSD syscall ABI is now reimplemented in terms of macOS security capabilities.
Is this actually new in macOS 10.15? I seem to recall this being a thing ever since sandboxing was a thing, even all the way back to when it was called Seatbelt.
> That means that any CLI process that "walks" the filesystem is going to generate huge amounts of sandboxd traffic, which bottlenecks sandboxd and so slows down the caller process.
Is this not implemented in the kernel as an extension? I thought the checks went through MAC framework hooks. Doesn't sandboxd just log access violations when told to do so by the Sandbox kernel extension?
> Unlike macOS app-bundles, regular BSD-userland executable binaries don't have a capabilities manifest of their own, so they don't start with any process-local capabilities (with some interesting exceptions, that I think involve the binary being embedded in the directory-structure of a system framework, where the binary inherits its capabilities from the enclosing framework.)
I am fairly sure you can just embed a profile in a section of your app's binary and call the sandboxing Mach call with that…
derefr
> I seem to recall this being a thing ever since sandboxing was a thing, even all the way back to when it was called Seatbelt.
Maybe you're right; I'm not sure when they actually put the Seatbelt/TrustedBSD interpreter inline in the BSD syscall code-path. What I do know is that, until 10.15, Apple tried to ensure that the BSD-userland libc-syscall codepath retained mostly the same behavioral guarantees as it did before they updated it, in terms of worst-case time-complexities of syscalls. Not sure whether that was using a short-circuit path that went around Seatbelt or used a "mini-Seatbelt" fast path; or whether it was by hard-coding a pre-compiled MAC ruleset for libc calls that only relied upon the filesystem flag-bits, and so never had to do anything blocking during evaluation.
Certainly, even as of 10.12, BSD-userland processes weren't immune to being exec(2)-blocked by the quarantine xattr. But that may have been a partial implementation (e.g. exec(2) going through the MAC system while other syscalls don't.) It's kind of opaque from the outside. It was at least "more than nothing", though I'm not sure if it was "everything."
One thing that is clear is that, until 10.15, BSD processes with no capabilities manifest, still had the pretty much exactly the same default set of privileges that they had before capabilities, which means "almost everything" (and therefore they almost never needed to actually hit up the security system for more grants.) I guess all Apple really needed to have done in 10.15 to "break BSD", was to introduce some more capabilities, and then not put them in the default/implicit manifest.
I suppose what actually happened in 10.15 can be determined easily-enough from the OSS code that's been released. :)
> Is this not implemented in the kernel as an extension? // I am fairly sure you can just embed a profile in a section of your app's binary and call the sandboxing Mach call with that…
Yeah, sorry, you're right; updated my assertions above. I'm not a kernel dev; I've just picked up my understanding of this stuff from running head-first into it while trying to do other things!
danudey
It's a new behavior that doing 'find ~' will trigger a MacOS (GUI) permissions warning dialog when `find` tries to access your photos directory, contacts file, etc.
jfkebwjsbx
Why would sandboxing be slower?
They are definitely doing something way too slow.
derefr
Apple replaced the very simple (i.e. function fits in a cache line; inputs fit in a single dword) BSD user/group/other filesystem privileges system, with a Lisp interpreter (or maybe compiler? not sure) executing some security DSL[1][2].
[1] https://wiki.mozilla.org/Sandbox/OS_X_Rule_Set
[2] https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...
This capabilities-ruleset interpreter is what Apple uses the term "Gatekeeper" to refer to, mostly. It had already been put in charge of authorizing most Cocoa-land system interactions as of 10.12. But the capabilities-ruleset interpreter wasn't in the code-path for any BSD-land code until 10.15.
A capabilities-ruleset "program" for this interpreter can be very simple (and thus quick to execute), or arbitrarily complex. In terms of how complex a ruleset can get—i.e. what the interpreter's runtime allows it to take into consideration in a single grant evaluation—it knows about all the filesystem bitflags BSD used to, plus Gatekeeper-level grants (e.g. the things you do in Preferences; the "com.apple.quarantine" xattr), plus external system-level capabilities "hotfixes" (i.e. the same sort of "rewrite the deployed code after the fact" fixes that GPU makers deploy to make games run better, but for security instead of performance), plus some stuff (that I don't honestly know too much about) that can require it to contact Apple's servers during the ruleset execution. Much of this stuff can be cached between grant requests, but some of it will inevitably have to hit the disk (or the network!) for a lookup—in the middle of a blocking syscall.
I'm not sure whether it's the implementation (an in-kernel VM doesn't imply slowness; see eBPF) or the particular checks that need to be done, but either way, it adds up to a bit of synchronous slowness per call.
The real killer that makes you notice the problem, though, isn't the per-call overhead, but rather that the whole security subsystem seems to now have an OS-wide concurrency bottleneck in it for some reason. I'm not sure where it is, exactly; the "happy path" for capabilities-grants shouldn't make any Mach IPC calls at all. But it's bottlenecked anyway. (Maybe there's Mach IPC for audit logging?)
The security framework was pretty obviously structured to expect that applications would only send it O(1) capability-grant requests, since the idiomatic thing to do when writing a macOS Cocoa-userland application, if you want to work with a directory's contents, is to get a capability on a whole directory-tree from a folder-picker, and then use that capability to interact with the files.
Under such an approach, the sandbox system would never be asked too many questions at a time, and so you'd never really end up in a situation where the security system is going to be bottlenecked for very long. You'd mostly notice it as increased post-reboot startup latency, not as latency under regular steady-state use.
Under an approach where you've got many concurrent BSD "filesystem walker" processes, each spamming individual fopen(2)-triggered capability requests into the security system, though, a failure-to-scale becomes very apparent. Individual capabilities-grant requests go from taking 0.1s to resolve, to sometimes over 30s. (It's very much like the kind of process-inbox bottlenecks you see in Erlang, that are solved by using process pools or ETS tables.)
Either Apple should have rethought the IPC architecture of sandboxing in 10.15, but forgot/deprioritized this; or they should have made their BSD libc transparently handle "push down" of capabilities to descendent requests, but forgot/deprioritized that.
dcow
A command like `terraform` shouldn't trigger the check because the quarantine system is bypassed altogether when you download and extract an archive. Maybe this is a red herring and your initial gut inkling is correct.
saagarjha
Try sampling the process as it starts; I doubt your issue is the one shown here.
acdha
> For example, I can run "terraform apply" and it could take up to 5 minutes to start, leaving my computer almost unusable until it runs.
On a clean Catalina install this does not happen. Does “terraform version” have the same delay? If not, check your remote configuration - maybe run with TF_LOG=trace. Terraform Cloud will definitely highlight the inherent performance problems of using a VPN.
jen20
It is worth noting that `terraform version` connects to HashiCorp’s own checkpoint service by default so this may not be the best test.
totetsu
docker run -i -t -v "$(pwd)":/project hashicorp/terraform:light apply /project/thing.tf . Maybe(if your projects terraform version is the latest.)?
brendangregg
Adding network calls to syscalls like exec() is utterly insane. This road can lead to bricked laptops where you can't run anything to fix it (imagine an unexpected network error that the code doesn't handle properly). And crackers will just use ways to overwrite running instruction text to avoid the exec().
The comments on the article are annoying: it good that there's a mini way to reproduce, but please, use some further debugging like tcpdump (it still exists on osx, right?). Last time I summarized osx debugging was https://www.slideshare.net/brendangregg/analyzing-os-x-syste...
I'd also stress test it: generate scripts in a loop that include random numbers and execute them.
xvector
There is no excuse for this except for sheer, utter incompetence. Everyone involved in writing and shipping this should be ashamed of themselves.
drvdevd
This is what I scrolled all the way down this thread for - to see if anyone thinks this is a good design/security decision on Apples part. I’m trying to understand what the reasoning is for this particular decision and if it actually makes the OS more secure in any meaningful way? Or does it actually- just degrade performance with very limited benefits? Are there any real benefits to this VS current security design in popular Desktop Linux distros at this point?
HappyDreamer
Couldn't this have been a business decision? Not about security? (just what they say?)
To make non-App-store apps annoyingly unusable, so the App store will sell more apps, instead of people downloading in other ways?
Just like Apple cripples the Safari browser and PWA apps.
Long term, maybe Apple wants to be able to remote-forbid apps if Apple is developing their own competing app?
Whilst most developers working at Apple understands this, and don't like it? Maybe the developers even feel happy about people here at HN being disappointed, and think that "now the business people here at Apple notice that this causes disappointment" ?
saagarjha
It checks that executables have been notarized by Apple? I can't say I really think notarization is great, but I think it's clear from their perspective how it would be beneficial?
will_pseudonym
Hey, malevolence can also play into this. Don't chalk everything up automatically to incompetence. /s
pmarreck
There’s going to be a big exodus of open source developers going to Linux-powered platforms instead of the standard Mac laptop because of this ridiculousness
cageface
This is happening at my company already because docker performance on Macs is terrible.
jfkebwjsbx
> the standard Mac laptop
There is nothing standard about a Mac laptop, both technically and in market share.
saagarjha
> And crackers will just use ways to overwrite running instruction text to avoid the exec().
This would require breaking your code signature and as such requires extra entitlements in the hardened runtime.
xenadu02
That's not quite correct. If network access is unavailable or fails then the exec is allowed. The behavior has been improved over time, putting stricter limits on how long the check is allowed to take before giving up.
The Mac remains a Mac: if you turn off SIP it also disables this behavior. You are free to choose less security for more convenience if that is your preference.
ridiculous_fish
The kernel sources are available.
saagarjha
…with everything to do with the sandbox left out.
ridiculous_fish
Fair point. These tarballs may be, err, editorialized.
If exec is blocking in the kernel on IPC to some daemon, that should be observable (e.g. Instruments with kernel traces enabled).
m463
Most of the important parts are left out.
at this point opensource and apple are sort of on life support.
millstone
Well NFS and SMB exist, you can exec() on such mounts.
nromiun
> 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!
> Apple’s most recent OS where it appears that low-level system API such as exec and getxattr now do synchronous network activity before returning to the caller.
Can anyone confirm this? Because honestly this is just terrifying. I don't think even Windows authorises every process from a server. This doesn't sound good for both privacy and speed.
mbreese
There are two new Security/Privacy Settings that I just noticed last night.
"Full Disk Access" to allow a program to access any place on your computer without a warning. A few programs requested this, so it looks like it's been around for a while.
The other one is "Developer Tools" and it looks pretty new. The only application requesting it is "Terminal". This "allows app to run software locally that do not meet the system's security policy". So, my reading of this is that in Terminal, you could run scripts that are unsigned and not be penalized speed-wise.
oefrha
I don't see it on macOS 10.15.4 (19E287). The full list of categories on my Privacy tab:
- Location Services
- Contacts
- Calendars
- Reminders
- Photos
- Camera
- Microphone
- Speech Recognition
- Accessibility
- Input Monitoring
- Full Disk Access
- Files and Folders
- Screen Recording
- Automation
- Advertising
- Analytics & Improvements
Are you running a beta build or something?
---
Update: Okay, I checked on my other machine and that one does have it (Terminal is listed but disabled by default). What in the actual fuck?!?
xenadu02
You can make the category appear and put Terminal in it with this command:
sudo spctl developer-mode enable-terminal
saagarjha
I don't see it on my machine. Do you happen to have System Integrity Protection disabled?
Sangeppato
Maybe you need Xcode, try running "mkdir /Applications/Xcode.app"
mbreese
Maybe if you ran Terminal.app once it would work?
(I'm also on 10.15.4 (19E287))
0x0
I wonder what "Developer Tools" grants in practice. Clicking the (?) for viewing built-in help does not mention this particular setting, it skips right over it going from "Automation" above it to "Advertising" below it.
undefined
saagarjha
I believe it means the process will no longer check for the Quarantine xattr.
ether_at_cpan
via https://lapcatsoftware.com/articles/catalina-executables.htm..., I've added an entry in my /etc/hosts to block requests to api.apple-cloudkit.com:
127.0.0.1 api.apple-cloudkit.com
127.0.0.1 *.api.apple-cloudkit.comken
Full Disk Access was added in 10.14 (2018), so it's relatively new.
jhrmnn
I'm using the Kitty terminal, and observed the script launch delay described in the blog post. After adding Kitty to "Developer Tools", the delay disappeared. Thanks!
dTal
Making this about speed is burying the lede. From a privacy and user-freedom perspective, it's horrifying.
Don't think so? Apple now theoretically has a centralized database of every Mac user who's ever used youtube-dl. Or Tor. Or TrueCrypt.
gitgud
Richard Stallman's ideals have become a bit less crazy for me now...
Either you have the ability to control the software, or it controls you
verytrivial
I think coming to this realisation about Stallman's ideas (not the man, mind) is something that most rational computer users are bound to do. It happens at different times for different people, but I think people very rarely go back after that "Hang on a second ....??" moment.
hexchain
I always wonder why people usually choose to neglect privacy issues about Apple.
First, there was Apple scanning photos to check for child abuse[0] (that obviously got no attention on this site), then there was this one - Apple uploading hashes of all unsigned executables you run.
Do people really accept that company's "privacy" selling point?
[0] https://news.ycombinator.com/item?id=21180019, https://news.ycombinator.com/item?id=22008855
acecilia
Is it even legal that Apple is retrieving this information?
ccmcarey
How could this possibly not be absolutely awful on projects that run hundreds of executables during their execution (e.g. some shell wrappers like oh-my-zsh call out to a large amount of different scripts every time they run).
parhamn
It looks like it is done once by executable lifetime. Changing the content doesn't cause it to rerun.
gowld
If you don’t trust Apple, don’t run a multi Gigabyte closed source OS they provide.
parhamn
I can confirm that executing a trivial script takes 20-200ms longer on the first run. Using 10.15.
undefined
neurobashing
not sure if I'm lucky or somehow I disabled something but the trivial script problem isn't affecting me on any of my machines. I am using Homebrew for a large % of command line/scripting so maybe that's why?
greatjack613
Privacy it may be a plus since in theory notarization provides some protection.
Speed, definitely not, this is going to make things slowwwww
gouggoug
I experienced this one day while tethering in the train. I was coding and running `go build` multiple times.
I could not for the life of me understand why go build would take upwards to 30 seconds to run and sometimes 100ms. I finally realized it was related to my internet connection being extremely spotty. I went online and searched if anybody had the same experience with `go build` but couldn't find anything.
I finally know what happened. This is a pretty intolerable "feature".
lallysingh
Does it work at all when unconnected?
enriquto
There seems to be a delay of about 5 seconds, then it "gives up" trying to notarize your program .
gouggoug
I don't remember if it did or not, but I'm fairly certain it did. (otherwise I'd probably remember it, I think...)
unown
As someone living in China, this is my result when I connected to my VPN (this is my normal life, thus I can visit sites like HN):
> Hello
> /tmp/test.sh 0.00s user 0.00s system 0% cpu 5.746 total
> Hello
> /tmp/test.sh 0.00s user 0.00s system 79% cpu 0.006 total
And even if I didn't connect to my VPN:
> Hello
> /tmp/test2.sh 0.00s user 0.00s system 0% cpu 1.936 total
> Hello
> /tmp/test2.sh 0.00s user 0.00s system 78% cpu 0.005 total
That's just ridiculous and unbearable.
Apple should provide a way to disable this notarization thing, and the user should still be able to enable SIP while disabling it.
additional information:
- macOS version: 10.15.4
- terminal: iTerm2 3.3.9
- didn't install any "security" software
wux
I'm curious what your results would be with the stock Terminal. Do you have the settings that others have talked about under "Security > Privacy > Developer Tools" with Terminal.app listed? If so, and the results are better with Terminal, then it'd be interesting to see if the issue is fixed when you add iTerm2 to the list of exempted apps as well.
unown
I have tried what you suggested. Granting "Developer Tools" access definitely FIXED THIS ISSUE for the specific application.
Here is the new result (I only run once for each case):
╒══════════╤═════════════╤═══════════════════════════╕
│ │ │ +"Developer Tools" access │
╞══════════╪═════════════╪═══════════════════════════╡
│ terminal │ 1.448/0.004 │ 0.016/0.004 │
├──────────┼─────────────┼───────────────────────────┤
│ iTerm2 │ 1.240/0.006 │ 0.024/0.007 │
╘══════════╧═════════════╧═══════════════════════════╛
(It seems I have "good" VPN/internet connection condition at this time)
airstrike
Upvoted for ASCII table alone
ccmcarey
It doesn't work when there's no network connection, wonder if it would be possible to filter out and automatically block notarization traffic, or if it's all encrypted with cert pinning to prevent this type of MITM+filter.
Karliss
Dropping packets when there is an otherwise working connection could potentially make the delay even worse depending on timeout or retry strategy used by Apple code. I assume that in the fast case without network connection it checks the network status flag and doesn't try to do any network connection at all.
ttsda
I'm still on 10.14, but I guess it will show up on Little Snitch. Unless they bundle it with some other more essential traffic.
chipotle_coyote
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
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.)
Sangeppato
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
varenc
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.
false_kermit
I just ran the same script on iTerm2 and had no delay.
Sangeppato
I had no delay neither until I reinstalled iTerm2, I have no idea why
chipotle_coyote
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.
defnotashton2
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...
grishka
> 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"
nightowl_games
That argument reads to me like the implementer knew this stuff was obtrusive.
jaykru
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.
ehutch79
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.
chipotle_coyote
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.
mrits
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.
undefined
fxtentacle
try again with a randomized filename
saagarjha
There was a thread on the almost-forgotten Cocoa-dev list about this: https://lists.apple.com/archives/cocoa-dev/2020/Apr/msg00008...
Catalina has a huge number of things that synchronously block application launch, and if any of them fail you get nothing but a hung app. A friend and I have a running discussion of the many ways where an application would just hang and we’d send samples and spindumps, to each other trying to figure out the right daemon or agent to kill to get the process to start responding again. It’s madness.
twhb
I tested whether running a script you just wrote really contacts Apple to “notarize” it. It does.
I first used the author’s timing method. First runs are consistently about 300 ms, subsequent runs consistently about 3 ms. Something is happening at first run.
Some in the comments are saying it’s “local stuff”, so I tested timing again with internet off. First runs go to about 30 ms, subsequent remain the same. So there is “local stuff”, but it doesn’t explain the delay.
Just to be entirely sure, I installed Little Snitch and got clear confirmation: running a script you just wrote results in syspolicyd connecting to api.apple-cloudkit.com. syspolicyd is the Gatekeeper daemon.
I don’t know what exactly is being sent. Maybe somebody else can do a proper packet analysis.
mindfulhack
I still love macOS, a lot. Since moving over after the disaster that was Windows 8 (and by then I was already using MacBook hardware), I've become a loving power user e.g. with AppleScript and setting up hotkeys or other ways to do absolutely anything I want on the screen. It really is still as powerfully customisable as Linux. Turn off SIP if need be.
My only problem in moving to Linux software is that I prefer Apple's hardware. I'm on the 2019 16-inch MBP. Linux's compatibility with all the T2 and SSD hardware isn't there yet, but apparently it almost is.
If Linux on the T2 MBP becomes solid and stable in the next 1-2 years, after extensive testing I may move over permanently. I already use Linux on secondary computers, and I love and value its privacy. Same with my phone. I just love my privacy.
My needs are a high bar though. Productivity must be held back by nothing. I use macOS notes extensively and it syncs with my iPhone which is an extremely useful tool for me to note things down both in audio and. It needs to be reliable and - heh - 'just work'. I just discovered the cross-platform 'Standard Notes' app, with a bit more money paid out to Linux-compatible services like that, maybe it can all work. Casual photoshop can be taken care of via a VM.
Surprisingly, macOS Catalina is itself a disrupter to my productivity. It seems buggy as hell - glitchy, and weirdly slow for many extremely basic things - all since Catalina. I just don't get it. Is it caused by this article's observation? Something's definitely going on.
Maybe Apple will fix this in the next release? Like how they fixed the keyboard?
Either way, I still want to move to Linux on this fabulous (fixed) hardware that is the 16-inch MBP. (T2 issues aside.)
fphhotchips
I have a 2019 Macbook Pro 16in and I hate it. It runs exceptionally hot (leading to massive performance problems), doesn't get enough power from the adapter to start with no battery, doesn't play nicely with my display, needs restarting every couple of days so Chrome doesn't crash and takes forever to boot.
That's just the technical problems. I'm willing to give the UI a break, since it's probably as much me adjusting as it being bad.
This is my first Apple anything, and if this is what "just works" looks like, I don't want it. I could be more productive on an Android tablet at this point.
mindfulhack
Actually, I do agree with you with some of those observations. Apple's been trying to fix their terrible T2 issue and I suspect some of the problems lately have been them trying to prevent the T2 reboot crash, while ruining other parts of the experience in the process as a necessary compromise. It may get worse (or better) as they move to all-Arm architecture.
I also am sick of the touch bar now - after 2 years living with it. I have to press it twice to actually pause my media, because it's an LCD screen and it has to auto turn off to prevent burn-in. That's a regression from the old hard media button in the Fn row which was both instant and far easier to press. At least we got 'Esc' back.
But man, their trackpad...nothing beats it. Still.
saagarjha
> it's an LCD screen
OLED.
arkis22
Mine starts spinning up the fan (theres kind of a pattern as to when), heating up the entire computer. The computer previously had been fine.
I usually have to restart and reset the "SMC" to stop the fan from nuking the computer.
I can let the computer drop to 5% battery life and the fan will turn off and the computer will cool down. Which is the opposite of what you want if it was actually overheating.
carnitas
Counterpoint, I also have the 16 inch 2020 MBP as my first Mac work laptop and absolutely love it. No issues, it works perfectly, and I’m 2x as productive on it as I was on my previous Ubuntu setup.
ochoa
Do you write anywhere online about your workflow setup using AppleScript? It sounds interesting. I’d like to configure my macOS experience more.
mindfulhack
Oh it's not like I have a Cmd+<X> for every single possible task you can imagine, it's a very tailored and customised set of sometimes complicated scripts for my weird personal needs that I've built up over the years.
Each time I want to do something, I goddamn will spend 8 hours figuring it out if have to. E.g. this: https://apple.stackexchange.com/a/381441/163629 - one hotkey to change macOS Notes text into a specific hex colour (and/or bold etc). It took me a day but I worked it out. Where there's a will there's, 99 times out of 100, a way.
You can seemingly do almost anything with AppleScript. Emphasis on almost.
Here's another example: Right after I plug in my iPhone via USB, I have one hotkey to automate a little-known feature of macOS where you can turn your Mac into a speaker dock for the iPhone. Awesome thing when you have the dramatically improved 16-inch MBP speakers. Here's my applescipt for that, just customise according to your iPhone name near the bottom and try it out: https://pastebin.com/raw/9BY710Y6
YMMV, if you have additional audio devices in sound prefs so may need to change the code a bit.
AppleScript also has the ability to perform unix bash scripting and commands, so with homebrew able to install most common Linux packages, you can go wild if you want.
I'm definitely not 'advanced' applescript level, I'm intermediate. Hundreds of HN readers would know more than me. I just google and think until I find a way. I'm not a programmer.
I have other shortcuts e.g. to control the MPV media player even if it's not the currently active window. Again, weird personal needs, but awesome. AppleScript to the rescue.
FastScripts is how I assign universal hotkeys to any of my applescripts.
guildmaster
Would be great if you could write about the scripts you hack to optimize your workflow
ronyfadel
I hope Apple currently has a team focused on macOS perf.
I worked on the team in charge of improving iOS (13) perf at Apple and IIRC there was no dedicated macOS “task force” like the one on iOS.
Luckily some iOS changes permeated into macOS thanks to some shared codebases.
bentcorner
I agree. This kind of behavior certainly smells like teams doing their development work on high-capacity low-latency networks without much performance oversight.
yariik
> I hope Apple currently has a team focused on macOS perf.
Apple doesn't give a fuck about macOS since 2015.
cjsawyer
I wonder what % of their users are developers only begrudgingly sticking around for iOS builds.
pier25
> IIRC there was no dedicated macOS “task force” like the one on iOS
It's not surprising. Macs are less than 10% of Apple's revenue.
https://www.macrumors.com/2020/04/30/apple-2q-2020-earnings/
robenkleene
Except all of Apple's other devices are built on macOS. Apple's clear de-prioritization of macOS based on revenue numbers is so insane I can barely believe it's happening. If developers, who use Macs in large numbers today, go to another platform, there's very real risk that their entire empire starts to come apart at the seams. And, this may just be me being naive, but it doesn't seem like that much work to keep macOS going, all they have to do is stop trying to turn it into iOS. They are literally doing a tremendous amount of active engineering work that drives developers away from their platforms.
They are risking their entire empire because (apparently) someone at Apple has an axe to grind with macOS's Unix underpinnings. And until they start getting real consequences (developer's leaving in huge numbers), it doesn't seem like it's going to stop. The tragedy is, if they ever do reach that point, where developers are leaving in huge numbers, it'll be too late. Platforms are a momentum game, you're either going up, or you're going down. And once you're going down, you're as good as dead.
fxtentacle
Agree. That's probably also one reason why more and more people want to use cross-platform app frameworks instead of developing for iOS natively. That way, you can do most of the dev work on Windows and Android, and you'll only need to use Mac & XCode for compiling the iOS binary.
And I'd wager that some iOS games are released without the developer ever touching XCode: https://docs.unity3d.com/Manual/UnityCloudBuildiOS.html
gubikmic
100% agree! If more people understood this, I hope this narrative would gain some traction and eventually reach Apple management.
To me, the idea that an OS is mostly finished is completely bananas. There's so much room for improvement and hardly any of that potential was tapped into in what's starting to feel like a decade.
And if Apple had invested into a successor for Cocoa, there might be a larger gap between native apps and (Electron) web apps, leading to some lock-in. Instead most new stuff is not native and for good reasons (and I do dislike the way they don't adhere to Mac conventions, but still).
I think ultimately the problem is Tim Cook. He's too attached to Apple's stock price. I think that's the one metric that he believes rates his performance. But inertia is a bitch. Like in politics, the effects might hit hard only once he's out and it could be too late to fix by then.
If I think about how much this impacts the economy overall (i.e. make millions of knowledge workers a little bit less efficient) then I can only hope that I'll see more sophisticated organizational structures in my lifetime that prevent such erosion.
plmu
I was thinking exactly this, 8 years ago. I moved from an imac + mbpro to linux only.
It took longer than expected. I even intended to buy put options, but someone I trust told me otherwise and to invest in equity instead, which I did, because I know that most buy decisions are not made rationally.
But it looks like the time has come now? On the other hand, I have been off by several years before. People are crazier than you think, especially when it comes to status and association with brands and self-confirmation of past decisions. They might well put up with Apples moves for a few more years.
robotresearcher
But at Apple scale: 9% of $58 billion = $5.2 billion Mac revenue last quarter.
ksec
Yes, that is what drives me crazy whenever people say Mac is only 9% of revenue and they dont care about it.
If the Mac revenue was separated out on its own, it would be about Fortune 120, that is higher than Kraft Heinz. With plenty more space for growth. Apple only has 100M Active Mac users. There are 1.4B Windows PC.
pier25
OTOH when Apple was a much smaller company the mac was much more important to them and it showed.
Maybe it's not related to revenue per se, but clearly since iOS became their main thing the Mac has suffered tremendously.
valuearb
Apples Macintosh division is the most profitable PC company in the world and has been for at least a decade. In fact, Macintosh is likely more profitable than all other PC companies combined.
Less than 10% is no excuse.
pier25
Like I said in another comment, is not about the revenue per se, but it's undeniable that the more popular iOS is the less Apple cares about the Mac.
_underfl0w_
Do you have a source for that claim?
goatinaboat
It's not surprising. Macs are less than 10% of Apple's revenue.
Without Macs for developers and other content creators that other 90% doesn’t exist.
ARandomerDude
Exactly. Especially given the Xcode lock-in nonsense.
qppo
It's surprising that they don't improve the developer experience for their own developers using their own tools, including hardware.
saagarjha
Apple uses the same tools you do. They just might not be using it like you are; you can find a lot of features that clearly have no reason to exist outside of Apple nonetheless shipping with their software.
callinyouin
I wouldn't be surprised if they've determined that developers will generally put up with a bad experience in order to have access to the massive iOS market.
arvinsim
There isn't much incentive to improve because they know that people will buy their hardware regardless.
Not to mention people defend and market their products for free.
pier25
Maybe internally they are using a different version of macOS?
codeisawesome
I find it funny how people are downvoting your innocent comment pointing out a fact... out of anger and hate for the actual fact :D
markdog12
What changes permeated into macOS? What did your team do to improve iOS perf?
ronyfadel
So many of the frameworks have shared code between macOS and iOS (e.g. MapKit, Foundation, Contacts etc..), so a perf fix in iOS pays dividends on macOS too.
Perf changes are too numerous to mention, I’d recommend watching last year’s WWDC keynote describing the iOS 12 v/s 13 perf advancements.
neuronic
They set "fast = true" as a global constant variable.
Get the top HN stories in your inbox every day.
It seems like there is a lot of confusion here as to whether this is real or not. I've been able to confirm the behavior in the post by:
- Using a new, random executable. Even echo $rand_int will work. Edit: What I mean here is generate your rand int beforehand and statically include it in your script.
- Using a fresh filename too. Just throw a rand int at the end there. e.g. /tmp/test4329.sh
I MITMd myself while recording the network traffic and, sure enough, there is a request to ocsp.apple.com with a hash in the URL path and a bunch of binary data in the response body. Unsure what it is yet but the URL suggests it is generating a cert for the binary and checking it. See: https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...
Here's the URL I saw:
http://ocsp.apple.com/ocsp-devid01/ME4wTKADAgEAMEUwQzBBMAkGB...
Edit2: Anyone know what this hash format is? It's not quite base64, nor is it multiple base64 strings separated with '+'s but it seems similar...
Edit3: Here is the exact filename and file I used: https://gist.github.com/UsmannK/abb4b239c98ee45bdfcc5b284bf0...
Edit4 (final one probably...): On subsequent attempts I'm only seeing a request to https://api.apple-cloudkit.com and not the OCSP one anymore. Curiously, there's no headers at all. It is just checking for connectivity.