Contents  DropDMG Manual  Technical Support

5.1.9   Signing

About Signed Disk Images

Apple recommends that Mac applications be distributed on disk images that are code signed. The signature allows the customer to verify that the downloaded disk image is exactly as you created it, that it has not been maliciously modified, and that it was created by a valid Mac developer registered with Apple’s Developer ID program. If the disk image is not signed, an application stored on it will be subject to Gatekeeper Path Randomization (a.k.a. App Translocation). That is, macOS will copy it to a read-only, random location prior to launch. The app will not be able to update itself or access its external resources, and it can lose privacy permissions that you had granted. macOS stops using path randomization on an app when the user moves it (via Finder—other ways of moving the file don’t work). However, neither the failure mode nor the remedy is made clear to the user, so it’s best to avoid potential problems entirely by using a signed disk image.

macOS 10.12 and later automatically verify the signature when mounting a disk image. Signed disk images can still be mounted on earlier versions of macOS, which ignore the signature.

Note: macOS does not support signing encrypted disk images.

Signing Disk Images With DropDMG

To have DropDMG sign your disk image, choose the appropriate signing identity from the Signing pop-up menu in the Configurations settings. This is probably one whose name begins with Developer ID Application. In the event that you have multiple identities with the same name, DropDMG will show a tooltip that shows the SHA1 hash for the identity so that you can tell which is which.

Signed disk images can be created on macOS 10.11.5 and later. Only read-only disk images in .dmg format can be signed.

Secure signing requires access to Apple’s trusted timestamp server, so your Mac must be connected to the Internet when you create the disk image with DropDMG.

You can verify the signature of a disk image or archive, and see who signed it, using the Verify Signature… command.

To remove or change the signing on a disk image, use the Convert Image/Archive… command.

Notarized Disk Images

Separate from code signing, Apple recommends that applications and disk images be notarized. Notarization is required for new developers starting with macOS 10.14.5 and for all developers starting with macOS 10.15. (“Required” means that, without notarization, macOS will prevent launching the app and will show a scary alert window saying that it couldn’t check the app for malware.)

There are two ways to notarize an app:

  1. You can notarize the app itself using the Organizer window in Xcode. This is the easiest method, as Xcode handles uploading the file, monitoring the progress, and stapling the ticket. (Alternatively, you can use a helper utility such as SD Notary.) You can then put the app in a disk image or ZIP archive for distribution.

    Note: Such “automatic” notarization may not be suitable for disk images that are signed; prior to macOS 10.15 Beta 6, signed disk images containing a notarized app trigger the malware alert, and even after that version they are treated as unsigned and so are subject to App Translocation.

  2. You can notarize the disk image container using what Apple calls the custom workflow. In practice, this means using the altool and stapler command-line tools. (Alternatively, you can use a helper utility such as SD Notary or App Wrapper.) This is what most developers will need to do, because Apple recommends that disk images be signed, and macOS requires that signed disk images also be notarized. It is not enough to notarize the app inside the disk image.

    Note: When you notarize the container disk image, altool also notarizes the app inside, so you can skip the step of notarizing the app using Xcode.

In some cases, it may be beneficial to notarize the app itself and also notarize the disk image container. If you transfer an installed app to another Mac directly (not via a notarized disk image), the Mac will be able to look up online its ticket from notarizating the disk image. However, if you had also separately notarized and stapled the .app package, macOS would be able to verify the notarization offline, as well.

Levels of Signing

A macOS app distributed outside the Mac App Store will generally have 3–4 separate layers of signing:

  1. The app itself will be code signed by Xcode after it’s compiled.
  2. If the app has an installer, the package file will be signed using an installer certificate.
  3. The disk image containing the app or installer will be signed using an application certificate. (This is the part DropDMG handles.)
  4. The disk image will be submitted to Apple for notarization, and then have a ticket stapled to it.

Gatekeeper and Quarantine

macOS only applies path randomization and notarization checks to apps and disk images that are quarantined by Gatekeeper. Web browsers and other apps that transfer files over the network add the quarantine flag (a extended attribute) to files that they download. When you open the file—and it passes the security checks—macOS removes the quarantine flag. This means that:

You can bypass Gatekeeper by:

“Detritus” Errors When Signing a Disk Image

Creating a signed disk image on macOS 10.12 or later may fail and report this error:

resource fork, Finder information, or similar detritus not allowed

This means that one or more of the files that you asked DropDMG to copy to the disk image contained extended attributes (xattrs), which macOS signing disallows for security reasons. In most cases, the xattrs are not actually needed, so you can simply remove them.

You can use a Terminal command such as:

find . \( -xattrname -o -xattrname \) -print0 | xargs -0 xattr

to find all the files with Finder info or resource forks in the current directory.

You can use a Terminal command such as:

xattr -cr .

to remove all the extended attributes from all the files in the current directory.

     Contents  DropDMG Manual  Technical Support