As you will have gathered, I’m unimpressed with the lack of information that Apple has provided about the macOS 11.5.2 update. Last night, almost a week after its release, it got round to posting as much detail as it wants to give us: it “includes bug fixes for your Mac” is apparently all we’re going be told.

Because of the shortage of release notes in recent years, I’ve taken to cruising through macOS updates looking at version and build numbers for many of the most important parts of the system. From those I work out what significant changes there have been. In the case of these “bug fixes” I identified changes in several important frameworks, including some which are widely used by third-party developers, who suffer the same dearth of information as the user.

Of course, this is only part of the story. Many of the most important parts of macOS aren’t contained in neat bundles with Info.plist files, but in Mach-O binaries. Apple has devised a method of incorporating Info.plist data into those binaries, something which third-party developers are now ‘encouraged’ to use to make notarization of command tools easier. But after much searching, I have been unable to find any executable binary in macOS which does that, and almost all of them bear no accessible version information at all.

Now that Apple has changed macOS to running from a sealed system, every single file on the System volume has to have its own hash, which can’t differ across Macs with the same installed version of macOS, or their Seals would differ. This ensures that every copy of 11.5.2 is identical, and that checking the hashes of individual components can be relied upon as a means of determining whether they have been updated.

So far, I have been comparing hashes between 11.5.1 and 11.5.2 across a limited range of directories, but here are the changes in 11.5.2 that this has already revealed:

• in /bin, /sbin and /usr/lib there have been no changes at all;
• in /System/Library/dyld all shared caches apart from aot_shared_cache.t8027 have changed, as would be expected from the changes I have already reported in both public and private frameworks;
• in /usr/bin, /usr/libexec and /usr/sbin most files are unchanged, with the exception of some significant executables.

The executables which have changed are:

• /usr/bin/fileproviderctl which matches the change I reported in the FileProviderDaemon framework;
• /usr/bin/sandbox-exec and /usr/libexec/sandboxd;
• /usr/sbin/spctl, /usr/libexec/syspolicyd and /usr/libexec/endpointsecurityd;
• /usr/libexec/testmanagerd which isn’t documented;
• /usr/sbin/tpctl which “manages trusted peers as part of keychain syncing”.

The problem with comparing hashes is that, unlike version and build numbers, they can’t tell you whether anything significant has changed. Hashes are designed to amplify the smallest of changes: a single bit different and there’s a completely different hash. Only Apple could tell us whether these changes in frameworks, sandboxing, spctl, syspolicyd and tpctl are significant, but the mere fact that these have justified a patch update implies that they’re of importance, and not just crossing the ts.

Some years ago, Apple used to include in its security release notes details of vulnerabilities which its own engineers had discovered, so that those notes gave a fairly complete account of what had changed. It’s some years since I last saw such entries, which either means Apple hasn’t discovered and fixed its own bugs, or it isn’t telling us what it does fix unless the vulnerability was discovered by a third-party, who could disclose details.

I think the evidence points to Apple having made significant security fixes in 11.5.2, as well as fixing bugs across important frameworks. At least we now know where to look. Pass me the Hopper…