Adding `FCLuaScriptItem` and `FCLuaScriptItems` to RGP Lua and JetStream Controller

[rpatters1]

I've been working on an idea that @Nick-Mazuk requested to be able to execute scripts from a different U.I. designed in Lua itself. To that we added the capability to add scripts on the fly. Today I suddenly realized this is going to address a JetStream Controller requirement as well.

Right now the program pops up an annoying dialog and enters a number which then executes a script. Well, with this new feature (coming in 0.64), your script will be able to fish its own item out of the list, modify the prefix on the fly, then re-execute itself with a different prefix. The details are a little more complicated than that, but I think it will work.

Sound interesting? If so, I'd be interested to know a little more detail on the design of the JetStream Controller now. The sequence is

• KM or Applescript executes the dialog box and fills in the code specifying which item to run
• Is that then a require statement within the script? (I suppose I can look at the source code now. Lol.)

@CJGarciaMusic @jwink75

[Nick-Mazuk]

This issue will probably answer your question of how the JetStream currently works in case you don't want to dig through all the source code: CJGarciaMusic/PowerUserWorkflow#11

In short, there isn't any require statements at the core of the JetStream. Just a big switch statement (built with if-thens) to execute the right function.

[rpatters1]

I have uploaded tentative documentation to the master branch of the PDK Framework Docs Repo. To review it:

• Clone the repo to your local drive by downloading the zip file (easiest).
• Open the first html file with your browser. (I believe it is called annotated.html.)
• Navigate to FCLuaScriptItem.

Feedback is much appreciated before I get too much further into it.

[rpatters1]

On further reflection, I realize this does not address the fundamental challenge for JetStream Controller: that of passing a trigger value from the controller to the Lua script. But maybe this will be useful in a future refactoring.

[Nick-Mazuk]

Ok, just to make sure I understand the docs, if I were to want to run a script I could do something like this?

local script_to_execute = "My script's name"
local script_items = finenv.CreateLuaScriptItems()
for item in each(script_items) do
    if item.GetMenuItemText() == script_to_execute then
        finenv.ExecuteLuaScriptItem(item.GetExecutableIndex())
        break
    end
end

This seems like a good API to me. Couple questions/thoughts, though:

1. It looks like you can add a script using finenv.AddLuaScriptItem? I assume this would not add scripts to the menu bar and any added scripts would not persist between Finale restarts, but just want to double-check.
2. Likewise, I assume methods like SetMenuItemText would not update the menu bar and the changes would not persist to the next session. I also assume it wouldn't update the source file.
3. GetPrefix: what does this do? I can't think of what a script prefix is.
4. AddLuaScriptItem seems like a security issue. Usually a user needs to download the script, and then they've implicitly consented to running that script. However, I could see someone creating a malicious script that adds a new script then immediately executes it. This other Lua script doesn't even necessarily need to be a script the user downloads. Now, would I think this ever would happen? No. Would it be easier to just write the malicious Lua code directly in your script? Yes. Would it be even easier to just execute an arbitrary terminal command (which is already possible)? Yep. But still, I can't think of a reason why someone would want to add a new script that's compelling enough to add another attack vector. With that said, I'm not against this feature since in reality it doesn't let a malicious user do anything new, but I think it's something to think about.
5. SetFilePath this seems like a security issue. Let's say we have three scripts, A: "a.lua", B: "b.lua", and C: "c.lua". "c.lua" as some malicious code and may not even be a Finale Lua script. A uses SetFilePath to change the file of B to "c.lua". User tries to run "b.lua" by clicking on "B" and accidentally runs "c.lua". Whoops! They've now run malicious code. There are the same caveats as above, though.

[rpatters1]

1. You can't change the menu bar, so no.
2. See 1. SetMenuItemText doesn't have much use to Lua scripts.
3. GetPrefix allows you to supply a Lua snippet that runs before the script does.
4. AddLuaScriptItem is how you are going to execute a script on the fly. I don't see this as fundamentally more dangerous than a script that (as you say) does the malicious code without it.
5. SetFilePath cannot change already-configured script items. Its primary use is for creating a new item to execute on the fly. CreateLuaScriptItems makes a copy of the already-existing items and it does not allow you to copy them back. Only add new ones.

[Nick-Mazuk]

I see. I think that eases my concerns. LGTM.

[jwink75]

It used to be a UserValueInput box, but now it’s just a small CustomLuaWindow with an entry box. There is now code in there that parses multiple commands, and also code that accepts multiple different input values beyond the 4-digit codes. This lets you put in, say “p < -f” and it will execute functions to add a starting p dynamic, add in a hairpin, and add a f dynamic at the end. I’m actually going to modify this further so that it will accept “p < f” and turn the second dynamic into an “end” dynamic. I actually LOVE the little dialog box and don’t want to lose it, but if there is a way to pass the plug-in arguments without actually opening it that really would be slick.

