[JW Lua] New security features in upcoming RGP 0.67

Robert Patterson robert at robertgpatterson.com
Wed Apr 12 18:06:24 CEST 2023 

I like the pushback, btw. It is very helpful.

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

> 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
>>
> _______________________________________________
> 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/5af94770/attachment.htm>

More information about the JWLua mailing list