If your Mac is still running Sonoma or Ventura, and you have already updated it to 14.7.1 or 13.7.1, you might have noticed that neither updated Safari, nor has there been a separate update released yet for Safari 18.1.
According to release notes for Safari 18.1 (20619.2.8), this new version has already been released for Sonoma and Ventura, but as of 1600 GMT on 29 October 2024, there’s still no sign of any separate update, nor was it bundled in the x.7.1 updates.
Sonoma and Ventura had Safari 18 released for them on 16 September 2024, concurrently with Sequoia 15.0. On 3 October 2024, at the same time that Apple released Safari 18.0.1 in Sequoia 15.0.1, it also released Safari 18.0.1 for Sonoma and Ventura, without any CVEs being reported as fixed.
Current versions of Safari read:
in Sequoia 15.1 – Safari 18.1 (20619.2.8.11.10)
in Sonoma 14.7.1 – Safari 18.0.1 (19619.1.26.111.11, 19619)
in Ventura 13.7.1 – Safari 18.0.1 (18619.1.26.111.11, 18619)
leaving the latter two due an update to Safari 18.1, which would ordinarily have been released with the x.7.1 macOS updates, but hasn’t been yet.
Update
As of 2150 on 29 October 2024, both Safari updates are now available through Software Update. Version and build numbers are 18.1 (19619.2.8.111.5, 19619) for Sonoma 14.7.1, and 18.1 (18619.2.8.111.5, 18619) for Ventura 13.7.1, and Apple lists the CVEs they address in this note.
Overnight European time, Apple released a small but urgent update to macOS Sequoia, bringing it to version 15.0.1. Although there are no updates to Sonoma or Ventura, there are updated versions of Safari for both.
This Sequoia update is about 1.42 GB for Apple silicon Macs, and around 500 MB for Intel models. It doesn’t bring any firmware updates, but Safari is updated to version 18.0.1 (20619.1.26.31.7). While Apple has released security notes for the concomitant updates for iOS and iPadOS, there are none reported for macOS.
Although Apple remains tight-lipped about exactly what has been fixed in this update, it does admit to fixing a bug in Messages that could crash the app in unusual circumstances, and to improving “compatibility with third-party security software”. It’s assumed the latter refers to the network problems that have been widely reported.
Changes seen in bundled apps include a single build increment in Messages, and Passwords with a new version of 1.0.1. Apart from those and Safari, the only other bundled app to see any change is Photos, with a small build increment. This suggests that there are undisclosed improvements to the new Passwords app.
Significant changes seen in /System/Library include:
Dock, small build increment
CFNetwork and Network frameworks, build increments
My previous explanation of how recent versions of macOS merge their System and Data volumes into what appears to be a single volume, omitted a third component, including Safari. Look in the System/Applications folder where all the bundled apps are stored on the SSV, and there’s no Safari to be seen, yet it appears in the top-level Applications folder. This article explains how that now works using cryptexes, and how they differ between Intel and Apple silicon Macs.
Finding Safari
As the modern boot volume group evolved through Catalina to Big Sur, Safari and its supporting frameworks were stored in the Data volume. That stopped with the arrival of Ventura, and they’re now stored in the third components that complete the modern boot volume group. You can see when files are stored on a different volume using my free app Precize to reveal their full paths. Use that to examine three apps from the merged Applications folder, and you’ll understand what I mean:
Chess.app has a path of /System/Applications/Chess.app demonstrating that it’s one of the apps bundled in the SSV, where almost all of the System folder is stored.
Cirrus.app, like any other app you have installed, has a path of /Applications/Cirrus.app, making it clear that it’s stored on the writable Data volume.
Safari.app has the weird path of /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app that demands further explanation.
Note that the Finder’s Get Info dialogs aren’t as truthful, and don’t tell the full story.
Their volfs paths are also worth noting. On my Intel Mac, they are:
Chess.app is at /.vol/16777240/1152921500311883667; because all macOS 14.6.1 SSVs are identical, your Chess.app should have the same inode number too.
Cirrus.app is at /.vol/16777240/461665725
Safari.app is at /.vol/16777238/993517
The first two follow a familiar pattern you’ll see throughout the System and Data volumes: their volume ID 16777240 is common to both, and that assigned to the merged volumes, but their inode numbers are wildly different. Huge numbers like 1152921500311883667 come from the SSV, while smaller ones like 461665725 are from the Data volume. Then there’s a slightly lower volume ID of 16777238 and a small inode number of 993517 for Safari, demonstrating that it’s somewhere altogether different: that’s a cryptex, a cryptographically protected disk image with an interesting history.
Why a cryptex?
When the modern boot volume group was being designed and developed, it took into account Safari’s special needs by making it the only bundled app to be stored in the Data volume. This enables it to be updated without having to go through the whole process of building a new SSV, allowing Apple to deliver urgent security patches to Safari and its underlying WebKit and other frameworks. There could also have been political considerations in separating Apple’s bundled browser from the other apps included in macOS.
This changed in Ventura in the autumn/fall of 2022, when Apple applied technology it had originally developed for its customised iPhone, the Security Research Device, dubbed the cryptex, a name formed as a portmanteau for CRYPTographically sealed EXtension. This offers two advantages:
Safari, its supporting frameworks, and other components of macOS that Apple prefers not to build into the SSV, can be delivered in cryptexes. As I’ll explain later, this also enables tailoring of macOS to platform.
Some urgent security patches could be delivered in cryptexes, making them faster to release and simpler to install in a Rapid Security Response (RSR).
Since then, RSRs seem to have had their day, and appear to have fallen from favour. But, as a means of delivering Safari and other more changeable components of macOS, cryptexes have proved their worth.
How a cryptex works
Although a cryptex is at heart a read-only disk image that is mounted during the boot process, it has two properties of particular importance:
Its contents are cryptographically verified, in much the same way that the contents of the SSV are, using hashes of its entire contents.
Its internal file system is grafted into the root file system when it’s mounted, rather than being mounted as a separate volume.
Mounting a cryptex starts with validation of the payload and its manifest. It then undergoes a sequence of processes similar to the mounting of an APFS volume, with a checkpoint search to establish stable checkpoint indices, and a check to discover whether there’s anything to recover, which seems unlikely. The graft is then performed in a series of opaque steps, with root hash authentication and validation. The object ID is found, and the graft completed.
Once this has been completed for each of the standard cryptexes and any installed RSRs, the contents of those are effectively part of the system, as a hybrid of the SSV and cryptexes. In the case of the Safari app, this process effectively places it in the main Applications folder, even though the original app is actually located in the System/Applications folder of the App cryptex in /System/Volumes/Preboot/Cryptexes.
As with the current boot System and Data volumes, grafted cryptexes aren’t unmounted or ungrafted until shutdown.
There are currently three main cryptexes in use, App containing Safari, its frameworks and other supporting files, and OS, with a range of other system items including additional frameworks, and several large dyld shared caches. You’ll also see an Incoming cryptex in /System/Volumes/Preboot/Cryptexes. As they’re outside the SSV, new and replacement cryptexes are installed without rebuilding the SSV, and in some cases don’t even need a soft restart of macOS.
Architecture-specific cryptexes
In addition to providing Safari and its related components, cryptexes also provide useful economy in shared caches, and explain why macOS updates for Apple silicon Macs are invariably larger than those for Intel models.
While the contents of the SSV appear to be identical on both Intel and Apple silicon, thus have a single signature, the two architectures differ in their cryptexes. Those for Apple silicon Macs contain dyld shared caches for both architectures, and a set of aot shared caches, presumably to support Rosetta 2, and amounting to 5.24 GB in total size; those for Intel Macs only contain Intel dyld shared caches of 1.68 GB total size.
Given their sizes, that’s a valuable efficiency both for updates and in storage required, and is the major reason for updates for Apple silicon Macs always being larger than those for Intel. Thankfully, because those shared caches are supplied compressed, the difference in update sizes is much smaller than the 3.56 GB difference when they’re decompressed and installed.
Login
