SD Notary 2 replaces SD Notary. You can use it as a stand-along app, or invoke it from Script Debugger 8 when exporting scripts. Script Debugger 8.0.6 and later will invoke SD Notary 2, falling back to SD Notary if SD Notary 2 is not found.
Because of the new name and ID, scripts will need to updated. Changes to the app means there have also been changes to the scripting dictionary.
The old version will continue to work until Apple drops support for its notarization method.
Before using SD Notary 2, please read the Requirements notes below carefully. Existing users should also consult the SD Notary 2 for existing SD Notary users notes.
SD Notary 2
SD Notary 2 is a utility you can use to notarize apps and certain other files. It replaces SD Notary, which uses a method that Apple is no longer supporting after fall 2023.
If you have already used SD Notary, you can skip to the section below that explains the changes in SD Notary 2.
The basic process involves three steps: a more comprehensive form of code-signing, submission to Apple where the app is checked and approved, and (optionally) stapling the resulting ticket to the app.
Most macOS applications are written in Xcode, and the process is designed with that in mind. For apps not written in Xcode, such as script applets, notarizing can be done using command line tools. Some of these tools, though, are still actually part of Xcode.
SD Notary 2 wraps a more friendly user interface around these tools. Although it was designed with script applets in mind, it should work with any application that has relatively straight-forward requirements. (SD Notary 2 was notarized by itself.)
Requirements
-
MacOS
11.3or later. Apple is discontinuing support for notarization from earlier versions. -
Xcode 13(or later) must be present, and have been run at least once to instal its command line tools. Xcode is a fee download from the Mac App Store. SD Notary 2 will launch it if it is not already running when SD Notary 2 is launched, or it has been updated since the last time SD Notary 2 was run. (If you have multiple versions of Xcode running, you may need to use xcode-select to make sure the correct one is running.) -
An
Apple IDwith two-factor authentication (not two-step verification). -
An
application specific passwordfornotarytool. See https://support.apple.com/en-au/HT204397. -
An
Apple developer accountin the name of the above Apple ID. See https://developer.apple.com/programs/how-it-works/ -
Membership of the Apple Developer Program. This costs $US99 and has to be renewed annually. This entitles you to generate a Developer ID code-signing certificate for your login keychain, which is needed to sign code. See https://developer.apple.com/developer-id/ or https://developer.apple.com/membercenter. -
A working
Internet connection. Notarizing involves communicating with Apple servers.
Using SD Notary 2
The SD Notary 2 window consists of three parts.
At the top, you choose the name of the Developer ID signing identity you wish to use. Unless you are a member of more than one team, there will only be a single entry. Below that you can choose whether to create and submit a disk image of your app, and if so whether to use DropDMG.app, and advanced settings for enclosures and extra entitlements. To the right, you can set the basic entitlements the notarized file will have.
The next part is the log area, where progress and feedback occurs. This is especially important when problems are encountered.
At the bottom are four buttons, for the four tasks SD Notary 2 can perform.
The Fetch History button will fetch the details of recent notarization sessions, and whether they succeeded.
The Sign Only… button lets you sign a file for notarization, without submitting it for notarization. You might do this before assembling files on a disk image, for example.
The Staple Only… button lets you staple a file that has already been notarized. You might use this when a session times out, or you lose your Internet connection after the file has been sent for notarization.
The Submit… but is where you select a file and submit it for notarization.
The first time you submit a file, or fetch details of recent sessions, you will see a dialog asking you to enter your Apple ID and the app-specific password you have set up for notarytool as described above. These credentials will be verified, and if correct will be securely stored in your login keychain. The only time you may be asked for them again is if you use a different Developer ID.
(These credentials are not stored in the application, and cannot be retrieved from your login keychain by either SD Notary 2 or Keychain Access. If you think you need to use your app-specific password again – on a different computer, for example, or a different account – you should ensure you also keep a copy elsewhere.)
Signs of progress
Depending on the size and complexity of your app, the speed of your Internet connection, and how busy Apple’s servers are, the whole process of submitting and stapling a file can take between a minute or two and quite a long time. The Log area will keep you informed of what is happening. If there is an error, it will display any explanation provided.
The copy of the file you choose to submit will not, itself, be modified. Instead, SD Notary 2 will create a folder next to it, named after the app, and make a copy there. So if you have chosen MyApp.app, a folder called MyApp - Working wil be created next to it.
The Working folder will contain a copy of the app, a .zip or .dmg containing the signed file for uploading, a file called Entitlements.plist containing the entitlements being claimed, plus a text file called Submission Log.txt. This log file is more detailed than the log that appears in the SD Notary 2 window, and includes each command-line call, and full results.
Once a .zip or .dmg containing your file has been successfully uploaded, SD Notary 2 will await approval. Assuming it it is granted, the signed file – or in the case of a .dmg, the dmg file – will be stapled with the notarizing ticket, and the containing folder renamed MyApp - Notarized. The original version will moved into a subfolder called MyApp - Unmodified Original. If approval is not granted, the folder will be renamed MyApp - Failed, and the original left where it was.
The detail
Notarized bundles have to be code-signed in a more comprehensive way than traditional codesigning. The app has to be set to use what is called the Hardened Runtime. This means the application cannot do any of the things listed in the Entitlements or Advanced tab views unless they are checked. The signature also has to include a time-stamp. Also, all executable code in the app bundle must be similarly signed individually using the same identity, and done so recursively from the deepest to the shallowest.
Any existing code-signing will be replaced.
Adds support for extra entitlements. Extra values must be saved in an a .plist file, which can be selected via the Extra entitlements… checkbox on the Advanced Entitlements tab. Clicking it will bring up a dialog to select the file. If there is any conflict with values set by other checkboxes, the values in the file take priority. The file can also be designated via scripting and the extra entitlements property.
Adds a new command to the File menu, Submit Again/Sign Again (command-R). If a submission fails and you need to modify your app, you can choose Submit Again, rather than having to go through to open dialog. Similarly, if signing fails you can modify your app and choose Sign Again.
You can now specify a default document set-up, covering identity, entitlements, and output format. You do this by setting up a document how you wish, then choosing Set Document Defaults from the File menu. You can reset to the factory default using the Reset Document Defaults command. As a consequence of the above, the Remember checkboxes for Apple ID, app-specific password and provider short name have been removed. The values are now saved (or not) via Set Document Defaults.
Hints
Apple expects to find code in certain places in a bundle. For example, frameworks are generally in /Contents/Frameworks, leaving /Contents/Resources for, well, resources. (In this discussion, script files are not considered code.) If Apple doesn’t like the way you code is structured, your app may be rejected.
A simple AppleScript applet (or Enhanced Applet from Script Debugger) should present no problems. But you need to be careful if you add other files.
In particular, if your app is a distribution app, and contains other applets within its bundle, you may want to notarize the applets to be distributed individually before adding them to the main app, and then check the Don't sign enclosures checkbox when signing the main app.
The other issue you need to be careful with is the bundle ID of your apps. Make sure they are unique for each app you upload, and preferably based on a domain name you own or control.
The File menu includes a submenu, Info For, whose commands allow you to query Apple’s servers for details of apps that have already been submitted for notarizing. When you submit an app, once it is uploaded Apple assigns it a unique ID, known as the Request UUID. These commands let you retrieve information based on the Request UUID. You can either copy a UUID from a page returned by the Fetch History command and use that; let the app retrieve the info for the most recent submission; or select the RequestUUID.txt file saved when you submit a file. If notarizing fails, this can sometimes give you more clues to why.
App-specific password
Notarizing uses a utility called notarytool that requires password authorization. You create an app-specific password by signing into you Apple ID account page https://appleid.apple.com, and clicking Generate Password below App-Specific Passwords. You should enter the app-specific password in SD Notary 2 when prompted for it. If you think you need to use your app-specific password again – on a different computer, for example, or a different account – you should ensure you also keep a copy elsewhere.
Supported file types
SD Notary can also notarize .dmg, .pkg, .plugin, .action, and .fmplugin files.
Notarizing .plugin and .fmplugin files is similar to notarizing an app. Notarizing .dmg and .pkg files involves a different workflow, because only read-only disk images and flat .pkg files can be notarized. In this case you need to sign the contents of the disk image or package before you create the image or package file itself. Then you create the .dmg or .pkg file from the signed content, and submit it for notarizing.
Signing of .pkg files requires a Developer ID Installer identity, rather than a Developer ID Application identity, so you must ensure you have both certificates installed if you wish to submit packages. If you have already signed the .pkg file while building it, it will not be re-signed.
You use the Sign Only… button to sign disk image and package contents. When you press the button, you can choose the app to sign, or you can choose a folder containing all the files that will end up in the disk image. The latter is useful if you are including more than one app. Once the signing is complete, you can make your disk image or package, and then submit it the same way as you would submit an app directly.
It is important that you do not make any changes between signing and creating a disk image or package, and that you use the notarized versions for distribution. When a disk image or package is notarized, any tickets for its contents are attached to the container file, and these will be lost if you repackage it. If in doubt, you can also notarize apps separately before adding them to a disk image file for notarization.
Creating disk images
SD Notary now has an option to create a disk image as part of the process, optionally using DropDMG.app if you have it installed. The notarization process works slightly differently when you choose either of these options.
if you do not choose to create a disk image, your app or plugin is signed, and then a .zip file of it is created and submitted to Apple. Once it is approved, the .zip file is discarded and the signed copy is stapled. The stapling step is optional, and is just a convenience. When someone tries to open a notarized application for the first time, the system look for the notarization ticket stapled to it. If it is not found, it contacts Apple’s servers to see if the app has been notarized anyway. Obviously, this can involve a significant delay, and can be inconvenient if you are off-line.
If you choose the disk image option, your app is signed as above, and then a read-only .dmg file is created and uploaded to Apple, instead of a .zip file. Once the app has been checked and approved, the .dmg file is stapled, rather than the signed copy of the app — the signed copy is in fact discarded. When you distribute such a disk image, the stapled ticket is read when the image is mounted, so the system does not need to check the app’s status when you first launch it.
By using a disk image, you can encourage people to copy your app to somewhere outside their downloads folder, which in turn can remove some quarantined behavior. If you use DropDMG, you can specify a configuration so that other elements, such as a licence, Read Me file and background graphic are included in the disk image file.
You can still create disk images the old way: Sign Only your app, build your disk image, and submit the disk image file. The new option just streamlines the process.
Scripting
SD Notary is fully scriptable. Each window is represented by a document. Documents can’t be saved, but they have properties, and respond to commands such as submit app.
The main windows collection lists only “true” windows, with a new sub-element class, window tab, listing all the tabs within a window.
When using the submit app command, you need to set a very large timeout. Some errors include more detailed logging information in their from parameter.
A typical script to submit an app might look like this:
set appFileOrAlias to choose file of type {"app"}
try
tell application id "com.latenightsw.Script-Notary" -- SD Notary.app
set newDoc to make new document with properties {allow events:true, allow calendar access:true}
tell newDoc
with timeout of 10000 seconds
set notarizedCopy to submit app at appFileOrAlias without showing dialogs
end timeout
end tell
close newDoc
end tell
on error errMess number errNum from extraInfo
-- handle error
end try
tell application id "com.apple.finder" -- Finder
reveal notarizedCopy
end tell
The submit app command has an optional boolean parameter skipping stapling. This lets you submit an app, and staple it later. This can be useful if you want to queue several apps for uploading.
The paths to skip property is an adanced setting that is not exposed in the interface at this stage.
There is also a pre submit app scripting command. This lets you specify an app to process so that SD Notary will activate with the file already selected in a document, and puts the document in a special mode where you can change the settings, and press Submit Now. All other commands are disabled for the document while it is in this mode.
Problems
If you strike problems that you think we should know about, we need a copy of the Log on screen, plus a copy of the relevant Submission Log.txt file.
SD Notary 2 for existing SD Notary users
SD Notary 2 uses a newer tool, notarytool, instead of the deprecated altool used by the original SD Notary. This requires changes to how you set up the app, how it logs progress, and how it interacts with Apple’s servers, but it does not change what it does, and how you configure the various notarization options.
The first thing you are likely to notice when you run SD Notary 2 are that several fields have been removed:
-
Apple ID. You will still need to enter your Apple ID when prompted, but it is no longer stored within the app. If you have only a single Developer ID siging identity, you will be asked for your Apple ID only once, the first time you press Submit… or Fetch History. if you have more than one Developer ID signing identity, you may be asked first time you use each one – it depends on whether you use multiple Apple IDs.
-
Name of app-specific password. You no longer need a password for
altool, but you will need to set one up fornotarytool. However, unlike before, you will not need to add it to the login keychain in Keychain Access as a named password item. Instead, you will enter the password directly when asked. This will happen at the same time as you are asked for your Apple ID, so only once for most people. -
Provider short name. This is no longer required.
Once you have entered your Apple ID and app-specific password, they will be stored in your login keychain by notarytool itself – they will not be stored within SD Notary 2 or its preferences. They will also be stored securely so that only notarytool will be able to access them – you will not be able to see the values via Keychain Access.app. For this reason, you may want to keep a back-up copy of the notarytool app-specific password somewhere else.
Other differences you may notice are the lack of a Cancel button after submitting a file, and different information and formatting in the log. The scripting dictionary has also changed to reflect the changes to the way credentials are handled.