Anyone having "File & Folders" security issues with 8.0.6?

AppleScript
#1

It appears that the latest update of SD 8.0.6 negatively impacted one of my scripts.

For reference, I have code at the beginning of my script to trigger the “Desktop Folder” and “Network Volumes” security setting prompt at the beginning of the script.

When I create a new run-only export of the script using 8.0.6, when I try to run in on my machine, it will always pull up the desktop prompt on every run of the script. The app will show up in the preferences pane, but only show the “desktop folder” checkbox - the network volumes will not show up. these settings that show up do not affect the script behavior, however, because even though the desktop setting is checked, it will still ask the next time.

Oddly, the network checkbox doesn’t show up at all, even though it does have network access.

I was pulling my hair out trying to figure out what was happening, and I finally found a copy of 8.0.5 on another machine. I replaced the latest version with that one, re-exported a new version from 8.0.5 (all export settings are the same regardless of the version), and ran the script. It ran as expected, prompting both the desktop and network access dialogs, and that created a new entry in the pref pane, that included BOTH desktop and network checkboxes. So I ended up with two entries for my app in the pref pane, even though I didn’t change anything about the export settings (other than using two app versions)

I’m not sure what all that means tbh, and for now I am having to use 8.0.5 to get my deadlines met. Just curious if anyone has seen similar to this, or where I might poke later to provide more specific feedback or potential bug report?

#2

Does your script save the settings in properties? If so, in the short term you can check in Preferences -> Building to see if Lock main script is checked. In the longer run, you need to look at storing your setting another way, because properties will not persist under newer versions of macOS.

#3

I don’t have any settings saved in properties. What I am referring to that is not persisting is the MacOS security settings in System Preferences/Settings app in Security & Privacy > Privacy > Files & Folders. Normally, the first time you access the desktop with the script it will prompt a dialog asking for permission to access the desktop folder. When you click “allow” (or yes or whatever), it will check the mark in the pref pane mentioned. After that, subsequent runs of the script can access the desktop without needing to go thru that prompt.

That is how my script was working. On new installs on machines, the first run would give the prompt, but the security setting would persist afterward, at least until I made a change to that script and updated it.

However, after I updated to Script Debugger 8.0.6, when I would run the exported script on my machine, it would trigger the “allow” dialog on every single run of the script, even if I chose allow previously. Manually checking or unchecking the option in the pref pane had no effect.

The script is saved as run-only, uses my dev certificate, but is not notarized. It is a beefy script I know, but has been working fine in that capacity until I updated to 8.0.6. When I rolled back to 8.0.5 and saved a new version of the same script, the security settings worked correctly again.

While I was having issues, I created test scripts with just the desktop security prompt triggers, and those did work correctly, although they were not saved as run-only/certificate I realize now. I’m just not sure what was causing my script to not function properly under 8.0.6, but works fine in 8.0.5

Once I get past the deadline I have, I may have more ability to try 8.0.6 again to see if the issue comes back.

the only thing I noticed once I finally got it working was that the 8.0.5 saved version seemed to create a separate entry in the “files & folders” pref pane than the broken one under 8.0.6, even though the bundle ID, name, export settings would/should have been exactly the same. Is there anything in 8.0.6 that would change how MacOS Monterrey would see the apps than 8.0.5 would?

#4

I suspect the solution is to turn on the Lock main script setting I mentioned above. When that setting doesn’t persist, it’s a sign that the applet is being modified when run (resaving with updated top-level variables). Some versions of the OS used a quarantine attribute to achieve the same end, but it’s less reliable and doesn’t travel well.

#5

I will try that whenever I update again to 8.0.6 - you’ve mentioned it before, I just didn’t lock it because I don’t have properties or anything that should be saving to the script anymore.

Is there something that changed in 8.0.6 that would cause the same script to be ‘modified when run’, that is not ‘modified when run’ when saved by 8.0.5? It’s the same code, but depending on which version of SD exports it, it acts differently.

I’m not sure it is due to the script being modified, though. My initialization code that attempts to trigger the OS prompt does a ‘ls’ shell script command of the desktop folder twice in a row, so that if the user clicks cancel the first time, it would immediately present itself as an issue on the second attempt. The idea is that if it is a brand new install, the first ‘ls’ attempt will bring up the prompt, the user chooses ‘allow’ and the second ‘ls’ prompt happens silently, since the script is approved to allow access. If the first attempt they choose cancel (thereby not allowing desktop folder access), then the second ‘ls’ would fail, triggering a descriptive error dialog. If it is a subsequent run of the script, both of the ‘ls’ attempts would be silent, since the access is allowed.

In the situation my script was in after having been saved under 8.0.6, the prompt was happening twice every time, not just on the first run. Even if the script was modified, I think that would present itself the same is when I make a manual change to the code and re-save - the first prompt only. The fact that the setting is not taking at all, even between a few lines of code in the same run of the script, leads me to think it is not just the script thinking it is ‘new’ again.

There is a very good chance my overstuffed script is in some way the root cause of this, even though it acts differently between the two versions of SD. I’ll try to take some time in a few weeks to update to 8.0.6 again and see if I can prevent the behavior or accurately recreate the situation in a way that explains what may be happening. I just wanted to mention it in case other have seen it too or anything, since I will not be able to ‘deep dive’ into it again for a bit. I’ll need to eventually update to 8.0.6 again though, assuming some sort of bug isn’t found that is what is causing this - so I’ll have to come up with something.

#6

If you have a run handler (or implied run handler) and it sets the value of any variable, then the script is potentially re-saved after running (absent quarantine or locking arrangements above).