One thingto keep in mind: if developer certificates were free, Joe Blackhat and friends would download them by the thousand and Gatekeeper would essentially be rendered useless.
That said, you shouldn’t be getting asked for permission each launch. That sounds like your code is being altered each time. Try making the .scpt file(s) in your app execute-only (use chmod and a-w or similar).
Shane, what I’m seeing is that once saved, I can run applets on Mojave and I’m only asked for permission to run once. However, each time I save the applet, I’m prompted once more for permission to run the applet.
Thank you, yes, I can see that although maybe blackhats are dissuaded by the process more than the fee. I’ve hoped there could be some other arrangement perhaps with extra rules for hobbyists but Apple seem to be pushing hobbyists out of the field.
I don’t understand the significance of the comment about global variables. I do have global variables which store values used in my script and which change – eg. path name to a folder which the user can change. Because they are not constants and need to be available to a number of handlers, I’m declaring them as global variables eg.
global downloadsFolder_Path
at the beginning of the script and setting the values when needed eg.
set downloadsFolder_Path to (POSIX path of ( path tohome folder ) & downloadsFolder)
But, I can confirm that although System Preferences show my applet has permission to control Finder and System Events, I have to give permission again each time the script is run.
Would it make any difference if I declared those global variables as local then, passed them to and from each handler ? Also, my applet is not run only. Is that relevant ?
When a script is run, if that results in changes to the value of any top-level variables, the script is normally saved back to disk with the new values. (This is how property persistence works.) That means the security system sees the app has changed, and thus needs renewed permission.
One relatively simple way to stop this is to change the permissions of the applet’s embedded main.scpt file.
Yes. But you also need to make sure there are no top-level variables changing.
No.
Wrap any code in lines consisting of three back-tick characters.
Shane, thank you for all that. I’ve vented some rant in another post.
Yes, my script has a pile of global variables. But, in good news, I’ve found that Mojave does not show the permission request every time the app is started – if the user does a logoff and a logon. So, in summary for a non-code signed AppleScript applet:
For new version of the applet – Mojave pops the permission request(s) on applet start-up.
For each further applet start-up in the same session – Mojave pops the permission request(s).
For each further applet start-up in later sessions – Mojave does not pop the permission request(s).
I think I can live with giving new permissions when installing a new version of my applet.
The whole thing of logging off and on again to suppress the dialogs is odd to me – if there is a concern about security in this situation, why let a logoff-logon suppress the dialogs ? That might be a bug and so Apple may well change that behaviour in a future release of 10.14.
By default, the scripts in applets are saved with -rw-r--r-- permissions. Could it be that you’re logging in the second time as other than the original file’s owner?
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
on open fileList
repeat with aFile in fileList
do shell script "chmod a-w " & quoted form of (POSIX path of aFile & "/Contents/Resources/Scripts/main.scpt")
end repeat
end open
Or:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions
-- classes, constants, and enums used
property NSFilePosixPermissions : a reference to current application's NSFilePosixPermissions
property NSFileManager : a reference to current application's NSFileManager
on open fileList
set fileManager to NSFileManager's defaultManager()
repeat with aFile in fileList
(fileManager's setAttributes:{NSFilePosixPermissions:292} ofItemAtPath:(POSIX path of aFile & "/Contents/Resources/Scripts/main.scpt") |error|:(missing value)) -- 292 is decimal equivalent of -r--r--r--
end repeat
end open
On Mohave, can I have a standard AS applet that is code signed and saved as run only which contains a helper applet that is also code signed and saved as run only?
I have just tried making my helper applet run only and now the main applet on launch warns me that the file might be damaged etc and then quits.
I thought I might have read something about this somewhere but maybe it was to do with library scripts rather than helper apps. I thought having the helper apps saved as run only might be a good thing for security but seems the system doesn’t like it.
And incidentally should I be choosing to make script libraries run only? Or perhaps what I’m really trying to ask is: can I make the script libraries run only?
Another question. I have an AppleScript app that does impositions in InDesign. It is running fine on the one Mac we have currently running Mojave. However an AppleScript droplet that sends emails gives the error that the application could not be opened. Why does one work and the other doesn’t?
There is no requirement to codesign except if you want to pass muster with Gatekeeper. Please read the article pointed to in the first post of this thread.
Very helpful article. Thank you Shane. However, I’m still having an issue with a droplet. We added the app to the Full Disk Access tab in the Security & Privacy System Preference. If I comment out the On Open and End Open lines and use a Choose File command instead, the script runs fine on the Mojave machine but trying to use it as a droplet with an On Open command gives a “The application could not be opened” error. Do you know why this is happening?