[JW Lua] New security features in upcoming RGP 0.67

[Robert Patterson]

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