Lua lobby?
Moderator: Moderators
Re: Lua lobby?
Oh, script.txt is an interesting approach too.
With remote whitelist I mean http download yeah (as Cheesecan suggested).
With remote whitelist I mean http download yeah (as Cheesecan suggested).
Re: Lua lobby?
what if the http-server is gone? where to get the url from? who maintains the list with valid-addresses? imo many problems here, too.Tobi wrote:With remote whitelist I mean http download yeah (as Cheesecan suggested).
Re: Lua lobby?
Port scanning etc. has been possible for 'years' with the current Lua lobby interface and exploitable by any game, widget or map, so now when some progress is about to happen some retards plan a some kind of lockdown?
Sockets are not a real security risk only some paranoid people can fear their badly configured network gets compromised but that is fortunately a minority, an average user knows bad things happen only to the bad people.
The real security problem is the users (automatically)downloaded content(maps, widgets) have an uncontrolled access to same things as the game: filesystem, Lua sockets, Spring config files. For example a map can easily modify configs for ZeroK UI to permanently crash at every gamestart.
There are many ways to fix that problem but it is harder so developers just want to ban Lua sockets to feel their power. Easy fix would be just to change the uncontrolled access to a controlled access.
Also the whole content distribution is still in some control so there isn't even a problem to start with. If there would be a problem it is easily an criminal act but of course nerds are too afraid to talk to police, instead they develop their own arbitrary rules and shitty moderators just like this forum has pages of "rules" and it is still worse community that without rules.
Raw Lua sockets aren't that relevant for Lobby and I got my Lua lobby interface hacked to work fine for most things so this retardness should be easily moved under Lua socket feature request.
OK, instead of some bs about locking down some hypothetical hole there are real problems like the outdated lobby protocol. Current Lobby designs and lobby server implementations are quite far from getting players into game fastly or supporting more game relevant data.
What I like to be possible:
-different ranking systems
-ladder support
-tourney support
-player/clan profiles
-custom data for player unlocks etc.
-PMs for offline players
-MP campaign support
Zero-K has hacked many things around like ELO ranking, Planetwars, unit unlocks/upgrades, but the documentation is probably non existent so only Springie and minority of Spring players can currently benefit.
Sockets are not a real security risk only some paranoid people can fear their badly configured network gets compromised but that is fortunately a minority, an average user knows bad things happen only to the bad people.
The real security problem is the users (automatically)downloaded content(maps, widgets) have an uncontrolled access to same things as the game: filesystem, Lua sockets, Spring config files. For example a map can easily modify configs for ZeroK UI to permanently crash at every gamestart.
There are many ways to fix that problem but it is harder so developers just want to ban Lua sockets to feel their power. Easy fix would be just to change the uncontrolled access to a controlled access.
Also the whole content distribution is still in some control so there isn't even a problem to start with. If there would be a problem it is easily an criminal act but of course nerds are too afraid to talk to police, instead they develop their own arbitrary rules and shitty moderators just like this forum has pages of "rules" and it is still worse community that without rules.
Raw Lua sockets aren't that relevant for Lobby and I got my Lua lobby interface hacked to work fine for most things so this retardness should be easily moved under Lua socket feature request.
OK, instead of some bs about locking down some hypothetical hole there are real problems like the outdated lobby protocol. Current Lobby designs and lobby server implementations are quite far from getting players into game fastly or supporting more game relevant data.
What I like to be possible:
-different ranking systems
-ladder support
-tourney support
-player/clan profiles
-custom data for player unlocks etc.
-PMs for offline players
-MP campaign support
Zero-K has hacked many things around like ELO ranking, Planetwars, unit unlocks/upgrades, but the documentation is probably non existent so only Springie and minority of Spring players can currently benefit.
Re: Lua lobby?
ZKL also has offline pm.
If you want details about extensions used, make a post somewhere else and i can describe it, its rather simple, but nobody ever wanted it.
If you want details about extensions used, make a post somewhere else and i can describe it, its rather simple, but nobody ever wanted it.
Re: Lua lobby?
If you want high availability you could put it in the cloud e.g. Google app engine. Free quotas are an issue, it only has 1gb free traffic per day, but then a 256 byte whitelist.txt could still be downloaded 4 million times(per day) so that particular quota shouldn't be a problem. If the list is not available - which I doubt, have you ever seen google.com offline? - the client could simply use the last retrieved whitelist.abma wrote:what if the http-server is gone? where to get the url from? who maintains the list with valid-addresses? imo many problems here, too.Tobi wrote:With remote whitelist I mean http download yeah (as Cheesecan suggested).
You don't have to have a badly configured network to be vulnerable to Lua socket exploits. The only way to stop your loopback interface from accessing your network from an application like Spring is if you have a software firewall that filters on the application level based on rules you configured manually. This demands a certain level of technical expertise plus extra computer resources.Pako wrote: Sockets are not a real security risk only some paranoid people can fear their badly configured network gets compromised but that is fortunately a minority, an average user knows bad things happen only to the bad people.
As far as extending the lobby protocol, I could agree to some extent that the lobby protocol is lacking in flexibility. But who would engineer a modular lobby protocol that could support all the features people want to put in their lobbies, and be able to add new modules on the fly without restarting the server. I think it's good that lobbies handle special features on their own rather than to complicate the existing poorly designed protocol even more. It's not a big deal or problem in itself for a lobby to get elo ranking(for lack of a better example) from outside the lobby protocol.
Won't comment on the rest you wrote because it looks like you wrote that just to provoke a negative reaction aka trolling.
Re: Lua lobby?
and who maintains this list? i guess the game creators... so every game needs to have a server with a whitelist who wants to use a lobby?Cheesecan wrote: If you want high availability you could put it in the cloud e.g. Google app engine. Free quotas are an issue, it only has 1gb free traffic per day, but then a 256 byte whitelist.txt could still be downloaded 4 million times(per day) so that particular quota shouldn't be a problem. If the list is not available - which I doubt, have you ever seen google.com offline? - the client could simply use the last retrieved whitelist.
what if the server gets captured which maintains the whitelist and all clients automaticly download that? ( = who maintains the whitelist?) -> more decentralization needed
also, there is no code inside spring to http-download something. why not use the existing script.txt functionality?
i don't see benefits of the http-download solution...
there were already plans to extend the lobby protocol: https://github.com/lunixbochs/uberserve ... rtymap.txtCheesecan wrote: As far as extending the lobby protocol, I could agree to some extent that the lobby protocol is lacking in flexibility. But who would engineer a modular lobby protocol that could support all the features people want to put in their lobbies, and be able to add new modules on the fly without restarting the server. I think it's good that lobbies handle special features on their own rather than to complicate the existing poorly designed protocol even more. It's not a big deal or problem in itself for a lobby to get elo ranking(for lack of a better example) from outside the lobby protocol.
i'll ignore that, it gets to personally.Cheesecan wrote: Won't comment on the rest you wrote because it looks like you wrote that just to provoke a negative reaction aka trolling.
Re: Lua lobby?
The current consensus:
- Full lua sockets with a whitelist determining what can and cant be connected to in the spring configuration/settings
- The above option but with script.txt as an alternative/extra route
- Listen only sockets
- TASSERVER handshake
Re: Lua lobby?
I'm aware that people will find routes around barriers, in that case its mostly that by putting up a barrier the 95% of people who normally would circumvent can no longer be arsed, but someone will always manage it if they really, really want to.
But that still doesn't get around the issue of listen only sockets for a lobby client:
As you can see it's clearly impractical.
But that still doesn't get around the issue of listen only sockets for a lobby client:
- Users cannot be relied upon to configure ports to accept incoming connections, and we've already heard from people with stats that most users cannot host as it is. Listen only sockets would make a lobby client setup impossible.
- It would require modifications to the lobby server and all the existing lobbies
- It would complicate the production of new tools and clients in the lobby infrastructure
- It bucks the trend of how other clients and RTS engines do sockets. This is an RTS game engine, not a dedicated lobby platform
- There are numerous features that would be made impossible that have already been implemented in native lobbies, I did some of them myself in AFLobby although that is dwarfed by the scale of its use in Zero-K, and nobody can deny that it's harmful there.
As you can see it's clearly impractical.
Re: Lua lobby?
i totally agree with abma... a remote white-list is just.. bad, for so many reasons.. i though that this would be clear to everyone, which is why i made just a troll-like post about it.
you would need either multiple places where to get it from, or give half the spring community access to change it.. and in the end it gets to be a very complex system for some engine internal mechanics.. just out of the line unrealistic.
you would need either multiple places where to get it from, or give half the spring community access to change it.. and in the end it gets to be a very complex system for some engine internal mechanics.. just out of the line unrealistic.
Re: Lua lobby?
I am just throwing ideas out there now. There could be a small servlet page for administration the whitelist. One way is to have a simple application page where submissions get approved or rejected by one individual maintainer. Another way is to have a private page with login which then lets you write to the whitelist directly. Accounts would then be handed out by an admin and then changes could made without admin intervention. I think the first way is much simpler but obviously if that person goes away everything crumbles.abma wrote:and who maintains this list? i guess the game creators... so every game needs to have a server with a whitelist who wants to use a lobby?Cheesecan wrote: If you want high availability you could put it in the cloud e.g. Google app engine. Free quotas are an issue, it only has 1gb free traffic per day, but then a 256 byte whitelist.txt could still be downloaded 4 million times(per day) so that particular quota shouldn't be a problem. If the list is not available - which I doubt, have you ever seen google.com offline? - the client could simply use the last retrieved whitelist.
what if the server gets captured which maintains the whitelist and all clients automaticly download that? ( = who maintains the whitelist?) -> more decentralization needed
also, there is no code inside spring to http-download something. why not use the existing script.txt functionality?
i don't see benefits of the http-download solution...
I doubt that someone who manages to hijack google servers would use that opportunity just to defile our whitelist.. but then again we have some pretty big trolls here. :)
Why not to use script.txt or another writable file? Because local filesystem access is not secure from Spring, so whitelist could be tampered with easily by widgets. One way could be to set r/w permissions on the local whitelist file, but this doesn't work well in Windows.
Anyway that was just a suggestion, I don't really care how it is implemented anymore. Just from observing the general attitude of people in this thread, I'm pretty sure whatever solution is implemented will not be very secure. Everybody just wants to make things easy for themselves. I say then don't even bother making Lua lobby because the whole project is just another dead project in waiting like the rest of engine-related sideprojects, MT, AIs, what else I don't know. Why not focus on something like improving poor multiplayer performance instead of writing a lobby in a language that is at least 15x slower than the languages used for the existing lobbies. Also I don't know how you can maintain thousands of lines of Lua code with no unit tests, dynamic typing, no compiler checking.
We could use some of those lobby features for sure, but you know all the lobbies and servers and everything would break and take a long time to fix. Plus every change to protocol will come with at least one bug that then breaks lobby clients again making players infuriated when multiplayer is unavailable. This is why I think the lobby protocol is a bad foundation for building on.abma wrote: there were already plans to extend the lobby protocol: https://github.com/lunixbochs/uberserve ... rtymap.txt
abma wrote: i'll ignore that, it gets to personally.

