Suspicious Package

Frequently Asked Questions

Installing Suspicious Package

What versions of macOS does Suspicious Package support?

Suspicious Package supports:

We don't know how or if Suspicious Package works on the preview of macOS 11 (Big Sur). Unfortunately, we don't have a spare Mac that's capable of running it, and are't eager to let it near our primary machine. If you find problems under Big Sur, you're welcome to let us know, but we can't promise to fix anything.

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?

Although you can install Suspicious Package app anywhere you like, Quick Look can be stubborn about recognizing the plug-in that is bundled inside of it. Specifically, you must open the Suspicious Package app at least once before Quick Look will even consider using its plug-in (this is, presumably, a security measure, so that only apps which pass the Gatekeeper checks can generate Quick Look previews). After you do that, Quick Look should find and use the plug-in.

If you open the app before dragging it to your Applications folder (or wherever you've decided to keep it), make sure to open it again after you've copied it. If you open the app directly from the disk image, it will not be marked as safe-to-use for Quick Look.

When the Suspicious Package app is opened for the first time, it will request that Quick Look update its plug-in registry, and that will usually suffice to get previews working immediately. Starting in version 3.3, the app repeats this request to Quick Look after the app has been moved or updated, or after macOS itself has been updated — these are all scenarios that can prevent or delay Quick Look in finding Suspicious Package.

If, after opening the app, you still do not get a proper Suspicious Package preview from Quick Look, you can open the Terminal and run the following command to force the issue:

/usr/bin/qlmanage -r

Why don't I get a Quick Look preview in Apple Mail (or in other apps)?

Although macOS offers Quick Look previews from many different contexts — beyond just the Finder — there are issues that prevent Suspicious Package from working in some cases.

For example, if a macOS installer package is attached to a mail message, you can request a Quick Look preview directly from Apple Mail — select the attachment and choose File > Quick Look Attachments (or use Cmd-Y or spacebar, just like in Finder). Usually, this does properly display the Suspicious Package preview.

However, if the Suspicious Package app is not installed inside the standard Applications folder, this might not work. For some reason, Apple Mail attempts to inspect our Quick Look plug-in directly, and because Mail is sandboxed, it can't “see” the plug-in if it lives in your home folder, and then Mail decides not to use it. If you get a generic Quick Look preview from Mail, this is probably the reason. Unfortunately, the only way we know to make this work is to move the Suspicious Package app to the Applications folder (or somewhere underneath it). In our testing, this problem no longer occurs in macOS 10.15 (Catalina).

Suspicious Package previews should generally appear and work correctly from other contexts, such as the Finder's Gallery view in macOS 10.14 (Mojave), and in the Spotlight results window. However, you may find that, in some of these contexts, the Suspicious Package preview is too small or difficult to work with. You may be able to resize the preview area to make it more usable, but this is not possible in all contexts. We're aware of these issues, but haven't quite figured out how to improve upon them.

Why don't I get a Quick Look preview in Finder windows set to use Column view?

Finder's Column view (i.e. View > as Columns) shows Quick Look previews in the rightmost pane for some types of files. But it doesn't support interactive previews such as Suspicious Package (excepting some of the built-in types, like PDF files or movie files).

We haven't found any way to make Suspicious Package work in this context, so if you are using Column view, you will still need to explicitly request a Quick Look preview for installer packages, e.g. using the spacebar or Cmd-Y.

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 on the right side of the app's title bar: available update indication and at the bottom of the Quick Look preview: 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 Note that the automatic check preference you set here applies to both the app and the Quick Look plug-in.

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.

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, whether that occurs from the app or the Quick Look plug-in.

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. In version 4.3 of Little Snitch, these alerts will also be improved to reference “Suspicious Package” (or in the case of the Quick Look plug-in, the “Suspicious Package Update Checker”) instead of the underlying XPC service.

When it is time to check for updates, either the app or the Quick Look plug-in might initiate the connection, depending on which one is used next. If you tell Little Snitch to allow the connection forever, you might still get a second connection alert, because the rules for the app and the Quick Look plug-in are distinct. After the second time, though, it should stop asking.

I don't want an app. Can I install only the Quick Look plug-in?

No. But you don't have to use the app, if you don't want to. Bundling the Quick Look plug-in inside the app simplifies installation: just drag the app into your Applications folder (or wherever). No more ironic Suspicious Package package!

You do have to open the app at least once, after you've dragged it into your Applications folder, in order for macOS to run Gatekeeper and mark the Quick Look plug-in as safe-to-use. See more about troubleshooting Quick Look problems.

Don't try to drag the Quick Look plug-in out of the app bundle. It won't work, because the plug-in relies on other resources within the app bundle.

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”?

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 some restrictions that would severely reduce the usability of the app. Most significantly, a top-level package can reference component packages that are in sibling folders. (This is not uncommon for packages delivered on disk images, where only a single top-level package is visible in the Finder, but it references component packages in some hidden folder on the same disk image.) If Suspicious Package were sandboxed, it wouldn't be able to read those external component packages.

That isn't to say that Suspicious Package won't ever be sandboxed, 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.

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 on Catalina?

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 on Catalina?

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 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 script 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.

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 advanced search feature from the All Files tab to find files by their Package ID — that is, the identifier of the component package that installs them.

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 modern (so-called “flat”) installer packages. It is otherwise extremely difficult to see the scripts in a flat package.

An older package format (known as “bundle-style”) 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” script and should I inspect it?

Most modern installer packages have a “distribution” script. 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 This also causes the macOS Installer to present a warning dialog when it opens the package: Run-on-Open issue

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 script.

Which brings us to the other bad news: the distribution script 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 script 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 script in all its glory, you can go to Suspicious Package > Preferences > General and check Distribution script.

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 script'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 script 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?

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 this warning dialog: Run-on-Open issue

Unfortunately, unlike the distribution script 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.

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.

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

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.

Unfortunately, prior to version 3.3.1, a side effect of doing this was that the Finder (and everything else on the system) would start to use the generic document icon for every package. This is because macOS doesn't define the installer package icon globally, but associates it specifically with the macOS Installer application. And since Suspicious Package didn't try to redefine the icon for installer packages, it fell into generic document territory.

So, starting in version 3.3.1, Suspicious Package defines an icon to avoid this ugliness. 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 (and also, frankly, to avoid bloating the size of the app by delivering another copy of the rather large package icon that already exists on every macOS system!).

All of this is relevant only if you change Suspicious Package to be the default application for installer packages. If you leave the macOS Installer as the default application, you should not see any change in the icons.

On macOS 10.15 (Catalina), once you change the default application for a given type of file, macOS apparently creates a new icon by overlaying the chosen application's icon on a generic document one. So, instead of the modified package icon that Suspicious Package provides, you might see a document with the Suspicious Package icon inside; we have no control over this. Indeed, if you switch back to the macOS Installer as the default application, you might then see the Installer's icon inside a document (which is quite strange and looks way too much like a disk image icon). We have no clue how to reset this to get back the package icon; even deleting the LaunchServices database doesn't seem to help.

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.)

Starting in version 3.3, 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” on Catalina?

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, 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 working on Catalina and will install on Mojave (or vice-versa), 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.