Suspicious Package

Frequently Asked Questions

Installing Suspicious Package

What versions of macOS does Suspicious Package support?

Suspicious Package supports:

If you're using an older version of macOS, you can download an old version of Suspicious Package as follows:

Note that prior to version 3, Suspicious Package was only a standalone Quick Look plug-in (there was no app).

We make these older versions available for those who need them, but we have not tested them since they were current, and can't make any claims about how well they might work.

Ensuring that Suspicious Package works properly on even a single version of macOS takes a great deal of work, especially for our one-person company. Since we are not willing to claim support for a macOS version that we have not tested, and since Apple releases a new macOS version every year, we must periodically drop support for older versions.

Why don't I get the Suspicious Package preview in Quick Look?

Generally, macOS automatically enables the Quick Look extension provided by Suspicious Package. However, if you're getting only the standard macOS Quick Look for an installer package, you may need to explicitly enable the extension.

Open System Preferences, and go to Extensions > Quick Look. You should see a checkbox here for Suspicious Package; make sure that it is checked. (If you don't see the checkbox at all, make sure that you have already dragged Suspicious Package to your Applications folder and have opened it from there at least once: this gives macOS a chance to run Gatekeeper on the app before allowing the extensions that it provides.)

What happened to the file and script details in the Quick Look preview?

Until version 3.6, Suspicious Package provided a Quick Look generator plug-in, which is the API that macOS has used since Mac OS X 10.5 (Leopard). But in macOS 10.15 (Catalina), Apple introduced a new API for third-party Quick Look previews, known as Quick Look preview extensions, and have “deprecated” the old generator API.

We held out on adopting the new Quick Look API for a while, but even in Catalina, the old generator API was becoming less capable — for example, we lost the ability to link from the preview back to the app. So we finally decided to take the plunge, even though this meant essentially re-writing our Quick Look support. But we also decided to re-think what works well from Quick Look and what doesn't. (Our original Quick Look plug-in pre-dated the app by several years, but our Quick Look support today doesn't need to stand on its own.) In particular, any non-trivial interaction within the Quick Look UI has always been iffy, and has only gotten more so over the years.

Hence, we decided to simplify the Quick Look preview to be a variation on the app's Package Info tab, with links back into the app. This was still more work than we would've liked to re-invest in Quick Look support, but we hope that it provides some sort of utility.

If you're still using macOS 10.14 (Mojave), the old Quick Look generator plug-in is still there, and should work the same as before. This is because Mojave doesn't recognize the new Quick Look preview extension at all. (The documentation for that old Quick Look preview is still available here.)

Even on Catalina, if you turn off the Suspicious Package extension in System Preferences > Extensions > Quick Look, the old plug-in ought to take over again. But be aware that we are no longer testing it in this context!

Note that this trick does not work on Big Sur, since the old plug-in doesn't seem to get used, or perhaps it is failing for some reason. We haven't tried to debug it, and don't intend to.

Does Suspicious Package automatically check for updates?

