Hacker News Reader

Hacker News

Comment by marcosdumay | Hacker News Reader

Parent Full thread

marcosdumay

Factorio has stuff like this:

https://mods.factorio.com/mod/Moon_Logic

Besides, it's quite limiting to create software that can't just execute in a Turing complete environment.

Anyway, we really need interpreters that include a strong capability system.

View on HN

OP only refers to bytecode. There's nothing wrong with executing Lua when provided to the VM via source code. The only reason to allow the VM to load bytecode directly is 1) a very minor improvement in loading time, as the interpreter then doesn't have to parse Lua code into bytecode itself 2) allowing obfuscation of logic running within Factorio. Both seem rather irrelevant, so I'm not sure why they allow loading bytecode directly.

Isn't hardening source code parsing much more difficult then hardening byte code parsing?

Sure, the output of the lua compiler might be guaranteed to not invoke undefined behavior in the byte code interpreter, but the compiler itself might be vulnerable.

To my knowledge, compilers like GCC and clang treat source code as trusted for this reason

“If I ran the business” (TM), I would just put it in Factorio settings as a toggle switch called “Reduced Security Mode - Allow Lua Bytecode.” By default, it’s turned off. People who really want those mods can turn it on, as long as they are informed (UAC prompt style) that they better trust the mod authors. I’d also add an API for mod authors to detect if bytecode access is enabled; so they can make their mods compatible with either environment.

Or maybe, down the road, Factorio could enable mods with greater privileges, as long as they are open source, and do an App Store-style review process with the community. Approved mods get not just bytecode, but perhaps even some of the typically forbidden modules like filesystem access. Unapproved mods using those enhanced privileges won’t run without a startup flag.

> By default, it’s turned off. People who really want those mods can turn it on

This works until a popular mod requires it (for legit reasons) then enabling the option becomes the de-facto standard for people who install mods.

It's possible to make it so you enable it on a per mod basis, like app permissions

Because that's never ever been a total usability disaster that just encourages people to enable every one because they don't feel like fighting it. It's also not effective, given how tightly tied mods are to the core API.

When you're talking about security, adding a bunch of config flags for users is never a good idea. Most users aren't going to understand what it does, and like others mentioned, there's too many reasons to turn it on.

I see no problem. It's those people's choice to do so, and they accept the risk.

Reply on news.ycombinator.com