I recently began to code sign my applets, due to Mojave security behaviour, using Script debuggers convenient method for persistent code signing.
But I ran in to a problem: If the app have scripts in it’s resource folder (e.g. script libraries) those bundled scripts get locked – non editable – afterwards. I have so far solved that by going back: removing the code signing (after which the bundled script is still locked), then copying the code from the bundled script to a new script and then replacing the bundled script with the new one in Finder.
Can anyone give me advice about the best way to solve the problem with locked scripts so that I can continue to code sign my applets?
I figure I can save the bundled scripts as script bundles (scptd) and code sign them – but then there will be a lot of code signing to do…
To avoid that, do I have to store the scripts/ script libraries outside the bundle – and deploy them to my organisation that way? Or is there a better way?
Well, I have encountered two problems, one of which has to do with distribution:
When distributing to other machines (in actual cases with MacOS 10.12) – replacing an older non-signed applet with an updated, code signed copy – that other machine will sometimes not recognize changes made in bundled script. I tried to reproduce this problem now, but failed. I will get back to that when I have more facts about the precise circumstances.
Bundled scripts get locked as soon as I code sign it. I guess that’s the way it has to be, but it means code signing is not a good idea with applets that have bundled scripts – since it blocks further editing – unless I check the box to code sign on export. But exporting code signed applets means they have to be run-only (right?) – which makes it more difficult to track problems encountered when run on other machines. Well, as I said, I guess that’s the way it has to be – so I guess a solution is to move those scripts out of the bundle. Or do you have other suggestions?
That sounds like a Launch Services issue. Moving into (and out of again) /Applications or duplicating the file can sometimes force an update.
Exporting won’t make any difference – they’ll still have their permissions changed to read-only.
It sounds like you’re creating a an applet to distribute .scpt file, correct? If so, why not have the applet change their permissions after moving them?
Right. Only if I code sign it upon export only, I at least have a working copy without locked bundled scripts. But then the SG’s convenient advantage to sign an applet one for all is unusable if it has bundled scripts.
Yes, if that works it could be a solution for distribution.
So once I save a signed app it’s bundled scripts gets locked from further editing. But if I can change the permissions for bundled scripts – without the applets functionality versus MacOS security functions being affected – couldn’t SD change the permissions for us every time the bundled scripts are saved?
That would solve not only distribution, but also – since also the scripts in the original applet loses it’s write permissions – make it possible to do further editing on bundled script in the original copy without any special actions.
By the way, the problem with distributed changes not being recognized (as cited below) only happens when they are compiled in SD (so I see it’s not related to code signing). I encountered that problem once again today. Moving the app didn’t help. But opening it in Script Editor, compiling it there, solved the problem.
Just to be clear: the locking is done by changing permissions — they’re the same thing.
At present, SD locks (that is, removes write permissions from) bundled scripts. This is to retain the integrity of the signed package. For example, if an applet is going to launch a bundled applet, it’s important that the bundled applet’s contents don’t change, otherwise the signing will be broken.
That defeats the purpose of code signing, where the signature is meant to guarantee that the contents are unchanged.
One thing to note: if you open applets or .scptd that have been locked this in Script Debugger, you will have the option to save anyway, which will modify their permissions accordingly.
I’m not sure there’s a simple solution that matches all requirements.