Yes, once every 2 weeks — or less, if you use it less often — Suspicious Package will download a small file from our website to get the current version number. If a newer version is available, you'll see an Update Available button under the app's toolbar (on macOS 10.15 or earlier, it'll be on the right side of the title bar): available update indication

Click on Update Available to open the Suspicious Package download page, where you can get the latest version.

If you want to change the frequency with which Suspicious Package checks for updates, or turn off automatic checking entirely, use Suspicious Package > Preferences > Update: update pref pane

Suspicious Package never automatically downloads or installs the actual updated app. You make the decision about when or if to download it, and where and how to install it.

Does Suspicious Package support languages other than English?

We speak only English, unfortunately, and our zero-revenue model makes it difficult to justify paying for a company to localize the app. Especially since Suspicious Package has a lot of complex strings to explain different parts of the package and identify potential issues in the review.

However, as of version 3.6, Suspicious Package is localized for French — thanks to the hard work of Olivier Prompt, who generously volunteered to translate the hundreds of strings required to make this a reality!

If you have any feedback on the localization — or if you are interested in discussing localization for another language — please contact us.

Why does Little Snitch tell me that com.mothersruin.XPCService.UpdateChecker.xpc wants to make a connection?

If you use Objective Development's Little Snitch, you may encounter a connection alert that tells you that “com.mothersruin.XPCService.UpdateChecker.xpc wants to connect to” This is triggered by Suspicious Package's automatic check for updates.

If you deny the connection, Suspicious Package won't be able to check for updates, and won't notify you when one is available. If you don't want it to attempt this connection in the first place, you can also turn off automatic checking using Suspicious Package > Preferences > Update.

Starting with version 3.4.1, Suspicious Package includes an Internet Access Policy, so that the purpose of this connection will be correctly explained in Little Snitch's Research Assistant view.

Understanding Suspicious Package

Will Suspicious Package protect my computer from malware?

No. The purpose of Suspicious Package is to provide visibility into macOS Installer packages, such that you can see what files they will install and what scripts they will run. You can certainly use those capabilities to evaluate the safety of a given package, but Suspicious Package can't make that determination for you.

Automatically defending your computer against malware is a huge problem that even Apple — with control of the OS, plus the resources of the most valuable company on the planet — struggles to solve. No independent developer is going to be able to solve that problem — especially not one that gives away their product for nothing!

But if Suspicious Package “didn't find any issues for review,” is the package safe to install?

No. Although the Suspicious Package app examines the package for a number of potential issues, it doesn't know how to determine if the package is truly safe to install. The review is intended only to highlight things that might be of interest in your determination of safety. Finding “no issues for review” only means that none of the things that Suspicious Package looks for are present — that doesn't mean that there aren't other issues.

There is, unfortunately, no substitute for the hard work of evaluating the contents and scripts in the package, and vetting the package signature. (If that could all be done algorithmically, Apple would presumably have macOS do it directly, and none of this would be necessary!)

Why can't I just use “Show Package Contents” from the Finder?

You can, but you'll get little to no information about what will be installed.

That's because Show Package Contents in the Finder's context menu actually refers to a different sort of package. macOS also uses the term “package” to refer to a folder that appears to be a file in the Finder. (A developer might call this a bundle, but a package is actually a more generic thing than a bundle, since a bundle implies a specific internal structure, such as an Info.plist file and a Resources directory.) The Finder's Show Package Contents command simply opens the folder in the Finder, instead of opening the application associated with the package.

A modern (“flat”) installer package is not a folder, so you won't even see this Finder command.

On an older (“bundle-style”) installer package, the Finder will offer to Show Package Contents, but that will only show the internal structure of the installer package, which isn't the same as seeing what the package will install. For example, you'll see an Archive.pax.gz file, but that would need to be further unpacked to get at the actual files that would be installed.

For bundle-style packages, Show Package Contents is occasionally useful for finding scripts and executables referenced by install scripts: see more details.

Why can't I just use “Show Files” from the macOS Installer?

Yes, you can open the package in the macOS Installer, and choose File > Show Files, which will show you the path of each file to be installed.

That's fine as far as it goes, but there is more involved in many installer packages — most significantly, installer scripts that might do anything — and Suspicious Package gives you visibility into all of it. Suspicious Package also provides more ways to examine the installed files, with Finder-like navigation, detailed metadata, sophisticated searching and filtering, tabbed browsing, and the ability to open or export individual files.

That said, if you opt to rely on the macOS Installer's “Show Files” feature, be aware that a package might run code as soon as it is opened by the Installer, via the capability or from an installer plug-in. The good news is that the macOS Installer prompts you before allowing this code to run; the bad news is that File > Show Files is not available until you've clicked through that prompt!

Is Suspicious Package “sandboxed”? Does it have entitlements?

No, the current version of the Suspicious Package app does not opt into the macOS App Sandbox mechanism.

We've attempted to sandbox Suspicious Package in the past, but there are restrictions that would reduce the usability of the app — including features in the Welcome to Suspicious Package window, and support for packages that reference external component packages. We might someday overcome these sandboxing obstacles, but it isn't at the top of our priority list, and we aren't eager to remove capabilities from the app to make it possible.

That said, although the app itself isn't sandboxed, there are a couple of components within Suspicious Package that are sandboxed, and which have explicit entitlements — as can be seen by using an app like our own Apparency. These are described below.

The SuspiciousPackagePreviewExtension.appex component provides the Quick Look Preview to the Finder — on macOS 10.15 (Catalina) and later — and has the following entitlements:

Entitlements for the SuspiciousPackagePreviewExtension.appex component
Entitlement KeyValueReason YES This allows the Quick Look extension to see the package to preview. This allows the Quick Look extension to talk to the /usr/libexec/syspolicyd daemon, which is required to successfully check a package's notarization status. (Suspicious Package uses the spctl(8) command to check for notarization, but when that tool is called by a sandboxed process, it inherits the sandbox and will fail without this entitlement.) com.mothersruin.SuspiciousPackage This allows the Quick Look extension to see the preferences for the Suspicious Package app, so that user settings — such as showing of the Distribution file — are properly represented in the preview. /private/var/db/receipts/ This allows the Quick Look extension to detect any previous installation of the package.
On macOS 11 (Big Sur), these allow the Quick Look extension to run the macOS commands that process pieces of the package and check notarization. The sandboxing of Quick Look Preview extensions on Big Sur is such that, by default, these standard commands can neither be read nor launched. (allow process-fork)
(allow lsopen) On macOS 11 (Big Sur), this allows the Open With Suspicious Package button to work. That button does the equivalent of opening a custom URL, which is handled by the Suspicious Package app. The sandboxing of Quick Look Preview extensions on Big Sur is such that, by default, this operation — opening a URL via LaunchServices — is not allowed.
(allow file-read* (subpath "/private/var/db/mds") (literal "/private/var/db/DetachedSignatures"))
(allow ipc-posix-shm-read* ipc-posix-shm-write-create ipc-posix-shm-write-data (ipc-posix-name ""))
On macOS 11 (Big Sur), this allows the Quick Look extension to check the trust of certificates used to sign Apple's packages. (Suspicious Package uses the macOS Security.framework APIs to evaluate certificates, but that framework's sandbox configuration isn't complete.)

Also, under the MRSFoundation.framework component, you'll find a com.mothersruin.MRSFoundation.UpdateCheckingService.xpc XPC service. This is the component that performs the periodic check for updates, and is entitled as follows:

Entitlements for the com.mothersruin.MRSFoundation.UpdateCheckingService.xpc component
Entitlement KeyValueReason YES This allows the XPC service to make an outgoing network connection, in order to fetch this file, which contains the information about the current version of Suspicious Package available for download.

Why isn't Suspicious Package distributed through the Mac App Store?

The primary reason is that it isn't sandboxed, which is a requirement for the App Store.

A secondary reason is that we highly suspect that Apple's App Review would — sooner or later — declare that our tongue-in-cheek app name was a problem, and we're not interested in changing that now.

Unfortunately, the value added by the App Store, especially for a free app, is too small to be worth the cost to us.

Why isn't Suspicious Package open-source?

Frankly, because we are obsessive software engineers who like our code to be as polished as our products, and we are not eager to give up that level of control.

We appreciate that, when you work with other people in a real company, working as a team is what you get paid for. But when you develop and publish software for free, you require some other reward, and for us, that's a measure of control.

Using Suspicious Package

How does Suspicious Package decide what packages to show in the welcome window?

The “Welcome to Suspicious Package” window attempts to show the macOS installer packages that you are likely to be interested in inspecting. It does this by asking Spotlight to find the installer packages under your home folder, preferring those inside Downloads and Desktop, as well as the ones that were more recently downloaded.

In addition, since installer packages are commonly delivered inside disk image (.dmg) files, Suspicious Package also looks for packages inside any opened disk images. It examines only the top level of any mounted disk image, and prefers disk images that were more recently opened. Note that it won't show packages inside of disk images that aren't open: you need to open them from the Finder (as described below).

Note that the welcome window is not a “recents” list. If you want to choose from the packages that were recently opened in Suspicious Package, use any of the standard macOS mechanisms, such as File > Open Recent, or the menu from the Dock icon.

If you find the welcome window annoying, uncheck “Show this window when Suspicious Package opens” and it won't be shown automatically in the future. You can always use Help > Welcome to Suspicious Package... to summon it manually.

Why doesn't the package I just downloaded show up in the welcome window?

Starting in macOS 10.15 (Catalina), an app can't access your Downloads, Desktop or Documents folder until you give it explicit permission to do so. (If you've spent any time on Catalina, you've no doubt seen many such “X would like to access files in your Desktop folder” alerts already.)

However, when Suspicious Package asks Spotlight to find the packages it should show in the “ Welcome to Suspicious Package” window, macOS doesn't even ask for permission. Instead, it simply doesn't tell Suspicious Package about packages that might exist in those protected folders.

Starting in version 3.5.2, the welcome window warns that “some installer packages may be missing, due to macOS Folder Privacy Settings.” If you click Fix, Suspicious Package will let you choose which of these folders you would like to search, and will nudge macOS to ask for permission. If you don't want Suspicious Package to have access to any of these folders, you can click Ignore to get rid of the warning.

You can always get back to this dialog by choosing Suspicious Package > Review macOS Folder Privacy.... However, once you've explicitly denied access to Suspicious Package, the app can't resolve the problem, even by asking again. You must open System Preferences, go to Security & Privacy > Privacy > Files and Folders, and change the per-folder checkboxes for Suspicious Package.

After allowing access to Suspicious Package, you might need to quit and re-open the app to see the welcome window change. Or, you might not. Apple has documented about 10% of the new access control mechanisms that they added in Catalina, so we don't even know how they intended this to work. So we've given up: if it does something sensible for you, that's great. If not, there's nothing that we can suggest, and we quite frankly no longer care. ¯\_(ツ)_/¯

Why won't Suspicious Package open this disk image (dmg) file?

Suspicious Package is specifically designed to open installer packages. standard macOS installer package icon An installer package usually has an “open box” icon that looks like the one at right, and will normally open in the standard macOS Installer application. (If you look at the extension of an installer package, it will be either be .pkg or .mpkg.)

Although a disk image (.dmg) file might contain an installer package inside it, you still must open the disk image first, i.e. by double-clicking it in the Finder. Then, you can ask Suspicious Package to open the installer package inside — if the welcome window is showing, any package inside the just-opened disk image will appear there automatically.

In any case, Suspicious Package does not know anything about disk images, and so can't open them directly.

Note that there are many ways to distribute macOS software. Disk images are common downloads, but they do not always contain installer packages. If you open a disk image and don't see a package, or if Suspicious Package won't open whatever is inside, it is almost certainly not an installer package. It might be the actual app of interest, or it might be some custom app that performs an install. Either way, Suspicious Package can't provide any information on what the contained software might do.

Can Suspicious Package open the special InstallESD.dmg file?

The “Install macOS” app — which starts an upgrade to a new macOS version — contains an odd duck called InstallESD.dmg. If you don't know what this is, consider yourself lucky and move on. If you do know what this and you want to use Suspicious Package to look at it, read on.

Because InstallESD.dmg is both a disk image and an installer package, it is the only exception to the Suspicious Package can't open disk images rule. Suspicious Package has always been able to open it, but you had to change the file extension from .dmg to .pkg first to make it work.

Starting with version 3.4, though, you can now open InstallESD.dmg without renaming it. The trick is to drag the file from the Finder and drop it onto the Suspicious Package icon (e.g. in the Dock), while holding down both the Command and Option keys. This key combination forces macOS to ask Suspicious Package to open this file, even though it doesn't generally support opening disk images. As long as it is one of these special disk images, it will open normally. (If you get a dialog saying that “Suspicious Package cannot open files in the ‘Disk Image’ format,” that means that Suspicious Package examined the actual file and found that it isn't really any sort of package.)

