Lua lobby?

[Licho]

Personalized hacks are only used if you hold something really valuable - we don't, nobody cares.

Protection from obscurity? Isn't the purpose of developing an engine over so many years to make something that could grow? If we just wanted to keep regulars all development could have stopped in 2006. Should design spring for 500,000 players not 500.

If you drive all the game devs out because engine makes it too complicated to develop features, there will be no growth for certain.
Spring is in decline atm, projects being abandoned, you have few remaining active content devs and imo you should listen more to them than to imaginary future threats.

First application that needs either lua sockets or extended autohost interface (allow pm + allow on clients not just dedi) is the voice command system quantum made. Atm he is passing messages hacky way from:

lobby pm (special hiding)
->
autohost
->
UDP AH interface
->
ingame all chat
->
hide chat in handler
->
process by widget
->
respond to log on client (echo)
->
redirect spring output to process because of log buffering
->
process by lobby on separate thread otherwise its blocking spring

It works, but its is complicated, slow and easilly hackable (to see what other people send as voice commands).
And this is what you get with misplaced security features - complicated, unreliable hacks that compromise security even more.

[Tobi]

We don't even have this "misplaced security feature" yet, so that's a nonsense argument. Heck, we don't even have the feature that is supposed to be "secured" using this "misplaced security feature".

Only reason such solutions are made are because people take the way of the least resistance without keeping future maintainability and proper software design in mind.

