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.
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.
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.
Thank you for this tool. It works perfectly with the relatively simple AppleScript apps I tested. One thing that may be useful for other people: If your script apps include unix binaries, it seems necessary to codesign them separately before using SD Notary. If I don’t codesign the unix binaries separately, then the script app won’t get notarized – even though SD Notary says it is signing the unix binaries.
I don’t pretend to understand why this is necessary, or whether I’m misreading the situation.
Apologies: I got confused about what my problem was. Everything I said about having to sign binaries was mistaken - I was muddling up two scripts. The actual problem I’m having seems to be that one of my scripts uses a unix binary that requires various dylib files in the same folder. I have all of these in the Contents->Resources->Files folder. The log tells me that all of these are unsigned. I’ll be glad to send this, but is there any chance that SD Notary can sign dylib files in the same folder with binaries? (And how would I send you the script if you want it?)
Hello Shane, I just realized that I tried to e-mail at a “noreply” address. Is there some way I could find a direct address? Thank you again for offering to look at this.
OK, I’ve had a go at notarizing your app. SD Notary 1.0.1 doesn’t sign .dylib files, but the next version will. However, your app still fails with this error:
"logFormatVersion": 1,
"jobId": "047fd535-f78d-4d93-96af-4567200a7d06",
"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,
"archiveFilename": "WPExport.zip",
"uploadDate": "2019-05-23T12:21:19Z",
"sha256": "9c377f34d5227b0ce476146b0b63ec04fcb73a386eca663399fe1a988b7cc771",
"ticketContents": null,
"issues": [
{
"severity": "error",
"code": null,
"path": "WPExport.zip/WPExport.app/Contents/Resources/Files/rsvg-convert/libxml2.2.dylib",
"message": "The binary uses an SDK older than the 10.9 SDK.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "WPExport.zip/WPExport.app/Contents/Resources/Files/rsvg-convert/libiconv.2.dylib",
"message": "The binary uses an SDK older than the 10.9 SDK.",
"docUrl": null,
"architecture": "x86_64"
}
Apple won’t notarize code built on very old SDKs.
The other thing you might look at is where you store your libraries. Look up apple’s tech note TN2206: code shouldn’t really be in /Contents/Resources. It doesn’t produce an error at this point, but I’d be inclined to follow apple’s guidelines where possible.
Feel free to use it.
Thanks for the icon! We are working on a few ideas for an SD Notary icon and I’ll add this to the mix.