Alternatively, you can drag the InstallESD.dmg and drop it onto Suspicious Package's welcome window (no modifier keys required), or use the “spkg” command line tool to open it from the Terminal.

Why does Suspicious Package ask to access my Downloads, Desktop or Documents folders?

Starting in macOS 10.15 (Catalina), an app can't access your Downloads, Desktop or Documents folder until you give it explicit permission to do so. (If you've spent any time on Catalina, you've no doubt seen many such “X would like to access files in your Desktop folder” alerts already.)

Generally, Suspicious Package reads only those macOS Installer packages (or installer receipts) that you directly ask it to open. But there are a couple of reasons that it might also ask for general access to these protected folders. One is for the “Welcome to Suspicious Package” window, as described above.

Additionally, for the File > Export Item to Default Folder (Cmd-Option-E) command, Suspicious Package has a default export location. The first time that you use this command on Catalina, macOS may ask for permission to access that folder. (Or, it might not, especially if you used Suspicious Package > Preferences to choose a default export folder after upgrading to Catalina — the macOS standard open dialog interprets selection of a file or folder as indicating “user intent” to grant the app access to that item.)

Suspicious Package should behave properly if you tell macOS to Allow this access. If you choose Don't Allow instead, the export may not work properly, but the other functionality of Suspicious Package should be unaffected.

