[JW Lua] New security features in upcoming RGP 0.67

Wed Apr 12 17:43:04 CEST 2023

Yes, that's a good point.

Aaron.

On Wed, Apr 12, 2023 at 11:39 AM Robert Patterson <
robert at robertgpatterson.com> wrote:

> 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
>>
> _______________________________________________
> 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/11c2cdab/attachment.htm>