It appears that Howard Oakley is once again very confused. Unfortunately, his blog is sometimes a foundation of misinformation, which drives me nuts. The Apple technical note that he links to is talking about a process updating itself at runtime while its code signing information is cached by the kernel in memory. Oakley has somehow warped that into a some kind of disk cache, using the odd phrasing "saved to the kernel's cache against the vnode".
> spctl has a --ignore-cache option. So the result of gatekeeper is indeed cached somehow.
Yes. I think it's in /var/db? But again, it's not a cache of the hashes of every file in the app bundle. What would the system even do with that? Not only is there no evidence for the existence of such a thing, but its existence would make no practical sense. Oakley is simply grasping for something that takes a significant amount of time computationally, without giving much consideration to what would be done with the products of that computation.
> And presumably as you noted it's a cache miss for this which causes the long application launch delay.
No, I've showed that it's a periodic malware scan.
What's most amusing is that in the most recent blog post (https://eclecticlight.co/2025/04/30/why-some-apps-sometimes-...), the handful of log statements that serve as the source of the claim in fact confirm that it is syspolicyd performing a malware scan that is responsible for the delay during launch.
11.012004 com.apple.syspolicy.exec Recording cache miss for <private>
20.898736 AppleSystemPolicy Waking up reference: 174
The first of the two messages is from `syspolicyd` and is reporting that it has no cached malware scan result for a file it was asked to scan. The malware scan is triggered by an up-call within the AppleSystemPolicy kernel extension during a MACF hook (`proc_notify_exec_complete`, `file_check_library_validation`, or `file_check_mmap`) if the kext doesn’t have a cached malware scan result for the vnode of the file in question.
The second log message is from the AppleSystemPolicy kernel extension when it receives the result of the malware scan and permits the process to resume execution.
It's a little puzzling that the original analysis is published based on speculation, without any real attempt at verifying that the data supports their hypothesis. Looking at `top` or Activity Monitor during the slow launch would show which process is performing work. A spindump captured during the slow launch would reveal what work it is doing. The system log store captures the process and subsystem that logged any given message. A few minutes in Binary Ninja or Hopper gives you a rough idea of what the code that emits the log is doing.
Oakley's brain just seems to be stuck in a loop of misunderstanding and mistaken assumptions. He gave the same bizarre response to me that he gave to you:
"The only feature in macOS that I know of that matches that description is what Apple terms XProtect, and there are only two (in Sequoia, previously one) sets of Yara rules in macOS. Now if I’m missing something, please tell me where those other Yara rules are." https://eclecticlight.co/2025/04/22/why-some-apps-launch-ver...
It appears that Howard Oakley is once again very confused. Unfortunately, his blog is sometimes a foundation of misinformation, which drives me nuts. The Apple technical note that he links to is talking about a process updating itself at runtime while its code signing information is cached by the kernel in memory. Oakley has somehow warped that into a some kind of disk cache, using the odd phrasing "saved to the kernel's cache against the vnode".
> spctl has a --ignore-cache option. So the result of gatekeeper is indeed cached somehow.
Yes. I think it's in /var/db? But again, it's not a cache of the hashes of every file in the app bundle. What would the system even do with that? Not only is there no evidence for the existence of such a thing, but its existence would make no practical sense. Oakley is simply grasping for something that takes a significant amount of time computationally, without giving much consideration to what would be done with the products of that computation.
> And presumably as you noted it's a cache miss for this which causes the long application launch delay.
No, I've showed that it's a periodic malware scan.