Adding App Notarization For Macs To Your Build Train

Apple sent the following message out to developers yesterday:

Dear Developer, 

We’re working with developers to create a safer Mac user experience through a process where all software, whether distributed on the App Store or outside of it, is signed or notarized by Apple. With the public release of macOS 10.14.5, we require that all developers creating a Developer ID certificate for the first time notarize their apps, and that all new and updated kernel extensions be notarized as well. This will help give users more confidence that the software they download and run, no matter where they get it from, is not malware by showing a more streamlined Gatekeeper interface. In addition, we’ve made the following enhancements to the notarization process.
Legacy code is fully supported, even if it contains unsigned binaries. While new software and updates require proper signatures in order to be notarized, you can upload your existing software as-is.Apps with plugin ecosystems are better supported.Stapler supports all types of bundles and plugins.Xcode 10.2 adds secure timestamps and other code signing options required by the notary service.Related documentation has also been improved. We encourage you to take look at Notarizing Your Apps Before Distribution and Hardened Runtime Entitlements.

If you have any questions, contact us

Best regards,
Apple Developer RelationsTM and © 2019 Apple Inc.
One Apple Park Way, MS 301-1TEV, Cupertino, CA 95014.

All Rights Reserved | Privacy Policy | Account 

If you would prefer not to receive future communications from Apple Developer, you may unsubscribe.

Many organizations have a solution to automate their build process for software and will need to now add submitting an app for notarization to this process. Before you start, there are a few things you should know:

  • This is an automated scan that usually takes about 20 minutes and requires at least the 10.9 macOS SDK.
  • Before submitting, make sure code-signing has been enabled for all executables and that you enabled the Hardened Runtime option.
  • Find a workaround if you’re setting to true for any reason.
  • Make sure to use an Apple Developer ID instead of a local cert from Xcode for apps and kexts. And make sure all code-signing certs have a timestamp when running your distribution workflows in Xcode or if using codesign make sure to add –timestamp.

You can use any tools for the next steps. Because I have a Bamboo setup on my desk, next I’m going to open it and create a command task. To do so:

  • Open the Tasks configuration tab for a job (or default job in a new plan).
  • Click Add Task.
  • Add a Task Description, which is just how the task is described in the Bamboo interface.
  • Uncheck the box to “Disable this task”
  • Provide a path to the command executable, which in this case will be a simple bash script that we’ll call /usr/bambooscripts/ If you’re stringing workflows together you might add other scripts as well (e.g. a per-product script as opposed to a generic script that takes positional parameters for arguments).
  • Provide any necessary Arguments. In this case it’ll just be a simple job but you can reduce the work by adding arguments for processing paths of different products.
  • Provide any necessary Environment Variables. We won’t use any in this project.
  • Provide any necessary “Working Sub Directory” settings, which is an alternative directory rather than using a relative path. If you don’t provide a working sub directory, note that Bamboo looks for build files in the root directory.
  • Click the Save button (as you can see below).

Now we’ll need to use scrub with the altool. Here, we’ll use the –notarize-app option and then define the bundle (using the reverse naming convention you’ve always used for the –primary-bundle-id option and then the username and password from your Apple ID linked to your Developer ID and finally the –file which is the zipped output from Xcode.

#!/bin/bash /usr/bin/xcrun/xcrun altool --notarize-app --primary-bundle-id "com.myorg.myproduct” --username “” --password “icky_passwords“ --file "/Users/krypted/Documents/"

We'll call this script /usr/bambooscripts/ and then let the job pick it up and process it.

Oh funny. I just noticed Rich Trouton posted a writeup on Notarization at I'd read that as well.

Who Signed My OS X App?

The codesign command is used to sign apps and check the signature of apps. Apps need to be signed more and more and more these days. So, you might need to loop through your apps and verify that they’re signed. You might also choose to stop trusting given signing authorities if one is compromised. To check signing authorities, you can use codesign -dv --verbose=4 /Applications/ 2>&1 | sed -n '/Authority/p' The options in the above command:
  • -d is used to display information about the app (as opposed to a -s which would actually sign the app)
  • -v increases the verbosity level (without the v’s we won’t see the signing “Authority”)
  • –verbose=4 indicates the level of verbosity
  • 2>&1 redirects stderr to stdout
  • /Applications/ – the path to the app we’re checking (or signing if you’re signing)
Then we pipe the output into a simple sed and get the signing chain. Or don’t. For example, if you’re scripting don’t forget a sanity check for whether an object isn’t signed. For example, if we just run the following for a non-signed app: codesign -dv --verbose=4 /Applications/Utilities/ The output would be as follows:
/Applications/Utilities/ code object is not signed at all