[JW Lua] New security features in upcoming RGP 0.67

Wed Apr 12 17:38:18 CEST 2023

Suppose a script requires running at startup to either make sense (like the
finale menu organizer) or for some initialization. I think this requirement
should be made explicit. I'm not particularly eager to make running at
startup easy. I think both the developer who wrote it and the user who uses
it should mutually agree that it is a good idea.

On Wed, Apr 12, 2023 at 10:31 AM Aaron Sherber <aaron at sherber.com> wrote:

> If there were no ExecuteAtStartup flag, then no script in an auto folder
> would be asking to run at startup -- each would have to be individually
> configured in the dialog to allow it to run. And you're already planning to
> require that kind of individual configuration anyway.
>
> Again, I don't have a strong feeling about this, just thinking through the
> possibilities.
>
> Aaron.
>
>
>
>
>
> On Wed, Apr 12, 2023 at 10:54 AM Robert Patterson <
> robert at robertgpatterson.com> wrote:
>
>> Also, without the ExecuteAtStartup flag, there is no simple way to
>> exclude them from an auto folder.
>>
>> On Wed, Apr 12, 2023 at 9:50 AM Robert Patterson <
>> robert at robertgpatterson.com> wrote:
>>
>>> When running at startup, there is no selection. There isn't even a
>>> document. I think a script needs to specify its ability to run at startup.
>>> The script is also able to be run normally unless it specifies
>>> finaleplugin.IncludeInMenu = false. (Or something like that: check the
>>> docs.) There is a finenv property that tells you if you are running at
>>> startup. You could use this to initialize expensive globals and then retain
>>> your state. (Not sure if this ever makes sense, but it's possible. It's a
>>> tradeoff between slow Finale startup vs slow first execution of the script.)
>>>
>>> I don't think it should be easy or obvious for users to disable hash
>>> tracking. Enabling debugging is a way of saying "I am a developer and I
>>> know what I am doing". That's the only condition under which I think hash
>>> tracking should be disabled. At any rate, for this version only
>>> ExecuteAtStartup scripts will be hash-tracked (and then only when executing
>>> at startup), so we can revisit this if we ever decide to expand hash
>>> tracking.
>>>
>>>
>>> On Wed, Apr 12, 2023 at 9:31 AM Aaron Sherber <aaron at sherber.com> wrote:
>>>
>>>> I don't have a strong feeling about this point, but it seems to me that
>>>> the configuration dialog should be able to say "Run this script at startup"
>>>> about any script, which is why I think the flag in the script may not be
>>>> needed. Worst case, the selected script requires an active document or
>>>> region (i.e., isn't appropriate for running at startup) and throws an
>>>> error. A related question: If a script has ExecuteAtStartup, then can it
>>>> only be run at startup, or can it be run at other times as well?
>>>>
>>>> I understand why hash tracking would be turned off with "Enable
>>>> Debugging" selected, but I don't think it's obvious that that option
>>>> should be selected if I only want to turn off hash tracking (and don't
>>>> actually want to debug). I'm not sure how common this scenario is. At a
>>>> minimum, it might be nice to change the label to "Enable Debugging/Disable
>>>> Hash Tracking" or something like that.
>>>>
>>>> Aaron.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Apr 12, 2023 at 9:47 AM Robert Patterson <
>>>> robert at robertgpatterson.com> wrote:
>>>>
>>>>> The ExecuteAtStartup option is needed because it tells RGP Lua that
>>>>> the script can be run at startup. The one is the script saying, "Please let
>>>>> me run at startup." The other is the user saying, "Okay, I'll let you run
>>>>> at startup."
>>>>>
>>>>> If there is a change to the config file, my plan is to pop the config
>>>>> dialog and require confirmation before Finale builds its plugin menus. That
>>>>> way you won't have to restart Finale to confirm it. Your scenario is one
>>>>> reason I'm leaving the config file itself in plaintext.
>>>>>
>>>>> The user configurable option you are looking for is "Enable Debug",
>>>>> which can be applied to an Auto Folder. That will always disable hash
>>>>> checking no matter how far hash checking goes. I wouldn't add another
>>>>> option.
>>>>>
>>>>>
>>>>> On Wed, Apr 12, 2023 at 8:35 AM Aaron Sherber <aaron at sherber.com>
>>>>> wrote:
>>>>>
>>>>>> My $0.02:
>>>>>>
>>>>>> Excluding ExecuteAtStartup scripts from auto folders is a good idea.
>>>>>>
>>>>>> I like the "Allow at Startup" config option -- but then is
>>>>>> ExecuteAtStartup really needed in the script?
>>>>>>
>>>>>> For hash tracking of startup scripts and the config file, I'd like to
>>>>>> avoid anything that requires me to restart Finale after confirming -- it's
>>>>>> just a (minor) hassle. Could there be at startup a dialog that says (in
>>>>>> friendlier language) "Changes detected in xxx....proceed?" Clicking Yes
>>>>>> would confirm the new hash and then allow things to be loaded right away.
>>>>>>
>>>>>> As a side note, avoiding Finale restarts is one reason that I
>>>>>> sometimes edit the config file directly before starting Finale, instead of
>>>>>> starting, making changes in RGP Lua, and restarting. If Finale is now going
>>>>>> to notice the changed config file and make me restart anyway, then I lose
>>>>>> that shortcut.
>>>>>>
>>>>>> I am opposed to hash tracking of all script files, unless it's a
>>>>>> user-configurable option. I have the Lua-Scripts repo dist folder set as an
>>>>>> auto folder, and periodically I pull the latest. It would be a hassle to
>>>>>> have to reconfirm any changed files.
>>>>>>
>>>>>> Thanks,
>>>>>> Aaron.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 11, 2023 at 10:09 AM Robert Patterson <
>>>>>> robert at robertgpatterson.com> wrote:
>>>>>>
>>>>>>> This is to give this list a heads up on new security features coming
>>>>>>> in 0.67. It will particularly affect people who distribute their plugins
>>>>>>> with a custom configuration file. (Jan Angermüller and Jacob Winkler, I'm
>>>>>>> thinking of you guys.)
>>>>>>>
>>>>>>> I started thinking about vulnerabilities and realized that the
>>>>>>> biggest one is the new ExecuteAtStartup scripts. They could be installed
>>>>>>> and run without the user ever knowing. In fact that is happening now with
>>>>>>> the menu organizer script. Anyone who has an Auto Folder set up on the
>>>>>>> Lua-Scripts repo is running that script, whether they know it or not. It's
>>>>>>> just not doing anything if no menu config file is present.
>>>>>>>
>>>>>>> 0.67 will address this as follows:
>>>>>>>
>>>>>>>    1. ExecuteAtStartup scripts will be excluded from Auto Folders.
>>>>>>>    You will have to explicitly configure them.
>>>>>>>    2. When you configure an ExecuteAtStartup script you will have
>>>>>>>    to explicitly permit it to load at startup with a new "Allow at Startup"
>>>>>>>    option. Otherwise, even if it has requested ExecuteAtStartup it will not do
>>>>>>>    so. (A script will need both to have requested it and for the user to have
>>>>>>>    permitted it before it runs at startup.)
>>>>>>>    3. A hash will be calculated and stored for ExecuteAtStartup
>>>>>>>    scripts and RGP Lua will refuse to load them if the hash changes. (The user
>>>>>>>    will have to reconfigure it by going into the edit dialog and hitting OK
>>>>>>>    before it will load again.)
>>>>>>>    4. The RGP Lua configuration file will also be hashed, and the
>>>>>>>    user will be forced to reconfirm the configuration if the config file is
>>>>>>>    modified externally to the RGP Lua plugin itself.
>>>>>>>    5. Indeed, I am migrating towards hash tracking of all script
>>>>>>>    files, but for 0.67 only the hashes for ExecuteAtStartup scripts will be
>>>>>>>    tracked.
>>>>>>>    6. If a user enables debugging on an ExecuteAtStartup script
>>>>>>>    file, it disables the hash checking. (That will be the plan even if all
>>>>>>>    scripts start being hash checked.) So enabling debug is going to be more
>>>>>>>    than ever something that should only be done when actual debugging is
>>>>>>>    taking place.
>>>>>>>
>>>>>>> My question for anyone who is using custom configs is, do you want
>>>>>>> RGP Lua to hash-track them as well? My main reason for hash-tracking the
>>>>>>> primary config file is that it is at a published location. Hash tracking
>>>>>>> custom-config files would create challenges for installation. I'm leaning
>>>>>>> towards not tracking them, at least in the initial version of
>>>>>>> hash-tracking. If you feel strongly one way or the other, let me know. If
>>>>>>> we are going to hash track them, you have to have a way to install a new
>>>>>>> config file without forcing the user to agree to something they don't know
>>>>>>> anything about.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> JWLua mailing list
>>>>>>> JWLua at jwmusic.nu
>>>>>>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>>>>>>
>>>>>> _______________________________________________
>>>>>> JWLua mailing list
>>>>>> JWLua at jwmusic.nu
>>>>>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>>>>>
>>>>> _______________________________________________
>>>>> JWLua mailing list
>>>>> JWLua at jwmusic.nu
>>>>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>>>>
>>>> _______________________________________________
>>>> JWLua mailing list
>>>> JWLua at jwmusic.nu
>>>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>>>
>>> _______________________________________________
>> JWLua mailing list
>> JWLua at jwmusic.nu
>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>
> _______________________________________________
> JWLua mailing list
> JWLua at jwmusic.nu
> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20230412/bc974d1e/attachment.htm>