Why won’t Ventura let me install that?

Several users have reported problems installing software that used to install fine in Monterey, but Ventura apparently blocks it. These are commonly Installer packages, often delivered in a Disk Image. While the image mounts fine, all attempts to install from that package fail, with macOS reporting that’s because the software comes from an unidentified developer, so macOS can’t verify that it’s free from malware. This article explains why, and what you can do about it.

Failure

My latest example is smartmontools 7.3, the superb open-source SMART toolkit used by almost every other app that checks the SMART status of disks. Downloaded through its SourceForge site, it arrives as a Disk Image that mounts to provide its Installer package, and that consistently fails to open because of this complaint from macOS.

installpkg1

The greyed text in the third paragraph gives a good clue what’s going on here, as it reads almost identically to descriptions given of apps being run for the first time with their quarantine flag still set: it names the browser that downloaded the Disk Image, and the time and date of download. Those can only have been obtained from one of two places: the quarantine flag itself, or the macOS quarantine database.

Just as you start cursing under your breath and dismiss that alert, up pops another.

installpkg2

This time it rubs salt into the wound by reminding you that macOS blocked the Installer app from doing what it should have done.

Cause

So is this about quarantine flags, and why should that make any difference in Ventura?

Whatever you try to do with that Installer package, macOS simply won’t let you inspect it properly. Copy it from the mounted Disk Image and try to open it using my free extended attribute utility xattred, for instance, and you just get the same alert informing you that it can’t be opened because macOS can’t verify that it’s free from malware.

You can, though, open the Disk Image file with xattred, where you’ll discover a quarantine flag, or extended attribute with the name com.apple.quarantine, and that’s likely to have a value of 0083, which means the flag is still set.

Solution

installpkg3

Now comes the hard bit. You should never remove a quarantine flag from anything whose origin isn’t verifiably trustworthy. Can you be absolutely certain that Disk Image is exactly as its (non-malicious) developer intended? The only way to prove that reliably is by checking the hashes in a signature that can be trusted, and that’s the reason that macOS won’t let you open the package: the developer has failed to provide that assurance.

What you should really do now is contact the developer and inform them of the problem. As they may not even use a Mac, let alone one running Ventura, they may be completely unaware of this.

One potential way ahead is to install the package in a macOS virtual machine (VM). Even VMs are serious about security, and they too block its installation unless you strip the quarantine flag, something readily done in xattred.

installpkg4

With the quarantine flag removed from the Disk Image, the package inside it installs without trouble. So it would if its payload were malicious, and more to the point Gatekeeper’s primary protection has no way to distinguish the benign from malicious, without that crucial signature.

Blamestorming

Some like to ‘blame’ Apple for all this, for making macOS more secure and making it far harder for malicious actors to install malware on our Macs. That’s a truly perverse way of looking at an effective primary security measure to stop malware from being installed in the first place. Sure, some actors work out more devious ways to get malware installed, but Gatekeeper now blocks this direct route and makes life harder for the bad guys.

The effort required of the developer really isn’t that great either. The first time you sign and notarise this type of package, it does take a little while. I do it for no less than six command tools, one of which (silnite) is by far the most popular of all my free software here. This involves signing the command tool itself using a Developer Application certificate, building that into the Installer package just as would normally be done, then signing that with a Developer Installer certificate, and submitting the package to Apple for notarisation. On a good day, the whole process can take less than 15 minutes.

So the next time someone tries to tell you that Apple has made all this ridiculously complicated and wastes their time and money, ask them whether that extra 15 minutes preparation for distribution is worth the added security for their users. If they insist not, you know what they think of those who use their software. Even with free software – arguably especially with free software – developers still have obligations to their users.

Full information for developers is given in two threads written by Quinn “The Eskimo!”, the legend of Apple Developer Technical Support: Creating Distribution-Signed Code for Mac and Packaging Mac Software for Distribution.