Thanks, that’s helpful.
To be clear, I meant checking if an app is signed, not checking if it is notarized.
To notarize a DMG the apps inside need to signed. They don’t have to be notarized.
Ah - apologies. I should have trusted that you were using the right terminology. To test whether something is codesigned, use
codesign -dv /path/to/app
1 Like
What would cause SD Notary to fail to sign an app? I’m asking because in my script so far every app I’ve sent has successfully signed, so I don’t know what the behavior will be if signing fails.
At this point it’s just an unhelpful error trap displaying a dialog indicating something went wrong, but I don’t even know if SD Notary trips an AE error when it fails or indicates that in the result. (I’m not going to use the dialogs showing option).
Any suggestions?
This script generates an error:
tell application "SD Notary 2"
if status of window 1's document is "ready" then
close window 1
end if
end tell
I’ve tried various version of closing a window, but it just doesn’t get it.
AppleScript Execution Error
SD Notary 2 got an error: window 1 doesn’t understand the “close” message.
After signing all the apps in a folder SD Notary has a bunch of open windows. My plan is to check that the staus is ready, and close the window.
The codesign command has a -v verify command.
You’ll get an error message. SD Notary uses the codesign tool to sign, and if it fails, it will pass back the error codesign returns. There are other possible errors, but they’re highy unlikely and should be self-explanatory.
OK, Unlikely errors are my specialty 
So, I’ll just go with an error alert and skipping processing for that app, and failing the pre-flight so it doesn’t try to make a dmg or submit.
That should work.
Speaking of errors…
So I’m trying signing with different applets and it seems to consistent error on some. If they have anything in common I think they are old applets that haven’t been edited in some time (years)
Here’s what the error messages are saying:
Could not be signed.
Error message:Error Signing Code: Error 105553138708864 in codesign: /Users/edstockly/AppleScript/TV ScriptPalette copy/101)Edit Press Credentials (app) - Working/101)Edit Press Credentials (app).app: replacing existing signature
/Users/edstockly/AppleScript/TV ScriptPalette copy/101)Edit Press Credentials (app) - Working/101)Edit Press Credentials (app).app: code object is not signed at all
In subcomponent: /Users/edstockly/AppleScript/TV ScriptPalette copy/101)Edit Press Credentials (app) - Working/101)Edit Press Credentials (app).app/Contents/MacOS/applet (2)
Error number: 1110
There’s something about the object is not signed at all. Does codesigning in Notary not work on really old applets? (I get the same error from the UI or via scripting.
It’s quite possible. Can you send me the applet?
If they’re all like the sample you sent, something weird has gone on at some stage. An app’s folder /Contents/MacOS/ should usually contain a single binary file called applet. The sample app contains four extra files, called applet (1) etc. Remove those and it should work fine – although I’d recommend a save as.
Unfortunately in cases like this the codesign tool gives no explanation – as far as it’s concerned, it’s just an app that can’t be signed.
I’ve no idea how the applet got like that – those extra files look recent.
1 Like
FYI, the sample script in the release notes should be updated with the Notary 2 application id:
tell application id "com.latenightsw.Script-Notary2" -- SD Notary.app
Also, from the release notes,
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.
I’ve had to create a new app-specific password on each of the two Macs I’ve installed on. (I’ve got two more I can try)
I’ve tried several apps on a different Mac and they have all failed. Nothing on this Mac has been notarized. Here’s the error statement returned to the script:
Error Uploading File: Error 105553150223216 in xcrun notarytool submit: <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>id</key>
<string>fff6b7c3-5f45-45b0-8f97-746b5e708b49</string>
<key>message</key>
<string>Timeout of 1800 second(s) was reached before processing completed.</string>
</dict>
</plist>
Error number: 7
I’ve looked inside the package contents and only one “applet” file.
Also, is it possible that changing an applet to a droplet and back again a few times could be causing the duplicate “applet” files?
EDIT:
Note, these failures are from using the sample script in the release note. The same file successfully gets notarized using the user interface.
There’s either something strange with those apps, or Apple’s service is having one of its bad days. (Yes, that happens more often than it should.)
When I modified the sample you sent me to remove the illegal contents, it timed out twice for me. Some (long) time later, out of curiosity, I used (see note below) File -> Info For... -> Last Submission and got the following:
"status": "Accepted",
"statusSummary": "Ready for distribution",
That means it can be stapled using the Staple Only... button.
My suspicion is that it’s a combination of both Apple’s servers and something about the file, but I have no hard evidence of either.
At any rate, the key message here is that when it times out, you can always check what happened later.
I guess – can you repeat it?
Note: I tried to use File -> Info For... -> Last Submission and found a bug: it returned the result of an earlier submission. The bug will be fixed in the next version. In the meantime, you can use Fetch History, copy the UUID, and then use File -> Info For... -> UUID on Clipboard .
FYI, I now have a pre-flight routine that looks in the MacOS directory and removes the extra files, keeping only one file named “applet” or “fancydroplet”
That seems to work.
That file that you tested worked for me after removing those items and submitting via the user interface. It also worked when I changed the property settings for the document from the sample. I’m wondering if you’re submitting via the UI or the Scripting interface of Notary, and what your settings are.
This worked:
set newDoc to make new document with properties {allow library loading:true, create disk image:true}
Via the UI, with default settings.
Is there a guide somewhere to what the error numbers mean? I’m getting an “error 6”
Notary Submission Error number: 6
SD Notary 2 got an error: An error of type 6 has occurred.
That’s the error when sending a dmg via appleScript. The same dmg succeeds manually.
tell application "SD Notary 2"
set submittingDocument to make new document with properties {allow library loading:true, create disk image:true}
tell submittingDocument
--admg is a variable with dmg file path
set notarizedDocument to submit app at aDMG
end tell
end tell
Hold fire on the scripting stuff. A couple of new problems have cropped up.
1 Like
I got a note today from Apple saying that altools is depreciated for notarising Apps does SD2 use the new method?
Yes. See the release notes linked to in the first message of this thread.
Sorry read the notes after I posted 