Legacy-LuaSTG-Engine
[Feature] Restrict or disable dangerous APIs
WHY?
We can't believe that everyone is good.
Dangerous API
- [x]
os.execute(removed by default) - [x]
io.popen(removed by default) - [x]
lstg.Execute(removed by default) - [ ] ~~
ffi~~
Alternative
- [x]
lstg.ShellIntegration.openFile(done) - [x]
lstg.ShellIntegration.openDirectory(done) - [x]
lstg.ShellIntegration.openUrl(done) - [x]
lstg.RestartWithCommandLineArguments(done)
Showcase
I honestly don't think disabling ffi is a good idea. Some of the western tools (like yabmfr2 for text formatting) uses ffi to communicate with C directly. If you disable ffi, please at least make a flag to turn it on again.
Hey, so... I don't really understand this sudden focus on security? Even if LuaSTG weren't open-source, anyone could just make a modified or fake LuaSTG executable and infect people that way... Just securing the Lua side would not be enough given LuaSTG's common distribution model. The fact that one must re-download the engine every single time will allow bad actors to simply distribute a dangerous copy of the engine. Perhaps man-in-the-middle attacks would be made more difficult (at least to conceal) if encryption is used, as a unique copy of the engine must be compiled to provide the password, but even then it is trivial to convince the user that the game is broken, rather than raising suspicion.
At the end of the day, it is up to the users to keep themselves safe. It is unfortunate that engine maintainers do not have much power here, but limiting developers' freedom will not meaningfully mitigate the security risks.
At the end of the day, it is up to the users to keep themselves safe. It is unfortunate that engine maintainers do not have much power here, but limiting developers' freedom will not meaningfully mitigate the security risks.
There are also many open-source game engines on GitHub, such as Danmakufu, whose scripting language does not provide FFI functionality or even an execute API. But this does not affect creators from creating amazing games.
If creators/developers feel that LuaSTG lacks freedom during coding, it's certainly due to missing features. Unfortunately, this is indeed the case ---- for example, LuaSTG does not support full programmable rendering pipeline.
https://github.com/Legacy-LuaSTG-Engine/LuaSTG-Sub/issues/84
While your assessment that such a lack of freedom is largely due to missing features definitely holds true, I'd argue that a large reason to even use LuaSTG over Danmakufu would be the large amount of extensibility that Lua itself offers, and FFI is not a trivial part of that. (I'd argue that loading external Lua C-API DLLs is also a large part of this too, but I've conceded that argument due to encryption requirements.)
Either way, my point wasn't so much about the lack of freedom these changes pose, so much as the arbitrary restrictions being applied. I'm confused as to why this decision was made in the first place. I don't have any real arguments against removing APIs to execute external programs, though I might take issue with the removal of io.popen, as there is a powerful Lua debugger extension for VSCode that relies on it, as far as I remember...
... But, what would even be the point? I do not see a reason to exploit-proof the Lua side, when the engine executable can easily be faked. You wouldn't even need to have the engine be open-source to place malicious code inside of it... As long as every game comes with a copy of the engine, there will be danger, not from Lua, but from the engine itself.
though I might take issue with the removal of
io.popen, as there is a powerful Lua debugger extension for VSCode that relies on it
Thank you for your reminder. I will provide an additional Dev version executable file in future releases. In the era of LuaSTGPlus, there was a LuaSTGPlus Dev file that would open up more features for developers to debug.
For release ver, popen should not exist as it is the same as os.executable and can run external executable files.
I mean, thanks for the consideration, but it still doesn't answer my question of why this is even being considered... Sure, you may gain an equal level of safety as Danmakufu, but if the distribution method for games involves providing executables, then that level of safety is null. Obviously, games distributed on platforms such as Steam are always checked for malware, so this issue is already non-existent there (even before patching out Lua's attack surface), but as long as independent distribution exists, Lua's ability to execute other programs is the least of our concerns, when the engine itself may house the malicious code.
The only reasoning I can see for these changes would be if there were to be a singular LuaSTG engine executable, through which all possible LuaSTG games are played. If this is a planned distribution model for LuaSTG games, then these changes would make sense to me. But I have not seen any evidence to prove that...
The only reasoning I can see for these changes would be if there were to be a singular LuaSTG engine executable, through which all possible LuaSTG games are played.
Let me explain to you how our (Chinese) community—basically QQ groups—works.
The engine maintainers upload general-purpose frameworks such as LuaSTG er+, ex+, and aex+ to the QQ group files. Developers/Creators use these frameworks to create mods, then upload to QQ group files. Other players in the QQ group can download and play these mods.
In this scenario, nearly all users in QQ groups are using a shared executable file. This is why we want to restrict unsafe APIs.
So they're all downloading the executable and the game modules separately? If so, this set of changes does actually make a lot of sense... Honestly, it is fascinating to me how different the Chinese and Western LuaSTG communities are, and how such issues are approached and received so differently. To us, the change seems unwarranted, but I can see how it is perfectly logical from the Chinese community's point of view. I suppose this just emphasizes the beauty of open-source software, as Westerners can develop their own fork of LuaSTG that serves their needs. I am personally willing to concede my argument here, but I cannot say the same for the other Westerners.
So they're all downloading the executable and the game modules separately? If so, this set of changes does actually make a lot of sense...
Thank you, this is very interesting.
I am personally willing to concede my argument here, but I cannot say the same for the other Westerners.
In fact, the execute APIs are still available—they're disabled by default, just as Flux has done.
https://github.com/Legacy-LuaSTG-Engine/LuaSTG-Sub/commit/963f84bfff5c6dc8cff8b629981f99056343d390#diff-c75c2ca07b039798eb6047b14cdb68bc1c2b2aae8a8aeecbc3fd300b9ea01a73
I am personally willing to concede my argument here, but I cannot say the same for the other Westerners.
The FFI library is a much larger and more complex issue. Some developers have privately asked me whether it's possible to completely prevent Lua scripts from accessing the FFI library.
I will providing an option that is enabled by default, allowing everyone to use the FFI library, while certain projects can simply disable it when customizing their engine.