After spending the best part of 2 weeks looking at this I have finally succeeded in notarising an adobe premiere pro plugin! I am happy to share the process that I have used. I will emphasise that this is the process that worked for me and has not been checked out by any other users. The process should be the same for other plugins also.
With the upgrade to MacOs Catalina you now MUST notarise and sign a plugin or Gatekeeper rejects it with no option for the user to run it! The proverbial “brick wall”. You will find your plugin will work locally on the development computer but as soon as the plugin is distributed in any way (ie on this website) then it will no longer run. I found this out the hard way!
Following apple’s instructions I got nowhere, because when I archive the project the option for “Validate” (ie notarise) is greyed out. I do not really know why this is but I assume that unless you are running mainstream apps the x-code workflow for notarising does not work (well, at least it did not work for me!)
Certificates
The first thing to note is that I found you need to be join the “apple developer program”. Having expired membership I had to rejoin at a code of £79.00 UK. As far as I am aware this is necessary.
Start by using X-Code menus Xcode->Preferences and then the “accounts” tab you must add your developer apple id. Then on the same tab use “Manage Certificates” and add a “Developer ID Application” certificate.
X-Code target settings
Select your target in X-Code and select “signing and capabilities”. Select your team and then use “Developer ID Application”. I did NOT use automatic signing. See screenshot below.
Two other settings are important. Under Build Settings find “Enable Hardened Runtime” and set this to “Yes”. Find “Other code signing flags” and write in “–timestamp” to make a secure timestamp. That is all the settings that I had to do. Now just compile your plugin bundle.
Preparing dmg for notarising
I use command line commands in “Terminal” to do the notarising. I chose to package the resulting bundle (in my case legaliser.plugin) in a dmg. I am not going to go into creating a dmg as it is rather ubiquitous. Once you have your compiled plugin and put it into your dmg you will have a filename.dmg package. You will need to remove some attributes of the dmg using this command. This is important!!
% xattr -cr <path_to_dmg>
and then code sign the dmg (The package inside already being codesigned! — see also note ** at the end of this article if you have any other third party libraries and any “other” binary code in the bundle).
% codesign –force –sign “identity” <path_to_dmg>
You can find your identity by running another command
% security find-identity -v -p codesigning
Your final codesign command will look something like this:
% codesign –force –sign “Developer ID Application: Some Developer (HF6KS429KLT)” <path_to_dmg>
Notarizing the product
You can now actually submit the final dmg to apple for notarising like this:
% xcrun altool –notarize-app –primary-bundle-id “MyCompany.product” –username “apple_id_usename” –password “app_specific_password” –file <path_to_dmg>
MyCompany.product is the bundle identifies as shown in the screen shot above.
You need to generate an app_specific_password. This is described here
https://support.apple.com/en-us/HT204397
In short – simply go to the apple id accounts page and under security you can generate an app specific password. Your final command will look something like this:
% xcrun altool –notarize-app –primary-bundle-id “MyCompany.superplugin” –username “steve@icloud.com” –password “ehgf-lavs-iegb-aoll” –file /path/to/mydmg.dmg
If all is good the command will return with something like:
% No errors uploading ‘/path/to/mydmg.dmg.
% RequestUUID = 02a12386-3e9e-40ea-b346-ab082340d562
and you will get an email from apple saying that it’s been successful.
If this works first time (big if!) then you can staple the ticket to your dmg by using:
% xcrun stapler staple /path/to/mydmg.dmg
and you are good to distribute!!!!!
Notarizing failure
I had a lot of this before I got it all to work! You now need to run a command like this:
% xcrun altool –notarization-info <RequestUUID> -u “apple_id_usename” -p “app_specific_password”
The <RequestUUID> is in the email and also printed in terminal after the notarising command above. This command will return among other things a URL. Cut and paste the URL into a browser and you will get some very useful information about why your package failed.
** Other binaries in your bundle
In my case the bundle also had a 3rd party .dylib which was copied to the resources file. The notarising will fail if this is not codesigned. (Or indeed any other foreign binary which could be malicious). You can codesign this separately and just keep a codesigned version of it in your project. I found this was the best method. Just run these two commands on the binary:
% xattr -cr <path_to_dylib_or_any_binary>
and
% codesign –force –sign “identity” <path_to_dylib_or_any_binary>
and treat the resultant binary as a special codesigned version for distribution.
Conclusions
On the whole it is quite an involved process and don’t expect to get it right first time. Once you have done it successfully a few times you begin to understand the process which makes it easier to grasp.
Useful other terminal commands
Check a binary to see if it is codesigned
% codesign -dv <path>
Check notarisation status of a dmg
Check a dmg to see if it is notarised
% spctl -a -t open –context context:primary-signature -v /path/to/my.dmg