LÖVE

Should I post my brainfuck interpreter? It was written completely in Lua, is functional and has an extra functionality which you can use to call Lua functions.

You could do that... but I will heavily object if you want to distribute it with LÖVE.

Robin wrote:Another argument for disabling access to os and io: you're not going to need it. If you reason "well, maybe I'll need it...", why not include a BrainFuck interpreter per default? You might want to use it!

Well, ok, that last argument was a little exaggerated. But still: there is no use in including things almost no-one is going to use.

With the (small ?) difference that we're talking of excluding standard stuff, not including a random library.

I, however agree (you managed to convince me), that in the aim of protecting newbies against themselves, disabling by default io and os could be ok. I stay on my position that it should be however available to those who want them, with a simple love:sandbox(false). Protecting against evildoers is IMHO irrelevant.

Tenoch wrote:With the (small ?) difference that we're talking of excluding standard stuff, not including a random library.

Yeah, I know. I got a little passionate.

Tenoch wrote:I stay on my position that it should be however available to those who want them, with a simple love:sandbox(false). Protecting against evildoers is IMHO irrelevant.

Having a way to "escape" the sandbox is pretty much unavoidable anyhow, so making it a simple command is not a problem, I think. Protection against evildoers is IMHO futile (as I said in previous post).

Edit: 300th post!

I want a sandbox (by default) but I'm a little affraid about if I need some unusual things. Is the hardcoded limitation (sandbox) will not forbit me to use love as I want ?

Just a idea.
Is it possible that the sandbox could made only in lua ? and the sandbox should be pre-loaded by default.

I think about 3 differents use of love :
1) you want use it like a player (think about flash player, or java player), you want almost use love to run some applet (.love)
Then you need a secure player, like the flash/java player you don't want allow damage on the user data.
2) you want distribute you game like a software, you package it with the love binary
You don't need security or sandbox, because you provide the binary (.exe) inside ... it more dangerous than the rest.
3) you want have love like a application (a suite?), think about the Office.
You run you application (think about your text editor), you want open a file (a game), work on it (play it).
You can have global preferences (like global resolution settings)
You also use it to debug, develop your game.
In this case you will maybe need
- a sandbox to run unknow peace of code, or check want you want
- no sandbox, because you run your own game and you want use easily you library. And you put every library in a personnal directory (outside of each game)

There is maybe more possible use.

I think TsT makes a very valid point, what is LÖVE going to be for us? As far as I see the ability to use it as a player is useful, but not really the main focus for larger projects. Once you want to distribute the game to an audience that doesn't include LÖVE developers you will have to package it with an executable anyway, which would probably mean that the "trust factor*" would apply just as it does other random shit you download.

However, lets be honest with each other: if we disable built in functions it would only be to facilitate the creation of our own and it would help to make LÖVE be more than just a lua module.

That said, I voted yes, but only because I could never see myself using non-LÖVE functions anyway.


*trust factor: If you download a program off the net you have to trust that the program isn't going to kill your computer.

mike wrote:Once you want to distribute the game to an audience that doesn't include LÖVE developers you will have to package it with an executable anyway, which would probably mean that the "trust factor*" would apply just as it does other random shit you download.

True.

mike wrote:However, lets be honest with each other: if we disable built in functions it would only be to facilitate the creation of our own and it would help to make LÖVE be more than just a lua module.

What exactly do you mean by that? Is it a good thing to disable built in functions or a bad thing, according to you?

mike wrote:That said, I voted yes, but only because I could never see myself using non-LÖVE functions anyway.

And that's a good thing for games in general, I think. They shouldn't have to interact with the (operating) system, because, well, they're fukken games.

Sorry I don't understand this debate/controversy whatsoever.

Limiting filesystem access is IMPOSSIBLE without disabling the LINKING of DYNAMIC LIBRARIES. Am I the only one who sees this?

Disable os.execute?

Solution:

mylib.dll k?


What if I want to write a quick graphical app using my framework to compare file directories or write make files? (Python would probably be my choice cause they have TK support but still)

Zorbatron wrote:Limiting filesystem access is IMPOSSIBLE without disabling the LINKING of DYNAMIC LIBRARIES. Am I the only one who sees this?

No, you are not the only one. And if you had read the thread, you have had not only seen that, but also that we're talking about partial sandboxing: not to prevent their use at all, but to shield the beginning coder from shooting themselves in the foot and (at least for me) aesthetic design purposes.

Robin wrote:No, you are not the only one. And if you had read the thread, you have had not only seen that, but also that we're talking about partial sandboxing: not to prevent their use at all, but to shield the beginning coder from shooting themselves in the foot and (at least for me) aesthetic design purposes.

Explain to me how this will happen, you act like lua is the most dangerous language ever. I didn't need to sandbox myself when I learned C/C++, what could possibly happen with lua?

And I did read the thread, I posted a few weeks ago in it.