Yeah, sorry only saw afterwards that that had already been covered. 
I’ve been playing with this a bit, and here’s some more info…
@Tekl : I suspect you have only stapled your disk image, not the app. You can check by running spctl:
spctl --assess --type exec -vv /path/to/Applet.app
For a normal codesigned applet you will see:
source=Developer ID
For one that’s been stapled, you will see:
source=Notarized Developer ID
It turns out the issue with submitting zipped applets is that stapling only works with 64-bit-only binaries. This may well change at some point — it seems odd that the notarizing process has no such limitation, and only the stapling fails — but at this stage you need to use lipo on the applet binary to strip 32-bit code before you sign.
Also, the --deep argument is useless when signing with the required hardened runtime. If your applet includes any other binaries, you have to follow the same lipo/codesign process with them first, working from the deepest level up.
The last point makes notarizing an Enhanced Applet (or any applet with embedded frameworks, apps or binaries) reasonably complex.
A utility to handle the process is under development, and it should end up relatively straight-forward. Exactly how it will be made available is still undecided. Watch this space.
1 Like
Hi Shane,
thanks for looking deeper. Apple tells that notarizing a disk image will also notarize the content. 
Alternatively, you can put apps, kernel extensions, and other software in a container, like a disk image, and notarize the container. The notary service accepts disk images (UDIF format), signed flat installer packages, and ZIP archives. It processes nested containers as well, like packages inside a disk image.
Yes, but I’m pretty sure it only staples the ticket to the disk image. That’s fine as long as you then distribute that unchanged disk image.
Apps can be notarized without being stapled, of course. It just means the original checking process Gatekeeper does involves talking to Apple’s servers rather than consulting a local ticket.
And indeed it has. Apple’s server now handles fat binaries (it provides tickets covering both binaries).
And see here:
2 Likes
Oh, thank you so much 
This has all been very helpful. Thanks! However, I am wondering about distributing updates. What does notarization make “note” of? If I distribute a MyAmazingApp.app v1.0.0 properly code signed and notarized, how do I release v1.0.1 and yet still allow v1.0.0 to be distributed and run?
Versions shouldn’t cause any problems. When you staple your app, the ticket that’s stapled to it contains a hash of all its executables as calculated from the upload, and Gatekeeper will compare that with what it presumably calculates itself.
How and when any other checks are done is unknown at this stage, and will probably (a) change and (b) be purposely kept obscure.
Further to the question of versions, this is what of the Apple team wrote on their developer forums:
We encourage developers to upload all the macOS software they distribute, including versions previously released. This helps users of older versions of your software and helps us improve as well.
I have a problem that stops me from beginning with notarization. It is maybe a bit off topic for this thread – but a would appreciate any suggestions.
I have två apple-id:s: One is my private account, which all my devices including my workplace computer is logged into, and another that I use as developer ID in my work. That’s the way I want it to be. Since my workplace Mac is connected to my private account, my keychains, my files on iCloud Drive and so on are always in synch between work and home. I don’t want to merge the two accounts into one, and I think it would also be some technical obstacles in doing that.
Now notarization demands app specific passwords, which in turn demands the Apple ID uses two factor authentication. But – as I understand it – two factor authentication demands that at least one Apple device is connected to iCloud with that Apple ID. When I’m logged in at my Apple ID account page with my developer ID, the alternative to create two factor authentication is not present. Two step verification is the only available choice, and the reason seems to be that I have no device connected to iCloud with that account.
So my fear is that I can’t begin to notarize my apps unless I mix my private and professional world – ether use my developer ID for iCloud och vice versa – which Is really unwanted. Or did I misunderstand something? Is there a workaround?
(BTW, thanks for that tool, Shane.)
According to Apple you need a trusted device: “A trusted device is an iPhone, iPad, or iPod touch with iOS 9 and later, or a Mac with OS X El Capitan and later that you’ve already signed in to using two-factor authentication.”
And: “Once signed in, you won’t be asked for a verification code on that device again unless you sign out completely, erase the device, or need to change your password for security reasons. When you sign in on the web, you can choose to trust your browser, so you won’t be asked for a verification code the next time you sign in from that computer.”
To be clear, the actual notarization process uses the app-specific password, so there’s no authentication involved at that point. So perhaps you can set it up by changing iCloud accounts temporarily, perhaps even on another Mac at work.
Thanks for the clarification, Shane. Considering that, your suggested solution should work.
A quick note: SD Notary will need an update to work properly with 10.14.5. It’s in the works.
1 Like
And released as version 1.0.1:
Here’s a script to automate the submission process from Script Debugger. Note that if you are going to notarize an app, there’s no need to turn codesigning on in Debugger — notarizing requires a deeper form of code-signing.
set docNumber to 1 -- change for testing
tell application id "com.latenightsw.ScriptDebugger7" -- Script Debugger.app
set theDoc to file spec of document docNumber
-- build file object for run-only version
set newDoc to my makeRunOnlyFile(theDoc)
-- export run-only version
save document docNumber as script application in newDoc with run only and bundle run only
end tell
tell application id "com.latenightsw.Script-Notary" -- SD Notary.app
try
with timeout of 1 second -- we just want to get it started, so we can get on with other things
-- submit try notarizing
submit app newDoc with showing dialogs -- dialogs will let us know when it's done
end timeout
end try
end tell
-- Handler to take file of open document and create file for run-only version. Modify to suit your naming convention.
on makeRunOnlyFile(theDoc)
set docPath to theDoc as text
set {saveTID, AppleScript's text item delimiters} to {AppleScript's text item delimiters, {":"}}
set theParts to text items of docPath
set AppleScript's text item delimiters to {"."}
set oldStubName to text 1 thru text item -2 of (item -2 of theParts)
set newName to oldStubName & " Run-Only.app" -- !!! Choose your own scheme here
set theParts to items 1 thru -3 of theParts & newName
set AppleScript's text item delimiters to {":"}
set newPath to theParts as text
set AppleScript's text item delimiters to saveTID
return (newPath as «class furl»)
end makeRunOnlyFile
Obviously you will need to modify the makeRunOnlyFile() handler to suit. My personal style is to save editable versions with an underscore before the extension, and remove it for the distribution version.
The only limitation is you can only have one file being notarized at once.
Thanks for the update. As I hate Apps without an icon I created one myself. 
Feel free to use it.
SD Notarize.icns.zip (558.8 KB)
Thanks for the icon! We are working on a few ideas for an SD Notary icon and I’ll add this to the mix.
As an applescripter not acquainted with programming in general, there are a lot about notarization that I don’t fully understand. I therefore have som questions of practical interest, that I would be happy for any clarification about:
• Using SD Notary there is a “Staple Only…”-choice. When is it useful to use that button? Is it only necessary to submit a first version of an applet?
• How is the files that are created along with the notarized applet – the RequestUUID file (ticket?) and the Entitlements.plist – intended to be used? Do I have to somehow attach them when distributing the applet? Must I keep them in place?
(In my case the applets I make is for in-house use only, and they are not distributed using disk images but copied using deploy tools.)
You use it if you have submitted an app but the process has been interrupted. You might have shut down the computer, or lost your connection, or Apple’s server might be having a bad day. So you use it to staple a copy that has already been submitted.
The RequestUUID is not the ticket, but it’s a number Apple uses to refer to your app. If you press Fetch History, you will see your submissions listed by Request UUID; having it recorded in a file lets you make sense of the history list.
The entitlements file is used in the code-signing, and is based on which of the checkboxes you checked in the Entitlements tab view. It’s kept as a record, in case you want to check what you allowed for an app.
1 Like