Open Kefta opened 7 years ago
This would be nice to have
luac compiled code hardly counts as secure in either way, the compiling details are as much known as for lua itself. (every luac compiler version also has a decompiler nowadays, it's not even hard to find them)
All you could try is to add several layers to its implementation to make it harder to break through, but is ultimately wasted effort unless you actually apply some solid encryption around the produced output. (one could try a private key-public key approach but even that isn't guaranteed to be safe)
The issue here is that both server and client need to know how to handle the encryption, and everything exposed to the client can be potentially hacked around.
On top comes the potential exploit ability trough hiding code from inexperienced users (and therefore making it harder to detect them in general) you mentioned, this doesn't count the same way for c++ modules simply because you have to install a c++ module manually for others to take advantage of it. (the source code is only required to be provided to avoid malicious code from the beginning, but nothing's really stopping people from shipping that special code in the deployed dll's anyway)
Another thing is, does luajit which is used by gmod, even have luac available? (As the code produced by luajit is quite different from normal lua)
After that you're left wondering if all this is worth the few milliseconds (or let's it be seconds in the best case) this would improve overall.
What really improves performance is what people create using gmod (there's some real performance hoggers circling around), the same goes for mapping, the tools are there, it's how you use them that makes the difference.
@neico Regardless if it's able to be decompiled or not, it doesn't save things like variable names or comments, and makes using or understanding the code much more difficult. Also, it's the exact same thing as C++ modules -- you have to install addons just like modules. Workshop is the only exception to this, which you can always blacklist luac files or handle the compilation when uploading to the workshop if you don't want to run into issues on that platform. Also, you are right about people slipping unaccounted code into DLL compilations, but in the end if you don't trust it, you can always compile it yourself (which you can do with luac already in GMod https://github.com/bkacjios/gluac-multiarch).
Lua used to compress much better than bytecode (either with or without debug info) last time I checked.
It depends on how many strings/comments the file contains, but it's usually a lot.
Really the only way I ever see this being exposed would just be for the Lua cache, and there's no point seeing as Lua bytecode with debug info is rarely going to be smaller than the original code.
Luac will allow files to be sent and ran on clients faster and more memory efficiently due to the step of code compilation being removed. I'm aware that there have been concerns raised in the past over allowing it due to the source code being hidden and potential exploits, but that same sentiment is held with C++ modules and is generally handled by users requiring source code to be presented before usage. Luac will also (partially) solve clientside code stealing in many respects due to (some) implementation details being stripped away post-compilation. Many addons that rely on security thru obscurity (anti-cheats) would benefit greatly from this byproduct as well.