With the introduction of notarization requirements in Mojave 10.14.5 and Catalina, you’re more likely than ever to encounter apps which you can’t open. This article looks at how you can try working around these problems, without running malware by mistake.

Kernel and System Extensions

Kernel extensions (KEXTs) and their successors System Extensions in Catalina are required not just to be signed using special certificates provided for the purpose, but are also required to be notarized. If you try to install a product which requires such an extension and the installation process fails, the only fallback is to restart in Recovery mode and try adding the extension manually, as described here.

If that doesn’t work, you need to contact the supplier’s support desk.

Apps

There are now many reasons that macOS may refuse to open an app normally, ranging from damage to the executable code within it, to it not being notarized when macOS was expecting it to be. The best clues come from how macOS refuses.

If the app is crashed when it tries to launch, typically showing a Problem Report for the app, click on the Show Details button and look down for the Exception Type given. This might, for example, read
EXC_CRASH (Code Signature Invalid)
and a little further down the Termination Reason might be given as
Namespace CODESIGNING, Code 0x1
Those are typical for an app which no longer matches its own signature.

Similar crashes can occur when an app tries to access privacy-protected resources for which it doesn’t have appropriate settings.

These crash-on-launch events indicate a problem which you can’t do anything about. Try downloading another copy of the app, and if that fails similarly, contact the developer as they have a problem which they need to fix as a matter of urgency.

Apps which are terminated with an informative alert rather than a crash may be more amenable to a different approach, according to the information that you’re given by that alert. Two things to try are liberalising the setting in the General tab of the Security & Privacy pane if it’s currently set to App Store apps only, and selecting the app in the Finder and using the Open command in its contextual menu instead of double-clicking it.

Command tools and other executable code

Catalina introduces full first-run checks including XProtect scans on command tools and other executable code which hasn’t normally been checked in Mojave and earlier. This means that broken signatures and other problems can be expected when trying to run some command tools, although unsigned executable code should still run normally. If there’s an unsigned version, or you can build one locally, you might have more success with that.

At present, it’s not clear what else you can try to manage problems with command tools which won’t run properly in Catalina. I will update this article with further information as this becomes clearer.

Running from the same path

In Mojave at least, security checks on apps which are launched from a known path are significantly less than when an app is launched from a folder or path from which it has never been run before. If you’re updating an existing app, try replacing the old version with the new, instead of running the new from a different location. It may also help to remove any quarantine flags, although that is a more serious undertaking.

Removing quarantine flags

One general way of reducing the depth of checking which takes place when running executable code for the first time is to remove any quarantine flag which has been attached to it (or to download it using a tool like curl which doesn’t attach the flag in the first place). This is potentially extremely dangerous, as it attempts to bypass built-in security protection such as XProtect and deep signature checks which are part of the ‘Gatekeeper’ system. Before even contemplating trying it, you must therefore be absolutely certain that you’re not dealing with malicious software, or anything which could harm your Mac in any way.

If you’re going to do this, for example to an app delivered in a Zip archive, remove the quarantine flag from the archive before expanding it. Quarantine flags normally propagate into all the files within an expanded app, making them harder to remove. Remove the one flag on the Zip archive first, and then decompress it.

To remove a quarantine flag using my free app xattred, simply open the archive file, select the com.apple.quarantine extended attribute in the centre listing of xattrs, and click on Cut.

When you do expand the contents, check them carefully using an up-to-date and effective malware scanner before going any further.

In case you’re ever tempted, don’t try removing signatures, or setting your Mac’s system clock back to an earlier date before current security rules came into force. Tampering with the contents of an app is almost certainly doomed to fail, because signatures are now so deeply embedded within them that all you’re likely to do is break the app completely so that it is crashed when you try to open it. System clock tricks can’t overcome precise times which are embedded in signatures prior to notarization either.

If you have a tip which can – without compromising security – allow a user to open an app which macOS has taken a disliking to, please share it in the comments. There’s only one rule, though: turning off SIP and other major protection systems isn’t allowed, as that’s a serious undertaking even for desperate circumstances.