…

On Jul 30, 2022, at 3:35 PM, Nick Mazuk ***@***.***> wrote: Ok, just to make sure I understand the docs, if I were to want to run a script I could do something like this? local script_to_execute = "My script's name" local script_items = finenv.CreateLuaScriptItems() for item in each(script_items) do if item.GetMenuItemText() == script_to_execute then finenv.ExecuteLuaScriptItem(item.GetExecutableIndex()) break end end This seems like a good API to me. Couple questions/thoughts, though: It looks like you can add a script using finenv.AddLuaScriptItem? I assume this would not add scripts to the menu bar and any added scripts would not persist between Finale restarts, but just want to double-check. Likewise, I assume methods like SetMenuItemText would not update the menu bar and the changes would not persist to the next session. I also assume it wouldn't update the source file. GetPrefix: what does this do? I can't think of what a script prefix is. AddLuaScriptItem seems like a security issue. Usually a user needs to download the script, and then they've implicitly consented to running that script. However, I could see someone creating a malicious script that adds a new script then immediately executes it. This other Lua script doesn't even necessarily need to be a script the user downloads. Now, would I think this ever would happen? No. Would it be easier to just write the malicious Lua code directly in your script? Yes. Would it be even easier to just execute an arbitrary terminal command (which is already possible)? Yep. But still, I can't think of a reason why someone would want to add a new script that's compelling enough to add another attack vector. With that said, I'm not against this feature since in reality it doesn't let a malicious user do anything new, but I think it's something to think about. SetFilePath this seems like a security issue. Let's say we have three scripts, A: "a.lua", B: "b.lua", and C: "c.lua". "c.lua" as some malicious code and may not even be a Finale Lua script. A uses SetFilePath to change the file of B to "c.lua". User tries to run "b.lua" by clicking on "B" and accidentally runs "c.lua". Whoops! They've now run malicious code. There are the same caveats as above, though. — Reply to this email directly, view it on GitHub <#287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMCBUQ22JJZ6FCRPR4DPV5TVWWUZTANCNFSM55DZFJMQ>. You are receiving this because you were mentioned.

[rpatters1]

Actually, based on your feedback (@Nick-Mazuk ), I realized the Add and Delete APIs are probably unnecessary. All we really need is Create (collection) and Execute. The Execute method can execute one you create from scratch, which allows for on-the-fly additions.

FWIW: I can't see any increased security risk from Execute over what is already there with require. The Execute API just allows for the script to get its own Lua state.

[rpatters1]

With excellent feedback from this thread, I think I have zeroed in on a workable set of APIs that preserves a modicum of security. There will basically be two flavors of FCLuaScriptItem depending on how you construct them. (You will have to construct them with one of the two finenv functions. I've removed the Lua-accessible constructors.)

• Items from Finale's plugin menu.
• Adhoc items.

Items from Finale's plugin menu will be launch-and-forget and behave exactly as if you launched them from the menu. As a security precaution, your launcher script cannot see the file paths for them. (It occurred to me that a malicious script could rewrite third-party scripts if it knew where they were. This allows you to launch them without knowing anything about them other than their menu and other descriptive text.) Furthermore, the only thing that matters for these scripts is the (read-only) "execution index". No changes you make to the script item have any effect on the launching of these scripts. (Specifically, changing the prefix has no effect.)

Adhoc items will allow you to launch any file of your choosing. If it isn't proper Lua, of course, you'll just get an error. The big difference with these is your script has to stay alive as long as the launched script stays alive. For scripts with modeless dialogs and retained lua states, this is longer than just a single script invocation. Also, the properties on FCLuaScriptMenu do matter for these. Especially, the prefix, undo text, and booleans.

I've updated the docs at the doc repo.

If you would like to try out a prerelease version of it, you can download it here. No guarantees on how long the link stays up. But a few days at least. The Apple version is not notarized, so the usual rigamarole will be required to bless it.

[rpatters1]

P.S. I've also hooked up FCCtrlComboBox in the same version in the link above.

[rpatters1]

P.P.S. I removed the constructor on FCLuaScriptItems as well, but I now realize that was a mistake. It'll be restored in the next version.

[Nick-Mazuk]

Awesome, thank you Robert!

[rpatters1]

I've been thinking that a script-launching script might like to have access to some of the other finaleplugin fields. The tradeoff is between security (not revealing too much about a script to 3rd parties) and usability of the launcher. The ones that occur to me are

Notes
Categories
ScriptGroupName
ScriptGroupDescription
required min max versions

Any others?