<div dir="ltr">Also, without the ExecuteAtStartup flag, there is no simple way to exclude them from an auto folder.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 12, 2023 at 9:50 AM Robert Patterson <<a href="mailto:robert@robertgpatterson.com">robert@robertgpatterson.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.)<br></div><div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 12, 2023 at 9:31 AM Aaron Sherber <<a href="mailto:aaron@sherber.com" target="_blank">aaron@sherber.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Aaron.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 12, 2023 at 9:47 AM Robert Patterson <<a href="mailto:robert@robertgpatterson.com" target="_blank">robert@robertgpatterson.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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."</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 12, 2023 at 8:35 AM Aaron Sherber <<a href="mailto:aaron@sherber.com" target="_blank">aaron@sherber.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">My $0.02:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Excluding ExecuteAtStartup scripts from auto folders is a good idea.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I like the "Allow at Startup" config option -- but then is ExecuteAtStartup really needed in the script?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Aaron.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 11, 2023 at 10:09 AM Robert Patterson <<a href="mailto:robert@robertgpatterson.com" target="_blank">robert@robertgpatterson.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>0.67 will address this as follows:</div><ol><li>ExecuteAtStartup scripts will be excluded from Auto Folders. You will have to explicitly configure them.</li><li>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.)</li><li>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.)</li><li>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.</li><li>Indeed, I am migrating towards hash tracking of all script files, but for 0.67 only the hashes for ExecuteAtStartup scripts will be tracked.</li><li>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.</li></ol><div>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.</div><div><br></div><div><br></div></div>
_______________________________________________<br>
JWLua mailing list<br>
<a href="mailto:JWLua@jwmusic.nu" target="_blank">JWLua@jwmusic.nu</a><br>
<a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" rel="noreferrer" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br>
</blockquote></div>
_______________________________________________<br>
JWLua mailing list<br>
<a href="mailto:JWLua@jwmusic.nu" target="_blank">JWLua@jwmusic.nu</a><br>
<a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" rel="noreferrer" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br>
</blockquote></div>
_______________________________________________<br>
JWLua mailing list<br>
<a href="mailto:JWLua@jwmusic.nu" target="_blank">JWLua@jwmusic.nu</a><br>
<a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" rel="noreferrer" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br>
</blockquote></div>
_______________________________________________<br>
JWLua mailing list<br>
<a href="mailto:JWLua@jwmusic.nu" target="_blank">JWLua@jwmusic.nu</a><br>
<a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" rel="noreferrer" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br>
</blockquote></div>
</blockquote></div>