Re: Lua lobby?
No.Cheesecan wrote:One way is to have a simple application page where submissions get approved or rejected by one individual maintainer.
I don't want to have to wait for six month for approval every time I change a line in my widget.
Re: Lua lobby?
That is the advantage of script.txt actually: it is read by the engine before any Lua runs, and never read again, so Lua can't overwrite it.Cheesecan wrote:Why not to use script.txt or another writable file? Because local filesystem access is not secure from Spring, so whitelist could be tampered with easily by widgets. One way could be to set r/w permissions on the local whitelist file, but this doesn't work well in Windows.
(Hmm, except for Spring.Restart of course.)
Truth. (well, most of it, not all IMHOAnyway that was just a suggestion, I don't really care how it is implemented anymore. Just from observing the general attitude of people in this thread, I'm pretty sure whatever solution is implemented will not be very secure. Everybody just wants to make things easy for themselves. I say then don't even bother making Lua lobby because the whole project is just another dead project in waiting like the rest of engine-related sideprojects, MT, AIs, what else I don't know. Why not focus on something like improving poor multiplayer performance instead of writing a lobby in a language that is at least 15x slower than the languages used for the existing lobbies. Also I don't know how you can maintain thousands of lines of Lua code with no unit tests, dynamic typing, no compiler checking.

Re: Lua lobby?
Our AIs aren't dead in the water, and you'd be surprised how small you can make the lobby implementation if you design correctly. We already have a plethora of reference designs and expertise ( including implementations using dynamically typed languages ).
And just to kill off th eremote whitelist idea:
Would you be happy if Microsoft ran an automated HOSTS file service that controlled what you can and can not access?
And just to kill off th eremote whitelist idea:
Would you be happy if Microsoft ran an automated HOSTS file service that controlled what you can and can not access?
-
- Posts: 834
- Joined: 19 May 2009, 21:10
Re: Lua lobby?
I don't care much about cheaters.
I think we should care about what (3rd party) widgets can. Widgets are much faster distributed as other parts of a game's infrastructure.
As stated you can route around barriers. But I want at least information or better a confirmation that some widget creates a socket connection.
I think we should care about what (3rd party) widgets can. Widgets are much faster distributed as other parts of a game's infrastructure.
As stated you can route around barriers. But I want at least information or better a confirmation that some widget creates a socket connection.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Lua lobby?
Pako wasn't upset, he was just irritated and spent much of his post facepalming at the not good handling of this issue. That and the fact that he felt that what he posted was obvious. And not that it matters at all, I agree with him.
Re: Lua lobby?
map is imo the best attack vector, mod second, lua widget third.
we don't have automatic widget downloading when a game is joined.
most players will never extract their map/mod to see what's inside.
I don't care if you find out I have a server running at 192.168.1.20 with port 25 open, you'll never be able to connect to it using the current lua sockets.
we just need a (host whitelist?) solution packaged mods can easily include in their self-contained spring distribution, which lua can't modify - not in the mod sdz, because those can be downloaded readily/automatically.
if lua filesystem access is still fully open, it should probably be limited in some way.
I've been expanding the lobby protocol and improving the server regularly. Server uptime is atm approximately two months, but I've rolled out several patches during that time without even dropping connections.
If you ever see any breaking problems, make sure I know about them and they will be fixed rather quickly.
we don't have automatic widget downloading when a game is joined.
most players will never extract their map/mod to see what's inside.
I don't care if you find out I have a server running at 192.168.1.20 with port 25 open, you'll never be able to connect to it using the current lua sockets.
we just need a (host whitelist?) solution packaged mods can easily include in their self-contained spring distribution, which lua can't modify - not in the mod sdz, because those can be downloaded readily/automatically.
if lua filesystem access is still fully open, it should probably be limited in some way.
You know the current server does that right?Cheesecan wrote: able to add new modules on the fly without restarting the server.

The current lobby protocol includes mechanisms for backwards compatibility. New protocol commands are not retained unless they have been proven to not cause unintended consequences for all major lobbies. I listen and respond to all feedback I receive, usually rather quickly.Cheesecan wrote: We could use some of those lobby features for sure, but you know all the lobbies and servers and everything would break and take a long time to fix. Plus every change to protocol will come with at least one bug that then breaks lobby clients again making players infuriated when multiplayer is unavailable. This is why I think the lobby protocol is a bad foundation for building on.
If you ever see any breaking problems, make sure I know about them and they will be fixed rather quickly.
- cheapsheep
- Lobby Developer
- Posts: 69
- Joined: 31 Dec 2011, 16:42
Re: Lua lobby?
If you reengineer the lobby protocol to add extensions (or anything else), it would be nice to implement some kind of login process that protect user credentials from Eve. It currently require client to do some kind of magic hashing, but as hashed password can be replayed as-is, it is akin to no security at all in the event you connect over an unsecured network.
This is probably not an issue at your regular gaming place, but if you connect through shared/open access points (maybe you play in a cafe with free wifi?), then it becomes an issue.
Adding an alternative command to LOGIN that involve a challenge-response would fix it, but it would require changes to server. Then there is the easy-lazy route: wrap current protocol in SSL. Running stunnel on your server and piggybacking to 127.1:8200 should be enough, and doesnt involve any coding. It would also provide privacy, and only lobby client devs who care about this problem would have to implement it, which means nobody should complain (except the person who will have to setup stunnel and obtain a certificate). Other routes are possible, such as implementing STARTTLS in server, but that would require more commitment from devs.
I currently feel the need to add a big disclaimer to my android lobby client (dont expect more than chat functions, unless/until spring provide listening sockets for more features), warning users about the risk of connecting over unsecured network... and this will draw more attention to the problem (and maybe bad guys too). I hope there will be no reason for me to include such a warning when my code is good enough to be released...
This is probably not an issue at your regular gaming place, but if you connect through shared/open access points (maybe you play in a cafe with free wifi?), then it becomes an issue.
Adding an alternative command to LOGIN that involve a challenge-response would fix it, but it would require changes to server. Then there is the easy-lazy route: wrap current protocol in SSL. Running stunnel on your server and piggybacking to 127.1:8200 should be enough, and doesnt involve any coding. It would also provide privacy, and only lobby client devs who care about this problem would have to implement it, which means nobody should complain (except the person who will have to setup stunnel and obtain a certificate). Other routes are possible, such as implementing STARTTLS in server, but that would require more commitment from devs.
I currently feel the need to add a big disclaimer to my android lobby client (dont expect more than chat functions, unless/until spring provide listening sockets for more features), warning users about the risk of connecting over unsecured network... and this will draw more attention to the problem (and maybe bad guys too). I hope there will be no reason for me to include such a warning when my code is good enough to be released...
Re: Lua lobby?
so why can I not at least get join/start/get match support?
I know you guys want to sit here and talk about all the wonderful crazy shit you would like to see but all I want right now is to be able to get matches, join matches and start matches. Would that be a lot to ask?
I know you guys want to sit here and talk about all the wonderful crazy shit you would like to see but all I want right now is to be able to get matches, join matches and start matches. Would that be a lot to ask?
Re: Lua lobby?
Pako is working on that?
It's funny the lobby protocol supports extensions but only three or so were made.
It's funny the lobby protocol supports extensions but only three or so were made.