TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Mac app launches slowed by malware scan (2024)

118 点作者 username22314 天前
Follow-up: <a href="https:&#x2F;&#x2F;lapcatsoftware.com&#x2F;articles&#x2F;2025&#x2F;5&#x2F;1.html" rel="nofollow">https:&#x2F;&#x2F;lapcatsoftware.com&#x2F;articles&#x2F;2025&#x2F;5&#x2F;1.html</a>

9 条评论

john-h-k13 天前
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.<p>It’s a pretty niche use case but it’s deeply frustrating
davb13 天前
Related, I found that even after designating an application (iTerm2) as a &quot;Developer Tool&quot; in System Settings -&gt; Privacy &amp; 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 <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;davebarkerxyz&#x2F;4111276ae1fb4a7566b271bd7afed607" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;davebarkerxyz&#x2F;4111276ae1fb4a7566b271...</a> (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).<p>Fortunately as of Sequoia (15.4.1), I&#x27;m no longer able to reproduce the issue.
carlosjobim14 天前
EVERYBODY: You can fix the Affinity slow start-up problem on MacOS in a simple step:<p>Go to your App folder and duplicate the &quot;Affinity Photo 2&quot; app. Then remove the original and use the duplicate.<p>Now Affinity starts in 2 seconds instead of in 30 seconds on my M3 machine.
评论 #43862505 未加载
评论 #43871192 未加载
评论 #43860757 未加载
评论 #43860789 未加载
评论 #43864040 未加载
评论 #43876280 未加载
评论 #43864993 未加载
krackers13 天前
&gt; 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<p>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&#x27;s fast. So _some_ bit seems to be stored somewhere indicating whether or not this is &quot;first launch&quot; and whether full verification needs to be performed (maybe it&#x27;s the launch services cache?)<p>As for whether the entire image is verified before _each_ launch, I&#x27;m not 100% familiar with the flow but I don&#x27;t think that&#x27;s correct, it can be done lazily on a page by page basis. <a href="https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;endpointsecurity&#x2F;es_process_t" rel="nofollow">https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;endpointsecurity&#x2F;e...</a><p>&gt;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.<p>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&#x27;d assume yara signature checks would apply.
评论 #43863100 未加载
larrywright14 天前
I wonder if this is why Fusion 360 is so slow to start. It&#x27;s by far the slowest app on my relatively modern M1 MacBook Pro.
评论 #43861519 未加载
eviks13 天前
&gt; doubt that the built-in system libraries are scanned for malware, because they reside on a separate cryptographically-signed read-only disk volume.<p>Would be nice to be able to do the same for user apps and only scan on volume updates (when app update) instead of the current constant waste of time and energy
m304713 天前
TIL: MacOS ships with YARA.
musicale12 天前
syspolicyd rears its ugly head again.
lapcat14 天前
Author here. It&#x27;s unclear why HN is interested in this post, because it&#x27;s just a response to another blogger&#x27;s recent posts, which weren&#x27;t even submitted to HN. Visitors aren&#x27;t going to have the background context.<p>My original post &quot;Mac app launches slowed by malware scan&quot; was submitted to HN last year, though it received 0 comments at the time. <a href="https:&#x2F;&#x2F;lapcatsoftware.com&#x2F;articles&#x2F;2024&#x2F;2&#x2F;3.html" rel="nofollow">https:&#x2F;&#x2F;lapcatsoftware.com&#x2F;articles&#x2F;2024&#x2F;2&#x2F;3.html</a>
评论 #43860639 未加载