[JW Lua] New security features in upcoming RGP 0.67

[Robert Patterson]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20230412/53bc7950/attachment.htm>