Note that macOS will only ask once for a given folder and app. If you want to change these permissions at a later time, you must open System Preferences, and go to Security & Privacy > Privacy > Files and Folders. There should be a group of checkboxes for every app, where you can enable or disable access for the folders that macOS considers to be privacy-sensitive. (If a folder isn't listed here, it is either not one that is specially protected by macOS, or not one that the app has previously requested to access on Catalina.)

What do the different “package formats” indicate?

On the Package Info tab, directly under the package name, Suspicious Package summarizes the package, as something like Developer ID Software • Distribution Archive.

The first part describes where the package came from. This is derived from the package signature, and gives you a quick way to see if the package contains Apple software, came from the App Store, or from a third-party developer.

The second part is the “package format,” which describes how the package was built. Although every installer package looks the same — and usually even has the same .pkg extension — there are actually many different package formats supported by macOS. If you simply double-click the package to open it in the macOS Installer, the format is probably uninteresting. But if you are an administrator using any sort of automated deployment mechanism, you may need this detail, since different deployment schemes have different requirements.

We are not Mac admins ourselves, so are being purposely vague about the specifics of deployment. For a good introduction to the different package formats and the implications for deployment, check out Armin Briegel's talk The Encylopaedia of Packages from MacDevOpsYVR 2021.

Unfortunately, there isn't much standardization on what to call the different package formats — Apple presents them all as simply “installer packages” and doesn't offer any distinction. So we've tried to name them based on available clues, some community practice, and our own personal experience working on the things. So that you know what we mean by something like Distribution Archive, the table below gives more background on each of the possible formats:

Package FormatDescription
Distribution Archive A distribution archive (sometimes also called a distribution package) combines one or more component packages with a Distribution file in a single flat file, using the xar archive format. A distribution archive can also be signed.

Because it is self-contained, a distribution archive doesn't require a disk image for delivery, although one might be used anyway — perhaps to include documentation or fancy backgroud images.

The distribution archive is probably the most common format these days.

Product Archive A product archive is a distribution archive in which the Distribution file declares a product identifier and version. The productbuild(1) man page terms this a product archive. (Note that, if you use productbuild to create a product archive, the ‑‑identifier and ‑‑version options are generally required, unless a hand-written Distribution file is given with the ‑‑distribution option.)

A product archive is required for submission to the App Store (and is also distributed by the App Store, after having been re-signed by Apple). A product archive is also required by the ‑‑installpackage option of the startosinstall command (bundled in the “Install macOS” app).

Distribution Archive with External Components Although a distribution archive usually carries its component packages in the same xar archive file, it is possible for the Distribution file to reference component packages in other places (such as in a sibling folder). This format is uncommon, although Apple still uses it occasionally.

By its very nature, this package format is not self-contained, and thus will usually be delivered inside a disk image or other container.

Component Package Although a component package is typically only a building block for the distributed installer package, it might also be distributed by itself. A stand-alone component package will behave like most other packages when opened in the macOS Installer.

The traditional macOS Software Update mechanism also uses stand-alone component packages. (In Software Update, the Distribution files are evaluated first, to determine which updates are applicable, so these must be downloaded separately from the component packages they reference.)

A stand-alone component package is also a flat file — using the xar archive format — and is also typically signed.

Distribution Metapackage (Bundle) Prior to the Mac OS X 10.5 (Leopard), the distribution metapackage served the same purpose as today's distribution archive. It is a bundle-style package that combines combines one or more component packages with a Distribution file. The component packages might be inside or outside of the metapackage bundle.

Since a bundle-style package is a directory, rather than a flat file, it typically requires a disk image or other container for delivery. Also note that bundle-style packages can not be signed.

Historically, distribution metapackages used a distinct .mpkg extension, but these days, it doesn't really matter.

Component Package (Bundle) As with flat packages, stand-alone bundle-style component packages are also possible.

As with distribution metapackages, this format generally requires a disk image or other container, and likewise can not be signed.

Info.plist Metapackage (Bundle) Prior to the introduction of the Distribution file in Mac OS X 10.4 (Tiger), metapackages were possible, but used an Info.plist to reference the component packages. We really hope that no one is making these any more, but some people like to party like it's 2006.

What is a “component package”?

Installer packages are often constructed of multiple sub-packages: these are called component packages by the macOS Installer, and by Suspicious Package.

This separation of content into component packages is generally not very interesting — unless you are the person developing the package — so Suspicious Package mostly tries to hide it. For example, the All Files tab always shows everything that would be installed by all of the component packages. However, it is sometimes difficult to ignore the existence of component packages — such as with scripts and receipts.

Also note that when you install the top-level package, all of the component packages might not be installed. The package's Distribution file might allow specific component packages to be turned on or off through the macOS Installer's Customize dialog. Or the distribution might automatically turn component packages on or off, based on the version of macOS, the other software you have installed, or even the hardware capabilities of your Mac.

You can get more information about which files are installed by which component package by turning on additional component package info. You can also use the rule-based search feature on the All Files tab to filter files by their component package.

What is the difference between a “flat” and “bundle-style” package? What is a xar archive?

In the beginning, a macOS installer package was a bundle — a directory containing specific files for the various pieces of the package. For example, there would be an Info.plist with the package metadata, an with the file listing and an Archive.pax.gz with the actual payload. (This style of package dates back, in one form or another, all the way to NeXTSTEP days.) Because a bundle-style package is a directory, it must be put into some other container — like a disk image — to be easily downloadable. There is no provision for signing a bundle-style package, so the origin and integrity can't be verified.

In Mac OS X 10.5 (Leopard), Apple introduced a new style of macOS installer package, often referred to as “flat packages.” This style of package is a file, rather than a directory, and can be easily downloaded, even if not wrapped in a disk image. The pieces of the package — including the metadata, the file listing, the payload archive, and the scripts — are archived using the xar archive format.

The xar archive format was developed at Apple, and originally open-sourced as part of the OpenDarwin project. Xar was designed to be a generalized archive format, but for macOS installer packages, probably its most important feature is the ability to sign the archive. The xar signature is what allows macOS (and Suspicious Package) to evaluate the trustworthiness of a package, and to verify that the contents have not been tampered with since being signed.

The subsequent security features and requirements of macOS installer packages are built upon the signing and verification aspects of xar-format flat packages. These include Gatekeeper's Developer ID requirements [added in Mac OS X 10.7 (Lion)] and notarization requirements [added in macOS 10.14 (Mojave)].

The macOS Installer still supports installing bundle-style packages, but because they can't be vetted through Gatekeeper, you probably won't encounter them often. However, the relative simplicity of their construction apparently makes them irresistible to some vendors.

For many years, the canonical open-source repository for the xar archive project was at Google Code. With the demise of Google Code, the closest thing to a canonical replacement — at least as far as Apple platforms are concerned — is the Apple Open Source site, but that gives you only source code dumps, without any documentation or community. There are many forks on GitHub, but we don't know if Apple pushes their changes to any of them (we rather doubt it).

How can I tell which files a “Custom Install” will install?

As noted above, the macOS Installer's Customize dialog may allow specific component packages to be turned on or off. Unfortunately, Suspicious Package doesn't have the smarts to figure out which component packages will actually be installed, and merely assumes that they all would be. For the purpose of evaluating what a package might do to your system, this is usually enough.

If you want more information about what files are installed by which component package, you can turn on Component package and bundle info (as described here). You can also use the rule-based search feature on the All Files tab to filter files by their component package.

If you need to examine component packages in more detail than that, Suspicious Package is probably not the best tool to use.

What is a “receipt” and what will I find if I open it?

Each time that the macOS Installer installs a package, it creates a “receipt” that contains some information about what was installed. Most significantly, the receipt includes the file listing from the package, which is the primary source of information for Suspicious Package's All Files tab. (The receipt does not contain the scripts from the package, nor the actual installed files, of course.)

Suspicious Package can open and inspect a receipt, in much the same way as a package. Because a receipt contains less information than the package it came from, you're always better off examining the original package, but sometimes you might only have the receipt available. But the first challenge is to find the receipt.

The macOS Installer creates receipts in the (normally hidden) /var/db/receipts folder. To open this folder, you can use Go > Go to Folder (Shift-Command-G) from the Finder. Apps that you install (or update) from the App Store will also have receipts created in this folder. Note that receipt names are generally in “reverse DNS” form, so you might need to use the Finder's File > Find (Command-F) feature to find the receipt you want within this folder.

Updates to macOS itself (installed from the Updates page of the App Store) also create receipts, but in a different folder: these go into /System/Library/Receipts, which is at least not hidden.

Either way, a receipt has a .bom extension, and a Kind description of “Installer receipt.” You can open this file with Suspicious Package in the same way that you would open a package, such as by dragging it to the app icon, or control-clicking in the Finder and choosing Open With > Suspicious Package.

You will usually find a second file with the same name as the receipt, but with a .plist extension instead of .bom. This property list file carries some additional information about the installation (such as the date), and Suspicious Package will automatically read and show this information. However, Suspicious Package will recognize only the .bom file as the receipt, so don't try to open the .plist file in Suspicious Package (it won't work).

