President Trump discussed if he would consider a pardon for Sean Combs, while in court, an ex-assistant testified about sexual abuse. Mr. Combs denies sexually assaulting anyone.
As the trial of Sean Combs ends its third week, a woman who used to work as his assistant continued testifying about her grueling experience, which she said included sexual assaults by him.
In an effort to present Mr. Combs as the leader of a criminal enterprise, an investigator testified about the drugs, guns and other items found in his Florida mansion.
Apple has just released the update to macOS Sequoia to bring it to version 15.5, and security updates for 14.7.6 and 13.7.6.
The Sequoia update for Apple silicon Macs is just under 3 GB in size, and just over 2 GB for Intel Macs.
Apple’s general release notes for Sequoia 15.5 only mention one new feature, that parents now receive a notification from a child’s device when its Screen Time passcode is used. Otherwise, it’s the usual “enhancements, bug fixes, and security updates”.
Security release notes for Sequoia 15.5 are here, and list 46 vulnerabilities fixed, none of which are reported as believed to have been exploited already. Those for 14.7.6 are here, and for 13.7.6 are here.
One important entry in the Enterprise release notes concerns the future of AFP: “Apple Filing Protocol (AFP) client is deprecated and will be removed in a future version of macOS.” I can hear the howls of anguish already.
large network shares should enumerate correctly in the Finder,
Pro Display Calibrator should work properly on M4 MacBook Pros,
apps registering helper executables should now do so correctly.
The macOS build number is 24F74. Firmware in Apple silicon Macs is updated to iBoot version 11881.121.1, while that in T2 Macs is updated to 2075.120.2.0.0 (iBridge 22.16.15072.0.0,0).
Safari is updated to version 18.5 (20621.2.5.11.8), and there are 8 security bugs fixed in WebKit (15.5).
Many of you have commented that you too find that apps and command tools can now take surprisingly long to launch. Although my previous analyses have demonstrated how those can often be attributed to security checks being made on components including frameworks and dylibs, there remains some dispute over the nature of those checks. Although I believe there’s convincing evidence that those checks are prolonged to recompute hashes and CDHashes, others are adamant that they are in fact ‘malware scans’. This article considers new evidence.
Inspecting and analysing the log during the launch of large apps isn’t the best way of getting a clear view of what happens when macOS runs its security checks. There’s a great deal going on at the time, with multiple security checks being performed for TCC, LaunchServices and RunningBoard in dialog, sandboxes and containers to set up, and iCloud services to connect. Last week I’ve been tackling this more methodically, and here use two launches of a simple command tool to give clearer insights into what’s going on when macOS runs its security checks.
Methods
The command tool in question is my blowhole, just over 200 KB of simple code to write a message to the log, hence directly telling us when it’s run. It has its signing certificate embedded into its Mach-O binary, and is notarized. However, because it’s a single binary and not an app bundle, its notarization ticket is stapled to its installer package, and not to the tool itself.
The two runs I analyse here are:
On a Mac Studio M1 Max running macOS Ventura 13.4.1 at 14:32 on 4 July 2023. blowhole had already been installed on that Mac, but the copy being run was in a previously unknown location, ~/Documents, which normally forces macOS to perform more extensive security checks, including an XProtect scan and notarization checks, but not as thorough as when in quarantine.
On a Mac mini M4 Pro running macOS Sequoia 15.4.1 at 20:07 on 2 May 2025. Although blowhole had been installed and run some weeks previously, it hadn’t been run since then, and was expected to attract more extensive security checks, including an XProtect scan and notarization checks, but not as thorough as when in quarantine.
The first of those was collected using Ulbow, and the second by LogUI. Excerpts giving milestone entries are given in the Appendix at the end. In the diagrams below, each milestone is given with time in seconds elapsed since the first mention of the binary.
Ventura
First mention of the tool to be run comes from AppleMobileFileIntegrity (AMFI), which leads immediately to its daemon amfid starting its assessment of the binary, with the entry SecTrustEvaluateIfNecessary to inspect the signature and the CDHashes it contains. As this takes a mere 0.003 seconds, and the next stage starts 0.01 seconds after amfid entered the path to the binary, all that could have done was confirm the integrity of the signature, its requirements, and that its hashes were already cached.
syspolicyd then records the start of the Gatekeeper process assessment, and initiates the Gatekeeper scan, first starting checks on the notarization ticket, then starting the XProtect scan while ticket checking proceeds. Of those, the XProtect scan completes first, returning its results to syspolicyd at 0.054 seconds after the start.
Ticket checking involves an explicit connection to iCloud using CloudKit, with abundant log entries. The CloudKit Ticket Store is found to be reachable, and the ticket checked for the CDHashes obtained earlier from the tool’s signature.
With both checks completed satisfactorily, at 0.192 seconds the Gatekeeper scan is declared complete, syspolicyd evaluates its result, and is almost ready for the tool to run. Before that can happen, details of the executable are entered into provenance tracking. syspolicyd confirms the evaluation allows the tool to run, and AppleSystemPolicy records the evaluation result.
Sequoia
The sequence here is very similar to that in Ventura, with some significant differences, marked in the emphasised items in the diagram above.
First, there’s a substantial delay of 0.063 seconds between amfid entering the binary’s path and the start of the Gatekeeper process assessment. This started with entries from amfid recording SecTrustEvaluateIfNecessary and trustdSecKeyVerifySignature, indicating that more took place here than in Ventura. However, there’s no evidence of any external signature checks being made, and it’s most likely that the binary’s hashes weren’t cached, so required recomputation to verify them. The delay is woefully inadequate for any form of malware scan to have taken place at this stage.
When XprotectService reports that XProtect is performing the malware scan, it additionally reports the location of the XProtect rules being used. That’s because Sequoia introduced a new location used for those data files, in /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara as recorded here.
Next, the XProtect scan here takes 0.126 seconds, rather than 0.030 seconds in Ventura. This is the result of the huge growth in the number and complexity of the Yara rules used for this scan over the last two years. The Ventura scan was performed using version 2168 of those rules, with a Yara file of 147 KB size and around 218 rules. By version 5296 used in the Sequoia scan, file size had risen to 947 KB with about 381 rules.
Size of the binary being scanned also affects scan time, although in an unexpected way. A great many of the Yara rules used include upper limits to file size, so those larger than a few MB are subject to few rules, probably intentionally. Thus, larger binary files are likely to complete their XProtect scan in shorter time than expected, and maybe more quickly than smaller binaries.
As a result of these two delays, Gatekeeper’s XProtect results aren’t reported until 0.247 seconds have elapsed since the start, already over 0.05 seconds longer than the whole process in Ventura. However, in this case there’s no mention of provenance tracking, and the blowhole tool is finally run after 0.3 seconds, taking just over 150% of the time in Ventura.
Summary of security checks
Trust evaluation and signature verification, to confirm hashes and CDHashes if not cached;
Gatekeeper scan, including simultaneous ticket check and XProtect malware scan;
CDHash ticket check online using CloudKit with iCloud Ticket Store;
XProtect malware scan against Yara rules;
Gatekeeper evaluation for syspolicyd to allow or not;
Result registered with the kernel;
Command tool run.
Note that there’s no evidence of any OCSP checks being made with the certificate authority to determine whether certificates have been revoked. Additional time will be required if hashes and CDHashes are to be recomputed, and as a result of increased Yara rules.
Appendix: Log Milestones
Times are given in seconds, adjusted to a start of 0.0. The Ventura extract was obtained with log privacy disabled.
Ventura 13.4.1 2023-07-04 14:32:40 on Mac Studio M1 Max
XProtect version 2168, Yara file 147 KB, 218 rules 0.000000 AppleMobileFileIntegrity Checking in with amfid for DER co.eclecticlight.blowhole
0.001395 amfid Entering OSX path for /Users/howardoakley/Documents/blowhole
0.010608 syspolicyd GK process assessment: /Users/howardoakley/Documents/blowhole <-- (/bin/zsh, /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal)
0.022891 syspolicyd GK performScan: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null))
0.023291 syspolicyd looking up ticket: {length = 20, bytes = 0xe0cad936293cea0807ec2e5193bed5f3f02dc019}, 2, 1
0.023316 syspolicyd cloudkit record fetch: https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, 2/2/e0cad936293cea0807ec2e5193bed5f3f02dc019
0.023554 XprotectService Xprotect is performing a direct malware and dylib scan: /Users/howardoakley/Documents/blowhole
0.053971 syspolicyd GK Xprotect results: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null)), {
XProtectMalwareType = 0;
XProtectSignatureVersion = 4321574501753746074;
}, version: 4321574501753746074
0.170283 syspolicyd CKTicketStore network reachability: 1, Wed Jun 21 19:33:35 2023
0.191576 syspolicyd GK scan complete: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null)), 4, 4, 0
0.191797 syspolicyd GK evaluateScanResult: 2, PST: (path: /Users/howardoakley/Documents/blowhole), (team: QWY4LRW926), (id: co.eclecticlight.blowhole), (bundle_id: NOT_A_BUNDLE), 0, 0, 1, 0, 4, 4, 0
0.191996 syspolicyd Putting executable into provenance with metadata: TA(917fa0aed8a1a838, 0)
0.191999 syspolicyd Putting process into provenance tracking with metadata: 1410, TA(917fa0aed8a1a838, 0)
0.192054 syspolicyd GK eval - was allowed: 1, show prompt: 0
0.192090 AppleSystemPolicy evaluation result: 17, allowed, cache, 1688477560
0.195467 blowhole Blowhole snorted!
Sequoia 15.4.1 2025-05-02 20:07:00 on Mac mini M4 Pro
Safe mode is an undervalued tool for dealing with a broad range of problems in macOS. Although not a universal panacea, it has several valuable uses, and can be helpful before having to resort to more time-consuming diagnostic procedures. This article explains how to engage your Mac into Safe mode, what it does, and when you should use it. This is based primarily on macOS Sequoia 15.3.2 running on Apple silicon Macs, but does cover Intel models, and much should apply to recent versions of macOS.
Entering Safe mode
Consider first whether you should disconnect some or all non-essential peripherals. If you’re only intending to use Safe mode to flush caches, or to install an awkward macOS update, that shouldn’t be necessary. When trying to diagnose potential problems with extensions, though, it could be beneficial.
Apple silicon Mac
The Mac must be shut down to begin with. Press its Power button and keep it held in until you see its Recovery options loading. Then select the startup disk you want your Mac to boot from, and hold the Shift key. The button underneath that disk icon will change to read Continue in Safe Mode. Click on that button, and your Mac will restart.
Normally, you’ll be asked to log in twice, and initially, at the upper right of the display, the words Safe Boot will be shown in red.
Intel Mac
All you need do with an Intel Mac is start up (or restart) with the Shift key held down until you see the login window. If you have set a firmware password, you’ll need to remove that in Recovery before trying to start up in Safe mode.
Checking
Once your Mac is running in Safe mode and you’ve logged in, check that it really is in Safe mode by opening System Information. Click on Software at the left, and the line Boot Mode should say Safe rather than Normal.
If you can’t start your Mac up successfully in Safe mode, Recovery is your only option, where you might consider reinstalling macOS.
Leaving Safe mode
To leave Safe mode and return to normal mode, simply restart the Mac.
“Prevents certain software from loading as your Mac starts up. This includes login items and extensions that aren’t required by macOS, and fonts that weren’t installed by macOS.”
“Performs a basic check of your startup disk, similar to the more comprehensive check performed by the First Aid feature of Disk Utility.”
“Clears some system caches, including font caches and the kernel cache. These are automatically created again as needed.”
Apple warns that some macOS features may not work when in Safe mode. Those could affect “video capture, graphics performance, file sharing, Wi-Fi, accessibility, audio devices and devices connected via USB, Thunderbolt or FireWire.” In practice these seem to vary according to Mac and macOS, making it hard to know what to expect. Most USB and Thunderbolt storage should still work normally, and Time Machine backups should continue as usual when running in Safe mode.
Blocking extensions and customisations
Booting in Safe mode blocks the loading of all third-party kernel extensions, and may delay the loading of some of those provided in macOS. Specifically, those in the Auxiliary Kernel Collection (AKC) aren’t loaded, and any devices or features relying on them won’t be available. All kernel extensions in the main Kernel Collection appear to be loaded normally. If you suspect that your Mac’s problems could relate to a third-party kernel extension, this makes Safe mode an excellent diagnostic test without having to alter Startup Security for an Apple silicon Mac.
Apple adds to that login items, system extensions (the modern replacement for kernel extensions), and fonts not installed by macOS. These are other common causes of compatibility problems, adding to the value of Safe mode.
Checking the startup disk
Older versions of macOS performed extensive checks of both disks and snapshots using fsck_apfs. Apple discontinued those some years ago, because they extended Safe boot time to periods sometimes exceeding half an hour. Since then, checks performed by fsck_apfs don’t include snapshots, and are quick checks rather than a full check-and-repair. As they’re performed after the Data volume in the active boot volume group has been mounted, they only cover a limited range of volumes: from the active boot volume group, only the Recovery and Update volumes are checked, together with all accessible external volumes. Results are written to the fsck_apfs logs at /var/log/fsck_apfs.log and /var/log/fsck_apfs_error.log, and in entries in the Unified log.
Those checks in Safe mode currently appear identical to those made during a normal boot. Accordingly, if you want to perform checks on your Mac’s current boot volume group, you should do so using Disk Utility or fsck_apfs in Recovery mode. Safe mode is no longer a useful tool for performing disk checks.
Deleting caches
Discovering exactly which caches are emptied or deleted isn’t straightforward. Beyond Apple’s two instances of font caches and the kernel cache (which only applies to Intel Macs), none of the caches used by Launch Services appear to be affected by this. Neither does this appear to include other notable caches and hidden data stores, such as those for QuickLook or Spotlight.
macOS updates
Although not mentioned by Apple, one longstanding use for Safe mode is to download and install macOS updates. This may have become less used since updating was re-engineered for Big Sur, but is always worth bearing in mind. A short visit to Safe mode, lasting just a couple of minutes before restarting in normal user mode, can also fix problems discovered after updating or upgrading macOS; if a normal restart doesn’t sort them out, try Safe mode before calling Apple Support.
Safe mode in Apple silicon Virtual Machines
Safe mode is available when running lightweight virtualisation of macOS on an Apple silicon Mac, provided that the host operating system is Ventura or later, which provides the option to start the VM in Recovery mode. Enable that option before starting the VM, then use the normal procedure to restart in Safe mode. When you shut down that VM, remember to disable starting in Recovery before running the next VM.
Good reasons for Safe mode
To identify and locate problems with third-party kernel extensions.
To identify and locate problems with third-party system extensions, fonts, login items, and other user customisations, as a quicker alternative to creating a ‘clean’ user account.
To download and install macOS updates, when they don’t work in normal mode.
To fix problems following macOS updates, when a normal restart doesn’t help.
To clear font and other user caches.
When there are problems preventing booting in normal mode, short of going to Recovery mode.
Last week’s security updates to macOS have left some confusion over version numbers, and firmware for T2 Macs. This article attempts to clarify what happened, and where supported versions of macOS are going next.
Security updates 11 March 2025
Apple released:
macOS 15.3.2 Sequoia
Safari for macOS 14.7.4 Sonoma
Safari for macOS 13.7.4 Ventura.
There were no security updates for Sonoma or Ventura other than their Safari updates.
There was also a firmware update included in the 15.3.2 update, changing the version of iBridge firmware in the T2 chip of Intel Macs from 22.16.13051.0.0,0 to 22.16.13060.0.0,0. There were no firmware updates for Apple silicon Macs, nor for Intel models without T2 chips, I understand.
Sequoia
If your Mac is running macOS Sequoia and has been updated, it should now be running 15.3.2 (build 24D81). If it has a T2 chip, it should have updated its firmware to read
EFI 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0)
Safari should be version 18.3.1 (20620.2.4.11.6).
Sonoma
If your Mac is running macOS Sonoma and has been updated, it should still be running 14.7.4 (build 23H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)
Safari should have been updated to version 18.3.1 or 18.4 (19621.1.14.11.3, 19621).
Ventura
If your Mac is running macOS Ventura and has been updated, it should still be running 13.7.4 (build 22H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)
Safari should have been updated to version 18.3.1 or 18.4 (18621.1.14.11.3, 18621).
SilentKnight
To keep a complex situation as simple as possible, SilentKnight only considers one firmware version to be current for each model of Mac. If it tried anything more complex, I’d not be able to cope. As there are presently two different ‘current’ and supported versions of T2 firmware in use, SilentKnight goes with the older one. That way it doesn’t complain, but politely remarks for Sequoia 15.3.2:
EFI version found 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0) ;
expected 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)
Please bear with me until Apple resyncs T2 firmware across the three supported versions of macOS. I’m sure that will return with the release of 15.4, 14.7.5 and 13.7.5. If not, we can all scream together.
Sonoma 14.7.5 and Ventura 13.7.5
Many have been reporting that their Macs have been updated to 14.7.5 or 13.7.5, and some have claimed that those versions have been released by Apple. They are in fact beta-releases of the next scheduled updates to Sonoma and Ventura, and haven’t yet been generally released. If your Mac is running one of those, you might like to check it against recent beta-releases:
21 February 2025 betas: Sonoma 14.7.5 (23H510), Ventura 13.7.5 (22H510)
10 March 2025 betas: Sonoma 14.7.5 (23H520), Ventura 13.7.5 (22H520)
17 March 2025 betas: Sonoma 14.7.5 (23H525), Ventura 13.7.5 (22H525)
App Store full installers
If you download a full installer from the App Store or elsewhere, the current releases are:
Sequoia 15.3.2 (build 24D81)
Sonoma 14.7.4 (build 23H420), which will then need Safari updated
Ventura 13.7.4 (build 22H420), which will then need Safari updated.
How has this happened?
Normally, when the current version of macOS has a security update, the two older versions that are still supported have matching security updates. That would have brought 14.7.5 and 13.7.5 along with 15.3.2. However, in this case the patch to be applied could be supplied in a Safari update for the older two. As that’s much smaller and simpler than a full macOS update, Apple opted to supply those as Safari updates alone, which can’t of course be a new version of macOS.
This is possible because Safari and some of its supporting frameworks and components aren’t part of the Signed System Volume, so updating them doesn’t require the System volume to be rebuilt, turned into a snapshot, and installed as a new Signed System Volume.
However, firmware updates can only be supplied and installed as part of a full macOS update, so it was only possible to update T2 firmware in Sequoia systems being updated the long way to 15.3.2.
I hope this dispels any remaining confusion.
I’m grateful to ExcleX for pointing out that Safari versions can vary according to when you updated.
Login
NYT | Top Stories
