Hi,
As I understand it, the only way to code sign applets (or script bundles) made with SD 8 is to notarize them. The possibility to save code signed applets without notarization is gone.
However, in my case, while code signing is necessary – notarization is an unnecessary and time consuming process.
In my organization applets ( a lot of them) are distributed to our client and servers by locally run applets that copies them (along with other files) from a file server when necassary. That process does not require notarization.
Code signing, however, is necessary to prevent the system integrity dialogs from showing up more than the first time an applet is run. With code signed applets, automation of other applications, network volume access and so one, will be allowed once and for all the first time an applet is used. Unsigned applets means a lot of clicking every time.
So – I wish for a come back of the possibility to save code signed applets (and script bundles) directly as soon as possible. (That feature was the main reson for me to start using Script Debugger instead of Script Editor).
I think version 8.0 codesigns by default when saving. At least, that’s what I remember from a previous post, and every time I save an applet, SD displays a message saying something like “Codesigning…”
Do you mean each time they are run, or each time a new version is copied from the server?
It does when running under macOS 11.x, because it’s required for native Apple silicon code.
I mean each time they are run.
I haven’t tried if there is any difference with applets saved from SD 8, though.
That’s interesting. So SD just picks a developer ID key stored in the Keychain (or one of them)?
But only with Big Sur? So what about Catalina?
The rules have changed between versions, but code signing essentially has three roles:
-
Satisfying Gatekeeper, which has, since 10.14, required signing with the hardened runtime and notarization;
-
It is a requirement for Apple Silicon native code. This means that all applets saved from 11.x are always signed (so presumably @emendelson is running 11.x.). In theory Apple could have chosen to sign just the arm64 applet binary, but they didn’t.
-
At launch (or any time) a signed item can be checked to see if the seal has been broken (in which case it won’t launch, not even via -control-open).
Code signing is not involved in authorizing automation of an app (at least, as far as Apple says, and I can test). That said, it can appear to make a difference because signing as done in SD7 and Script Editor also lock the applet’s main.scpt file (making it a read-only file, not to be confused with run-only code), so that it can’t be modified. (If it could, it would obviously invalidate the applet’s signature.)
If you’re being asked to authorize repeatedly, it’s because the applet is being modified when run. That happens when top-level values in a script change, and locking the main.scpt file stops that modification from happening.
In SD8 there is a setting in Preferences → Build → Saving Applets to Lock main script. This should stop an applet from modifying itself each time it runs, the same as SD7-style signing.
The other option is to export rather than save. In the File → Bundle & Export Settings dialog, there is an option to Sign bundles and applets to run locally. This is always done when running under 11.x (as per above), but can also be turned on under earlier versions.
No. Default signing under Big Sur is what is called ad-hoc signing, or signing to run locally. It does not use any identifying certificate.
Only with Big Sur. When run under Catalina, SD8 does not produce universal applets. This a system-level thing.
Let me try to explain the process of saving an applet.
When you choose save or export, the code and destination are passed to an Apple function, which then saves a “raw” applet.
Script Debugger (or Script Editor) then modifies that applet. If it’s not a first save, any resources the user added are copied from the previous version. If it’s not run-only, Script Debugger adds the file for QuickLook and recovery. And it makes any necessary changes to the applet’s Info.plist file.
If you code sign using Script Debugger 7 or Script Editor, the permissions for the bundle’s main.scpt file, which stores the script itself, are first changed to read-only, to stop it being modified when the applet is run. Then the applet is signed.
The process is more complex when running under Big Sur. When the code is passed to Apple’s function to save, the OS checks to see if the calling app — Script Debugger or whatever — was compiled against the Big Sur SDK. In other words, whether it’s an app built to cope with the new requirements, or not.
In the case of Script Debugger 7 the answer is no, so the process continues just as above, producing an Intel-only applet that runs under Rosetta on Apple silicon Macs, the same as if it were saved under an earlier version of the OS.
In the case of Script Debugger 8 the answer is yes, so the applet produced is universal: it has both both Intel and arm64 native binaries. It is also, by default, ad-hoc signed, because arm64 code will not run unless signed.
Because Script Debugger needs to modify the bundle, it does it itself after making the changes outlined above.
Another slight difference with Big Sur is that universal binaries do not need to have their main.scpt file locked, because universal applets never modify it (hence properties never persist in universal applets). This is enforced by the use of quarantine attributes, so no changing to read-only is required. But if such an app is run on an earlier system, and someone removes all quarantine attributes from it, it will self-modify and hence render itself invalid.
Thanks for some very clarifying answers, @ShaneStanley
I guess quarantine attributes is something that can only be removed deliberately. So if I save applets from Big Sur it’s quite safe to save them without locking main.scpt – even for use in macOS 10.14 and 10.15?
I also assume this is not the case when creating applets in SD8 on macOS prior to Big Sur (as I sometimes have to application compatibility issues). So if I create an applet with SD 8 on macOS 10.15, main.scpt should be locked to avoid repeated authorization dialogs?
Yes to both. Under Big Sur, probably the bigger risk is someone editing a script. For that reason (among others) I’d recommend exporting run-only versions for distribution.
Several of the changes in Script Debugger 8 might not be obvious, but they aim to simplify the process for people who write and distribute scripts. The combination of the new Preference → Build settings, the File → Build & Export Settings dialog, and Direct Export can help both organize and automate distribution. I recommend you have a look at them, both here:
and in Script Debugger Help.
Yes, those changes seems very helpful. I’ll take a look at them soon.
Thanks!
Actually, it seems to me, code signing do play a role here. I found out there is an important difference in this respect between applets code signed by SD7 and applets saved from SD8 on Big Sur:
In the former case users can allow automations of other apps and network volume access once and for all. Really once and for all. They don’t have to go thru that process again every time an applet is updated. That’s the behaviour I’m used to.
But what I found out after a little experimenting is that with applets saved from SD8, those dialogs pops up againevery time there is a new version of the applet. That can get quite annoying.
So I’m kind of back to box one here.
Let me look at it further. That sounds like the sort of think Apple is likely to decide is a security hole and plug at some stage.
Have you tried signing an applet saved from Script Debugger 8 on Big Sur at the command line, to see if the behavior holds for universal applets?
No not yet, but that suggests a workaround for my case.
I had a look at the new export options in SD8. I think they are great and believe they make the process easier for most people. But they are not useful in my (probably quite unusual) case.
In my case, because of how the deployment process works, I have to copy the applets (and scripts) to different places in different folder hierarchies. For that I use my own tools. Also, I prefer the scripts to be read-able so that they can be easily tested and troubleshooted in their destination environment.
So for me, exporting the applets is just an extra step and run-only applets it is desireable.
However, if signing from the command line gives the desired result also with universal applets, I could just add code signing to my deployment tools. That would make SD8 usable also in my special case.
That’s based on my assumption that code signing make automation allowances stick for each applet – even between code changes.
That assumption are in turn based on my experience that applets saved from SD8 triggers the integrity dialogs to show up for every new version, whereas for code signed applets from SD7 you click OK in each dialog once and for all.
Right, but permission is granted to apps, not any scripts they might run. So if an app running scripts is asked to approve scripting the Finder, then it shouldn’t need to ask again for any new scripts it might run.
I guess I’m trying to understand why one might want sign a script bundle, as opposed to app.
So it works. Therefore storing the main part of your code in a script that’s ran from the app reduces the numbers of times you have to update the app – and hence the number of occasions for uses having to click their way thru integrity dialogs for unsigned apps. That’s how I have done it more and more, and now I might have another reason to continue in that direction.
I don’t know 
I seldom use script bundles.