Why does Suspicious Package show the wrong icon for this file or application?

Suspicious Package actually has no idea what icon an item will have after being installed. (It would have to essentially do the install in order to determine this reliably.) Instead, Suspicious Package shows a generic icon, determined from metadata about the item, such as its name, extension, location and permissions. This is why you'll see only generic application icons, for example. These icons are intended only to give you helpful visual clues as you scan the file view.

Why doesn't Suspicious Package show the indirect scripts for certain packages?

Suspicious Package shows all scripts for a modern xar-format flat installer package. Presumably, indirect scripts are there for a reason, and if Suspicious Package didn't show them, you'd have to unarchive the package yourself to see them.

Older bundle-style packages can also have indirect scripts. But in this case, the scripts are visible within the bundle, if you open the package using the Finder's Show Package Contents command (see above). Suspicious Package shows only the top-level (preinstall and postinstall) scripts in this case, rather than trying to show the entire contents of the package, and doing so less effectively than the Finder.

What is a “Distribution” file and should I inspect it?

Most modern installer packages have a “Distribution” file. This is an XML-format file, with (typically) a smattering of embedded JavaScript code. The macOS Installer reads the distribution when it opens the package, and uses the information in this file to decide how and if the package should be installed.

For example, the distribution might declare which macOS version and/or Macintosh hardware is required for the installed software. It defines any special UI that the Installer displays, such as a software license agreement. It determines what choices the user can make on the Customize dialog, and how those customizations change which component packages will be installed. It can even automatically change which component packages will be installed, based on which macOS version — or other software — is already installed.

