[HN Gopher] Mac app launches slowed by malware scan (2024)
___________________________________________________________________
Mac app launches slowed by malware scan (2024)
Follow-up: https://lapcatsoftware.com/articles/2025/5/1.html
Author : username223
Score : 80 points
Date : 2025-05-01 15:25 UTC (7 hours ago)
(HTM) web link (lapcatsoftware.com)
(TXT) w3m dump (lapcatsoftware.com)
| lapcat wrote:
| Author here. It's unclear why HN is interested in this post,
| because it's just a response to another blogger's recent posts,
| which weren't even submitted to HN. Visitors aren't going to have
| the background context.
|
| My original post "Mac app launches slowed by malware scan" was
| submitted to HN last year, though it received 0 comments at the
| time. https://lapcatsoftware.com/articles/2024/2/3.html
| username223 wrote:
| Submitter here. I submitted it because it explains a bug I
| recently encountered. Other people apparently found it useful.
| Should I delete it?
| lapcat wrote:
| > Should I delete it?
|
| Is that even possible?
|
| Anyway, I just think my 2024 post is a better place to start,
| because it explains the issue directly, whereas this new post
| simply refutes another blogger and argues that there's
| nothing new beyond my 2024 post. That interpersonal
| drama/conflict probably isn't going to be understandable or
| useful to readers.
| tough wrote:
| @dang or mods can replace a main discussion link if they
| think its apt/good for the final user you might write to
| the email on the footer of this page to reach them
| dang wrote:
| Ok, we've switched to that from
| https://lapcatsoftware.com/articles/2025/5/1.html above,
| and I'll add a link to the follow-up to the top text.
| carlosjobim wrote:
| EVERYBODY: You can fix the Affinity slow start-up problem on
| MacOS in a simple step:
|
| Go to your App folder and duplicate the "Affinity Photo 2" app.
| Then remove the original and use the duplicate.
|
| Now Affinity starts in 2 seconds instead of in 30 seconds on my
| M3 machine.
| dijit wrote:
| Why does this work?
| carlosjobim wrote:
| I have no idea. I found it deeply buried in a support forum
| the other day.
| pier25 wrote:
| I just updated to the latest version and Affinity Photo 2 opens
| in seconds now.
| spiffotron wrote:
| I'd legitimately love to know why this has worked wtf
| mmastrac wrote:
| I bet you could get the same results by duplicating the inner
| binary only rather than the whole folder. I saw something very
| similar with terminal apps.
|
| The blog post doesn't mention this app - am I missing
| something?
| larrywright wrote:
| I wonder if this is why Fusion 360 is so slow to start. It's by
| far the slowest app on my relatively modern M1 MacBook Pro.
| Avamander wrote:
| It's slow on almost everything, so I kinda doubt macOS is to
| blame.
| m3047 wrote:
| TIL: MacOS ships with YARA.
| john-h-k wrote:
| I've got a personal project compiler I built and it's hit by this
| very hard. Testing involves (naturally) generating lots of
| executables. Running it in a Linux docker container takes around
| ~1s for all 500 tests. macOS by default takes around a _minute_,
| and even with the workarounds I've found ("allow untrusted
| software to be run by iterm2") it takes 5-8 seconds.
|
| It's a pretty niche use case but it's deeply frustrating
| krackers wrote:
| > Macs have a cache of SHA-256 hashes of all bundled files of all
| apps that have been launched. But where exactly is this cache
|
| I always assumed this had to be the case? When you first launch
| an application gatekeeper takes a long time verifying it, but on
| subsequent launches it's fast. So _some_ bit seems to be stored
| somewhere indicating whether or not this is "first launch" and
| whether full verification needs to be performed (maybe it's the
| launch services cache?)
|
| As for whether the entire image is verified before _each_ launch,
| I'm not 100% familiar with the flow but I don't think that's
| correct, it can be done lazily on a page by page basis.
| https://developer.apple.com/documentation/endpointsecurity/e...
|
| >In the specific case of process execution, this is after the
| exec completes in the kernel, but before any code in the process
| starts executing. At that point, XNU has validated the signature
| itself and has verified that the cdhash is correct. This second
| validation means that the hash of all individual page hashes in
| the Code Directory match the signed cdhash, essentially verifying
| the signature wasn't tampered with. However, XNU doesn't verify
| individual page hashes until the binary executes and pages in the
| corresponding pages. XNU doesn't determine a binary shows signs
| of tampering until the individual pages page in, at which point
| XNU updates the code signing flags.
|
| If you can replicate this on an Intel mac where code signature is
| optional, you could try more rigorous comparisons comparing an
| unsigned binary vs a signed one. In both cases I'd assume yara
| signature checks would apply.
| lapcat wrote:
| > So _some_ bit seems to be stored somewhere indicating whether
| or not this is "first launch"
|
| Yes, of course.
|
| How do you go from that to "a cache of SHA-256 hashes of all
| bundled files of all apps that have been launched"?
| krackers wrote:
| Isn't there some cache of code-signing info?
| https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS
|
| >Specifically, the code signing information (code directory
| hash) is hung off the vnode within the kernel, and modifying
| the file behind that cache will cause problems. You need a
| new vnode, which means a new file, that is, a new inode.
| Documented in WWDC 2019 Session 703 All About Notarization -
| see slide 65 (PDF).
|
| This seems to be described in
| https://eclecticlight.co/2024/04/29/apfs-beyond-to-vfs-
| and-v... but I'm just a layman here.
|
| And I realize now the initial gatekeeper scan is probably
| just controlled by presence of quarantine bit, the result
| themselves are probably not cached.
|
| Edit: Now I'm not so sure, spctl has a --ignore-cache option.
| So the result of gatekeeper is indeed cached somehow. And
| presumably as you noted it's a cache miss for this which
| causes the long application launch delay.
| davb wrote:
| Related, I found that even after designating an application
| (iTerm2) as a "Developer Tool" in System Settings -> Privacy &
| Security, there were circumstances where notarisation checks were
| still carried out. Particularly, launching tmux then detaching
| and reattaching would cause the processes to no longer be exempt.
| This applies to any executable (+x), including shell scripts. I
| put together a test script that proves it at
| https://gist.github.com/davebarkerxyz/4111276ae1fb4a7566b271...
| (the second run is much quicker than the first one after a tmux
| reattach, but within applications marked as Developer Tools the
| times should be nearly identical).
|
| Fortunately as of Sequoia (15.4.1), I'm no longer able to
| reproduce the issue.
___________________________________________________________________
(page generated 2025-05-01 23:01 UTC)