When I submit my app with SD Notary, the processed app gives an error message:
Apple’s FileMerge says main.scpt are different, but since they are run-only, I can’t see what the problem is. Any suggestions?
Assuming stapling succeeds, the original file you selected is copied into the folder called Unmodified Original.SD Notary does nothing else to that file.
In the actual notarised copy of the app, the changes are the removal of all extended attributes and resource forks, marking of the main.scpt file as read-only, plus inside-out code-signing.
It sounds like something different in how the files were generated.
The modified main.scpt was because of running the app. So apparently run-only scripts also get modified on disk…
However, the problem didn’t go away. Right after I build the app, it run just find. After it has been notarized and stapled, it will generate this error -4960.
I build the app from an .applescript text file with osacompile. The script itself is under 600 lines, so not big at all. It embeds some Script Libraries, a 3rd party app, shells scripts and some binaries (psql and dylibs for accessing postgres).
So before it just runs, and after it generates an error, even the unmodified one. Do you have any ideas what the problem is, or what I can try to remedy this problem?
Not really. The original file is involved only twice: it gets copied into the working folder, where the copy is processed, and assuming all goes well, it gets moved into the Unmodified Original folder.
Are you using osacompile to build a .app file, or a main.scpt file? Where are you putting the binaries? Is the third-party app signed?
If you can email me the app, I can have a look.
I generate the app like this: osacompile -x -o my-script.app my-script.applescript. Afterwards, I update the Info.plist, and copy some resources. I’ll send both binaries (a fresh one that works, and a notarized one) to the support email address.
It’s solved. In the end it had to do with absolute symbolic links to Script Libraries. Because I use Script Libraries that call other Script Libraries, I replaced all but one with a symbolic link.
Only after rigorous research by Shane Stanley (thanks Shane!) I found out I mistakenly created absolute symbolic links instead of relative ones. After I fixed these, the error message was gone!