(i.e., changing C++ is hard, git is hard, don't want to wait for engine release, etc., so just introduce 6 extra layers to get a prototype working quickly without having to touch C++ or git. Has nothing to do with security at all.)

Whitelist is ok IF we (ZK team) can set up defaults for the players.

So maybe start by speccing out the feature a bit more so there can be some progress. In which cases can you set up defaults / how do you ideally want to set the default? Config file? Env var? Another file in the data directory? Text file in the game archive?

Just thinking out loud: If config file, then obviously you shouldn't be able to set this whitelist through Lua in the engine, which complicates the engine a bit and gives a bunch of APIs inconsistent behaviour. File in game archive has problem that VFS can't differentiate between map and game. So maybe a simple text file in data directory is best? Maybe Lua can overwrite that. Modinfo.lua then maybe?

More out of box: Are there any things besides whitelist that might achieve the same goal? Maybe full network access is OK if it's opt-in for the user? Maybe whitelist should be delegated to lobby? Maybe through AH interface? Just brainstorming.

[Cheesecan]

Use a remote whitelist? The list can be updated more quickly that way. You could have a blacklist too. Data integrity should be guaranteed using public-key cryptography.

[hoijui]

remote white-list... and where is it fetched from?
some place where all game devs have access to?
ah i know, we mak white-list!


...DOH!

btw, i am with tobi.

[AF]

I think a whitelist is a good idea


BUT

The threat is not from rogue games, unsynced sockets is more a danger of rogue widgets. Nobodies going to go to the effort of packaging a whole game up when they can distribute a widget or a repackage BA with a rogue widget, at which point they need to justify why people should play their version.

What I suggest is that we have it as a settings value, and default to non private IPs, any installer or special instructions can be used to set up special case setups for whichever tools the user needs.

If we're really paranoid we can crash the engine when a request to an illegal IP or host is made.

I agree with Aegis on further thought that localhost should not be possible by default, because then we could have headless running in spectator mode with a loopback feeding us data on eveyr units position thats overlaid on our screens.

-------------------------------------------

So what would we need to do, what libraries are relevant, and where would we need to look actually do any of this?

[varikonniemi]

I agree with Aegis on further thought that localhost should not be possible by default, because then we could have headless running in spectator mode with a loopback feeding us data on eveyr units position thats overlaid on our screens.

how is that any different from modifying the engine to have permanent los? We obviously have all the information necessary to do that since we are running the simulation anyway.

Cheaters will always find a way to cheat, that is for certain.

[Licho]

We don't even have this "misplaced security feature" yet, so that's a nonsense argument. Heck, we don't even have the feature that is supposed to be "secured" using this "misplaced security feature".

You do, lua lobby can connect to any host atm, but its limited to tasserver protocol handshake/messages..

So yeah, there is the feature (lua sockets), buts ts hidden under another layer that limits its use.

[Licho]

Whitelist in engine config is fully acceptable and imo best solution. It can only be deployed by lobby/trusted party.

[koshi]

Show us lua sockets?
https://github.com/spring/spring/blob/d ... aLobby.cpp

[Licho]

Show us lua sockets?
https://github.com/spring/spring/blob/d ... aLobby.cpp

I see network sockets <-> lua interface. Thats lua sockets to me. I didnt even know "lua sockets" is some actual library..

[cheapsheep]

What about providing tcp sockets, but only listen/accept and no connect? (Why) do all of you assume spring should be the client? Just turn it the other way around: get your lobby (or voicerecognition- or touchscreen-gateway, whatever...) to connect to spring (or more specifically, to your lua widget listener). It would provide an easy way to add features like remote control without a frightening stack of hackish layers that move your private commands over lobby protocol.

Listen-only socket support removes the need to discuss about how to get valid authority data (whitelist, certificates) from a non-existing trusted authority. Widget/map cannot connect anywhere, they just wait for incoming connections: rogue network abusing widget problem solved. And people who want an hassle-free way to add new ways to control spring are happy.

It seems so obvious... whats wrong with it?

[Andrej]

What about providing tcp sockets, but only listen/accept and no connect? (Why) do all of you assume spring should be the client?

American ISP especially are renowned for maintaining the lead in freedom of network communication by underprovisioning internet routable IPs and forbidding the running of 'servers'.

By empirical test, large portion of spring userbase seems not to be able to host games, that is a tcp socket listening to connections, so this approach would fail.

Usually the fault of NAT
http://en.wikipedia.org/wiki/Network_ad ... #Drawbacks

Services that require the initiation of TCP connections from the outside network ...etc...

[cheapsheep]

@andrej

your ISP isnt involved in communication between your lobby and your spring instance running on the same machine.

its also not involved if you want to use your tablet as a control device for spring, provided your tablet is connected to your lan.

[AF]

Listen only clients is more stifling than connect only

[cheapsheep]

yes its more "stifling" and thats the point. It stifles criticisms about security by stifling attack potential of unrestricted connect. I call it pragmatism...

But when you have solved your web-of-trust problem or whitelisting mechanism, feel free to uncomment REGISTER_LUA_CFUNC(Connect), I wont deny it can be useful. Its just not needed right now for those who want a way to add remote control without hacks... and the rest of the implementation is required anyway.

Seeing that some care about a "loopback feeder" while full game state is available to everyone, I just fear that it could take ages to settle on connect restrictions... stifling innovation potential of others in the meantime.

[AF]

Its just that listen only requires that external services go to extra lengths to connect to you. This is undesirable, e.g. say I had a twitter news feed for my game in the start up menu like some games do, do you think twitter is going to support connecting to me rather than me connecting to them? What about a games news feed via RSS? How are they to know the details if I can only listen? Do I pass them my IP and port forwarding details via carrier pigeon?

Listen only sockets is incredibly limiting, and introduces issues even with attempting to connect to the lobby server ( making lua lobby impossible and making the entire sockets feature somewhat useless )

[cheapsheep]

I have heard twitter has a phone number you can call to ask them to open a tcp connection to your box if you were smart enough to implement an RSS client using a listening socket. Or just use carrier pigeons like you said, but be sure to support RFC2549 and ensure they can haz a cheezeburger on long-haul flights.

I guess there are different kinds of requirements to implement different kinds of addons for spring (just a random guess out of nowhere...). It just happen requirements of those who want to implement a network client and requirements of those who want to implement a network server mostly overlap in this specific case: only connection setup differs... send, receive (-thread), close are shared.

If you are misrepresenting what I said because the thread is called "Lua lobby" and nothing else matters, then fine, just state it clearly and dont tempt me to answer like I do. Do I have to copy-paste my proposal to a new thread so it gets proper consideration as a "feature request" that doesnt carry network penetration risks? I promise I will make it extra-clear that people should not expect to be able to implement an RSS client using this (unless they find the phone number I was talking about earlier).

If you just didnt understand that a listen-only implementation would be useful for some use-cases (I gave examples...) but not for all use-cases (among which might be yours), then just call this "useless" as you did, I'm fine with it. And its fine too if you think your USB ports are useless because they cant work in device mode... who would use such a useless port to connect a mouse? It cannot even be used to connect 2 hosts together (without a "bridge"), that USB technology is useless!

As I said, I just fear that people who might benefit from server sockets right now would have to wait until you figure what kind of condition has to be put in the if-statement restricting use of the connect function. My implicit proposal was to comment out the export of the connect function until you resolve this political issue. Lets be clear, I value the fact that some consider the risks of unrestricted connect... while being highly "skeptical" of those who believe they can avoid publicly available information from coming in through the pipe. Big lobbies (music, movie, not your kind of lobby) have tried to control information flow and failed miserably.

If you wont implement sockets until you find a way to prevent a "loopback feeder" scenario, give up now... you cant control information once its out. Cheaters will outsmart you and feed their nasty "see-it-all" widgets by using covert communication channels such as cpu load of fake spectators if they feel doing something funky while running an unadulterated spring on player side. Or they will use NAT to outsmart your whitelist and translate your whitelisted IP to bridge with their spec spring "drone"... because yes, NAT can also be applied the other way around by "creative" people. So, dont expect whitelists to prevent the player from connecting to any IP he wants... all it can do is prevent nasty unreviewed widgets from doing some type of harm, that is: connect behind your fw or to it without your knowledge, which is a Good Thing. In the meantime, low-tech cheaters have their spec friend on the phone, so they do not even need to be smart or have 2 computers...

Dont invest too much in that barrier:



... and if you do, give us listen-only sockets while you over-engineer the barrier's retina scan. I have lots of ideas for controlling spring that I'd like to evaluate... its just too awkward to do it now without some kind of open interface...

[Tobi]

I think connecting to loopback isn't really an issue, as mentioned before someone who wants to cheat can cheat anyway, and this seems like an awfully complex way to cheat. (+ one can just pass traffic over LAN if loopback is blocked in some way)

Personally I only consider unsigned, unprivileged, unreviewed, automatically downloaded code with enough access to pastebin your whole HD to be a little worrisome. (i.e., enough worrisome to vote against patches that allow this, and to invest some time into this thread.)

A listening socket would be sufficient for all kinds of local integration, but as some pointed out it doesn't cover the LuaLobby scenario. Nevertheless, I see no issue with allowing Lua to make sockets listening on localhost. (random Q: do firewalls pop up on Windows when opening a listening socket bound to localhost only?)

For connecting sockets I'm still undecided on whether config-file whitelist or remote whitelist is better, but remote seems to have the edge. (pros: less weird hacks in engine [to make some read-only config vars], no need to worry about Lua being able to modify the whitelist accidentally, no need to worry about different games/lobbies messing up each others whitelist in case they share a config file, no need to write code to perform whitelist migrations.)

[Licho]

For loopback connections there are alternate ways

1) improve existing autohost interface (allow on client, allow PM not just "chat all", allow sending lua messages)

2) allow access to stdin from widgets

3) allow local lua sockets

I would prefer 1 in this case. Beneftis are:
- already existing code both in engine and autohosts
- non blocking in engine
- allows multiple listeners and talkers
drawbacks:
- current protocol limits message size (not an issue atm)

[abma]

For connecting sockets I'm still undecided on whether config-file whitelist or remote whitelist is better, but remote seems to have the edge. (pros: less weird hacks in engine [to make some read-only config vars], no need to worry about Lua being able to modify the whitelist accidentally, no need to worry about different games/lobbies messing up each others whitelist in case they share a config file, no need to write code to perform whitelist migrations.)

the whitelist then could be placed into script.txt... or what do you mean with a remote whitelist? http-download?