LÖVE

Oooops... I thought it was already removed (I remember reading about the *intention*...)

Anyway, I still think LÖVE should be a "safe" application. I still open .love files without thinking twice, at least for now...

I agree, but it may involve a custom version of Lua. I'm not sure whether users simply can require("io"), even though love doesn't open the library by default.

When you build lualib.lib (or liblualib.a) you decide what goes in there. If you don't put in the io library (liolib.c), it just won't be there.

Of course, it's possible to require() anything and provide evil functionality in a DLL or .so, but then you can remove require() as well (just remove it from _G before you load the script, or change it to a function that throws an error that explains that you have to use the LÖVE equivalent). But that would mean that you limit people with what they can require() which may not be what you plan for LÖVE.

We need to make that a runtime decision, though. The io library will be made available if love is run with some command line option.

I would like to second the bit operations module. It is an advanced feature, so i understand that it is of the lowest priority, but I am sure at some point i will appreciate it.

rude wrote:We need to make that a runtime decision, though. The io library will be made available if love is run with some command line option.

I'd appreciate that. I'd give additional utilisation to love. I need something, where I could make standalone binary just as it is possible now, but with enabled io. Command line argument means 2 or 3 run scripts :/. However, I can't really make up any better solution than that.

Also, I need to be able to run external commands. I didn't have chance to test if it works now.

Another idea is to have a "preload"-like feature.

A simple script like : after that we can load/run the .love file in this environment.

Hmm, do you think we should disable standard require() in "secure" mode? It would mean that people can't load custom libraries, but that might be just what we need to make it secure enough.

@Green_Hell: In addition to a command-line option which ensures a 100% clean Lua API, that can be the default behaviour of fused files. That should take care of both development and distribution for people who need io/os and otherwise an unaltered Lua API.

Related note: it would also be possible to run fused binaries in safe mode. It might not work, of course, if the code expects io/os to be available.

I like the idea of a command line option. That really solves a big problem.

Regarding fused files, I don't think it's that important. After all, I could write a program in my favourite language and claim that it's a fused LÖVE program. You can't protect against that (whatever protection you use I can clone in my evil program).

When we download an executable off the internet we take a risk. There's not a lot we can do about it. But when we download LÖVE from love2d.org and then a game (.love) from evilhacker.com at least we'll know that the game is safe. Executables will never be safe.

So to summarise, my suggestion is:

1. safe mode by default for love.exe
2. unsafe mode by default for fused executables
3. unsafe mode available through command line options for love.exe

My thoughts exactly. Most people know there's a risk in running binaries.

All we need to do now is define what "safe mode" really is.