The good news is that even the JavaScript code within the distribution is limited in what it can do: although it can read files in your home folder and elsewhere, it can't write any files, and it can't make any Internet connections. (In this way, it is much more limited than the typical JavaScript you'd find on the web. The distribution uses the JavaScript language only, and that JavaScript can use only what the macOS Installer exposes to it — namely, functionality designed to determine the capabilities of the hardware and the presence of previously-installed software.)

The bad news is that there's an exception: a way for the distribution to run arbitrary commands, through a JavaScript method called [or its relative, system.runOnce()]. If a distribution declares its intention to use this exception, Suspicious Package will flag this as a potential issue: Run-on-Open issue

The same scenario will cause the macOS Installer to present a warning dialog when it opens the package, saying that “This package will run a program to determine if the software can be installed.”

If you click the Show Scripts That Run on Open button, Suspicious Package will show you the scripts within the package that might be run by However, the distribution may also run system commands with this mechanism, so in order to completely understand what it does, you really need to read the Distribution file.

Which brings us to the other bad news: the Distribution file is an arcane, Apple-defined format that is not easy to interpret. The Distribution XML Reference provides some reference information, but if you've never looked at a distribution file before, it probably won't help much. Even those of us that have been staring at these things for years are no experts!

All of this is why Suspicious Package does not show you the Distribution file by default. Given the challenges of making heads or tails of it, you're probably better off focusing on other evidence of trustworthiness, such as the identity of the distributor. But if you want to see the Distribution file in all its glory, you can go to Suspicious Package > Preferences > General and check Show Distribution file on All Scripts tab.

What is a “PackageInfo” file and why would I want to see it?

Within a modern installer package, each component package has a “PackageInfo” file that contains most of the metadata for that component. This XML-format file includes information such as the top-level scripts that should be run, what bundles are installed and how, and other attributes — including the component package identifier and version, and any special install path information.

Suspicious Package always reads the PackageInfo files, and attempts to present that information in a more useful way, e.g. incorporating install paths into the All Files view, and showing bundle version strings in the info pane. Optionally, the info pane will also show the special installer rules that apply to a bundle, and the component package identifier to which a specific file or folder belongs.

For this reason, Suspicious Package does not show you the PackageInfo file by default. Apple doesn't provide any documentation of the PackageInfo format, and some of it is quite arcane. So if you can avoid looking at it, all the better.

However, if you want to see the PackageInfo file anyway — perhaps because you are authoring a package, or dealing with a package that is behaving badly — you can go to Suspicious Package > Preferences > General and check Show PackageInfo files on All Scripts tab.

How should I evaluate scripts that run when the macOS Installer opens?

As noted above, a script that runs when the macOS Installer opens is an artifact of the Distribution file's capability. Suspicious Package will always show such scripts that are bundled with the package itself: these appear under the Installer Package heading in the scripts browser. But as described above, the distribution can also run system commands, and the only way to determine that is by inspecting the Distribution file itself.

With that proviso, the important things to know about scripts that run when the macOS Installer opens are:

How should I evaluate a package that contains plug-in code for the macOS Installer?

Run-on-Open issue

The macOS Installer provides a plug-in mechanism by which a package can add UI to the installer: this normally takes the form of additional steps, such as entering registration or licensing information, or performing some sort of post-install cleanup or update checking.

However, this mechanism results in code provided by the package being run by the macOS Installer, upon opening of the package. As with run-on-open scripts, this also will cause the macOS Installer to present a warning dialog, as shown here.

Unfortunately, unlike the Distribution file mechanisms, where there's something that you can see (no matter how arcane), there is basically nothing you can check here: macOS Installer plug-ins are binary executables, and there's not much you can do to analyze them beforehand. Again, you're probably better off focusing on other evidence of trustworthiness, such as the identity of the distributor.

How can I find installed files with dubious permissions?

Among the things you might want to examine in a package are the permissions — ownership and modes — of the installed files and folders. For example, you might want to look for the creation of files or folders that are outside the user's home folder but are writable to all. Or you might want to find executables which use the “Set User ID” or “Set Group ID” features to escalate privileges. (These things can be used for legitimate, non-malicious reasons, but they can also have security implications.)

Suspicious Package automatically flags some of these things in its Review, but often, interpretation is required. Another approach is to use the rule-based search feature on the All Files tab.

To enter the rule-based search mode, use Edit > Search Package (Command-F), and click the add button add search rule button on the right side of the search bar. Then, you can change the name pop-up to owner, group or file mode. For ownership rules, you can choose from the users or groups found in the package payload. For a file mode rule, you specify the bit(s) of the mode that you want to match, e.g.: All Openable Files

Note that you need to use numeric notation for the bits — these are the “absolute modes” you'd specify with the standard chmod(1) tool, whose man page has a good summary of these values. Some examples you might use here include the following:

Depending on the pattern of interest, you may be able to combine everything into one sets any bit in mask rule. Or you may need to add multiple sets all bits in mask rules, underneath an any grouping. To combine file mode checks with other rules, Option-click an add button add search rule button — it will turn into an ellipsis button ellipsis button — to add a new grouping.

Tip: If you have a common set of scenarios you want to look for in every package, configure your rules here once, and create a saved search. You can then apply these rules to any package, by going to the All Files tab, and choosing your saved search from the Go menu.

Why does Suspicious Package always export “All Openable Items”?

Suspicious Package allows a subset of installed files (such as property lists) to be opened in another application. To make this work, it exports these “openable files” into a temporary location, shortly after you open the package. Depending on the size of the package, this automatic export might take awhile, so Suspicious Package shows the progress in the Exports list like so: All Openable Files

For more on how to open these automatically exported files, see Opening Installed Files in Another Application.

Suspicious Package automatically deletes these files again when you close the window for the package.

How do I open macOS Installer packages with Suspicious Package by default?

If you use Suspicious Package on every package before opening it in the macOS Installer, you might find it convenient to make Suspicious Package the default application for packages. This can be done in the Finder, by choosing File > Get Info on any installer package, choosing Suspicious Package from the Open With popup, and then choosing Change All.

Once you do this, double-clicking any installer package will open that package in Suspicious Package. Once you decide you want to install it, you can use Suspicious Package's Open In Installer toolbar button (or Command-Shift-I) to proceed to the installer.

If you've downloaded a package, macOS will run Gatekeeper on that package when you first open it, no matter which app you are using to open it. So, if you switch the default app to be Suspicious Package, you'll get any Gatekeeper dialogs before it opens there. Of course, Suspicious Package isn't going to install the package — or run any of its install scripts — no matter what. But Gatekeeper doesn't know that.

Why did Suspicious Package change the icon for macOS Installer packages?

If you change the default app for opening macOS Installer packages, as described above, you'll notice that macOS (eventually) shows a different icon for these packages. The behavior of macOS here has changed repeatedly in just the last few years, so what you see will depend on the macOS version.

In macOS 11 (Big Sur), you'll probably see a generic (blank) document icon. We've attempted to make this better, either showing some version of a standard package icon or at least a document icon tied to Suspicious Package, without any luck. (Big Sur has a couple of new methods for defining document icons, but we couldn't get either of them to work here. We suspect this has to do with the way that macOS defines the types for installer packages — partly in the system-wide CoreTypes bundle, and partly in the macOS bundle — but we couldn't find a way to override this to produce a better experience.)

In macOS 10.15 (Catalina) or later, you will probably get a document icon with the Suspicious Package icon on it. This is simply the way that Catalina handles a user-selected default app, and we could do nothing to change it.

In macOS 10.14 (Mojave), we are able to provide an alternate icon that ought to appear for installer packages. We chose an icon that is somewhat different from the standard one (at larger sizes), so that you can see at a glance that the default application has been changed.

If this icon mess makes you crazy and you just want to go back to the default state, start by re-assigning the default app for installer packages to be the macOS Installer application, using the same process described above. On macOS 11 (Big Sur), that ought to be enough — although you may need to restart your Mac, and then start clicking on some package items, in order to convince the Finder to start showing the right icons again.

On macOS 10.15 (Catalina) or later, however, you may find that you now get a document icon with the Installer app icon on top. (Look closely here, because this combination looks bafflingly similar to the standard disk image icon.) The only way we've found to reset this state and bring back the normal package icon is rather hideous, and involves issuing these two commands in the Terminal:

/bin/rm -f ~/Library/Preferences/
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -delete
and then restarting your Mac (which is what the LaunchServices delete command will tell you is required). Note that this will reset your entire LaunchServices database, so you will lose any other default app assignments, and likely be forced to click through some new “you're opening this app for the first time” dialogs, too. So this is not to be undertaken lightly, but if you're going icon-mad, it might be worth it.

What purpose do package identifiers and bundle overwrite rules serve?

The metadata presented by Suspicious Package in the Info pane of the All Files tab all pertains to the end result of installing the package. There is additional data in the package (usually) that has more to do with the way that the macOS Installer performs the install; Suspicious Package does not show these by default. They are generally only of interest if you're developing or debugging a package yourself.

That said, if you want to see this additional data in the Info pane, you can enable it by going to Suspicious Package > Preferences > General, and checking Component package and bundle info. This adds two fields to the info pane:

What is the significance of the date and time that a package was signed?

All certificates — including Apple-issued Developer ID certificates — expire after some amount of time. (This is a security precaution, since the underlying technology and the attacks against it are always moving forward.) In the ideal case, developers replace certificates before they expire, and a package you download today will be signed with a still-valid certificate. But in the real world, developers don't always get ahead of expiring certificates; and on occasion, you might keep an older package and want to use it after the certificate has already expired.

However, an expired certificate does not necessarily make the package signature invalid. When a package is signed on macOS, the current date and time can be incorporated into the signature in a way that is independently verified by Apple. That is, instead of the package just claiming to have been signed at a specific date and time, the actual signing time is securely supplied by Apple, and bound to the package signature cryptographically. (This is known as a “trusted timestamp,” with an Apple server as the “Time Stamping Authority.”) This typically happens automatically when the developer signs the package, but it might have been disabled (see the productsign(1) man page, and the ‑‑timestamp option).

When you go to install the package — or merely examine it in Suspicious Package — macOS evaluates the validity of the signature. If it finds a verified signing time (and confirms that it is trustworthy), macOS will evaluate the signing certificate as of that date and time. If the certificate is expired now, but was not expired (and was otherwise valid) at the time the package was signed, macOS might declare that the signature is still valid. (There are exceptions; for example, a certificate might have been explicitly revoked, and might not be considered valid for any signature on any date.)

Suspicious Package uses the standard macOS mechanism for validating the package signature, so it will apply these same rules with respect to the verified signing time.

Unfortunately, the way that this is presented in the standard macOS certificate trust sheet is less than clear: if you examine the certificate details, you'll see that the certificate has expired, but macOS still says “this certificate is valid.” Of course, the certificate itself is no longer valid, but since it was valid at the verified signing time, the signature is nevertheless valid. However, macOS doesn't show the verified signing time anywhere, nor even note its existence. (As of macOS 10.15.4, the standard pkgutil(1) command will provide this information, but the standard certificate trust sheet is as confusing as ever.)

Suspicious Package attempts to improve matters by explicitly noting when a verified signing time is found in the package signature. If you choose Window > Signature Details (Command-5), and if the package signature includes a verified signing time, it will be shown in the sheet: package signature details sheet

If you click Show Certificate, you may still see the certificate-is-expired-but-valid confusion described above — since Suspicious Package uses the standard macOS certificate trust sheet, and can't change this bit — but at least this gives some context to the confusion.

What is a “writable startup volume folder”?

macOS 10.15 (Catalina) introduced a new scheme whereby the traditional startup disk is split into two volumes: a read-only volume containing the OS itself, and a read-write volume containing user data, software that isn't built into macOS (whether from the Mac App Store or direct from third-party developers), and supporting system files (like caches and data files that are updated outside of Software Update). This split is pretty much hidden in the UI, but you can see evidence of it in Terminal.

The reason this is relevant to Suspicious Package is that certain — probably rare — packages need to install into an alternate folder on the read-write volume in Catalina, while still installing into the normal read-write system folder on earlier versions of macOS. Rather than have two different packages for the different macOS versions, developers can declare both folder paths and let the macOS Installer pick the right one. For example, there are packages from Apple — such as the mobile development support packages that Xcode installs on first run — which are installed under the /System/Library folder on Mojave, but under the /Library/Apple/System/Library folder on Catalina.

When constructing the All Files tab for such a package, Suspicious Package assumes that it will be installed on the current startup disk. So, if Suspicious Package is running on Catalina or later, it will apply the alternate folder path to the All Files tab. That alternate folder will be identified with a special Kind description of writable startup volume folder. In the Review tab, you will see an informational “issue,” showing which paths were declared and which one was applied.

This is all well and good — as long as you are examining the package on the system where you'll install it. But if you are, say, working on Big Sur and will install on Mojave, you might want the All Files tab to represent the other scenario. You can do this by closing and reopening the package, while telling Suspicious Package exactly which macOS version it should assume. There are several ways to do this:

Note that none of this is relevant unless a package declares one of these alternate folder paths. If you don't get an informational issue to that effect in the Review tab, you can ignore these complications.