Last Week on My Mac: Bugs of wonder

Last week Apple released the second beta of macOS 26.4 to developers, and almost immediately I was receiving reports that SilentKnight crashed on launch in that new beta. Given how unusual that has been in previous versions, I was grateful to hear so quickly, and for so many of you to provide crash reports. As usual they don’t point to anything specific, but led me to wonder whether something might have broken in AppKit in that beta.

But there’s a strange observation reported by SilentKnight’s old predecessor LockRattler, which continues to work normally in 26.4 beta 2: that reports a bizarre iBoot firmware version number from Apple silicon Macs. Instead of a number like 13822.101.2 that I might have expected, LockRattler gives “mBoot-18000.100.10.0.1”, which is random nonsense. Yet it’s listed in a mammoth compilation of iBoot version numbers in the Apple Wiki as an occasional fault.

“mBoot-18000.100.10.0.1” is a problem for SilentKnight, as it tries to make comparisons between firmware version numbers to see whether that installed in your Mac is older or more recent that the version number it expects. If it didn’t do that, every beta-tester would be driven crazy by its persistent reports that their Mac’s firmware is out of date, when in fact it’s that for the next version.

Comparing numbers is of course simple, but I’ve been unable to find anywhere in the API that returns numbers for firmware versions. Wherever they’re available, they’re reported as strings of arbitrary characters, leaving SilentKnight the task of recovering three integers (in the case of iBoot) from what in this case turns out to be rubbish. This is further complicated by the fact that different architectures return strings with different structures: for plain Intel Macs, they should look like “2094.80.5.0.0”, those with T2 chips extend to “2094.80.5.0.0 (23.16.13120.0.0,0)”, and Apple silicon is simpler again with “13822.81.10”. What could have been a simple task is turned into lots of additional code.

It also raises the question of how any beta-release could be put in the hands of external testers when it can’t even report its firmware version correctly. Most of us draw clear distinctions between alpha and beta releases, and this strongly suggests that Apple doesn’t undertake any purposeful alpha testing before release as a beta. Either that or it’s well aware of significant bugs that it doesn’t inform beta-testers about. I fear the answer could be both, and I’m wondering whether trying to make sense of reported firmware versions is too fraught to be reliable.

My main use of SilentKnight here is to check for updates released for the security tools in macOS, primarily XProtect and XProtect Remediator. You may recall that Apple’s last update to XProtect Remediator on 17 February, bringing it to version 157, contained a strange change, which I reported as “the Bastion rules appear to correct a group of typos in the definition for bastion-common-system-binary”.

There were six typos in all, in a definition for bastion-common-system-binary introduced back in version 153 six months ago, on 5 August last year. I shouldn’t need to point out the errors in the original definition:
(define bastion-common-system-binary (require-all (process-attribute is-platform-binary) (require-not (require-any (signing-identifier "com.apple.osascript") (signing-identifier "com.apple.zsh") (signing-identifier "com.apple.bash") (signing-identifier "com.apple.sh") (signing-identifier "com.apple.ksh") (signing-identifier "com.apple.osacompile") (signing-identifier "com.apple.python2") (signing-identifier "python3") (signing-identifier "ccom.apple.pbcopy") (signing-identifier "ccom.apple.pbpaste") (signing-identifier "ccom.apple.cat") (signing-identifier "ccom.apple.curl") (signing-identifier "ccom.apple.dd") (signing-identifier "ccom.apple.cp") (signing-identifier "com.apple.perl")))))
Instead of “ccom.apple.pbcopy”, it should of course have read “com.apple.pbcopy”, and the same for the other five signing-identifiers below that.

I’m delighted that Arnaud Abbati has explained eloquently the consequences of those typos in a wonderful article in his blog. I won’t steal his thunder here, but agree with his conclusion: “Six months of security updates, and nobody noticed. It missed engineering. It missed testing. It missed code review. It missed QA. It missed whatever metrics pipeline is supposed to validate that the rules actually match real binaries.”

There are times when I wonder what really does go on in Apple. When it releases a beta that can’t even tell what its firmware version is, and its security intelligence tool is broken for six months because of obvious typos, it does make you wonder.

4Comments

Add yours

1

EcleX on March 1, 2026 at 8:12 am

Thanks for the interesting article. I know that Apple engineers read this site, so there is hope for improvements in the future…

LikeLiked by 1 person
- 2
  
  hoakley on March 1, 2026 at 10:02 am
  
  Thank you. I’d love to think so.
  Howard.
  
  LikeLike
3

joethewalrus on March 1, 2026 at 9:27 am

Ars Technica published an article in the last 1–2 days on how to downgrade any M4 or earlier Mac from Tahoe to Sequoia, suggesting that consumers who buy a new Mac might want to go ahead and follow that process if they find Tahoe factory installed.

I struggled to find the best adjective, and landed on extraordinary. It is certainly not ordinary that the market for the article exists this late after Tahoe’s release. I can’t recall ever seeing anything like it on Ars. We are all wondering, as you say, what really goes on in Apple these days.

I’ve thought about going the opposite way, putting my MacBook Pro on the beta in hopes of getting ahead of additional fixes (while my Mac Mini still sits happily on Sequoia for the foreseeable future), but based on what you’re describing here, I think I’ll count my blessings with 26.3.

LikeLiked by 1 person
- 4
  
  hoakley on March 1, 2026 at 9:48 am
  
  Thank you – yes, I read Andrew Cunningham’s article. A couple of relevant points:
  
  – Andrew was mainly concerned with Tahoe’s dreadful interface, rather than problems with bugs. Of the two I discuss above, one affected all versions of macOS back to and including Catalina, and the other (I dearly hope) will be fixed before 26.4 is released. I don’t think bugs are a particular problem in Tahoe, at least not compared to its interface.
  
  – he details two main routes, both of which have been covered extensively here in the recent past. One is to install from a bootable installer, the other to perform a Restore in DFU mode. Although the latter requires another Mac, it’s by far the simpler and quicker, and less prone to failure, and the one that I’d prefer.
  
  Andrew researches and tests well, and I commend his articles for those who want to read more widely. Indeed, I value Ars Technica’s coverage of other topics, notably Beth Mole’s health reporting. In these dark days it’s good to rejoice in technical journalism that is both accessible and of highest quality.
  
  Howard.
  
  LikeLike

Share this:

Related