Jump to content

leper

WFG Programming Team
  • Content count

    1,100
  • Joined

  • Last visited

  • Days Won

    27

leper last won the day on July 13

leper had the most liked content!

Community Reputation

659 Excellent

2 Followers

About leper

  • Rank
    Primus Pilus

Profile Information

  • Gender
    Male
  1. I might port Hyrule Total War to 0AD

    <Position> <Floating>true</Floating> </Position> might also be useful.
  2. It does appear like lightdm/SDDM/whatever starts dbus, while just using startx/xinit doesn't do that. And for some reason something (driver/library/etc) uses dbus, which runs into some issue.
  3. I might port Hyrule Total War to 0AD

    You need to add a few lines to simulation/data/placeablesFilter.json. I do however dislike that we do have to explicitly specify most things there, so I guess we should change the code to either allow recursive inclusions, or invert the logic and only specify things (using wildcards) that should be excluded. I think I prefer the latter option. When saving there's two tabs "Scenarios" and "Skirmishes", select the latter and save.
  4. The biggest trade gain is trading with an ally over a long distance (though you only get a part of the traded value at the ally's market). Cycles for traders are done in the wip code for the Silk Road map, however there is no gui support for creating such cycles.
  5. All Relics Captured Message

    But before anyone changes something to be wrong (assuming that we consider title case for buttons to be the correct thing) you should be aware that I only mentioned both of those because they are right next to each other.
  6. All Relics Captured Message

    That's just proper application of title case, and it seems most software products do use it for things similar to what we use those buttons for. If you want inconsistencies pointed out you might want to look at "Report a Bug" and "Translate the game" in that last image of yours.
  7. All of this sounds a lot like what Collada was about a few years ago. If someone does all the work and thus allows us to drop that bundled FCollada (which we are "maintaining" in the sense that we try to not make it fall apart) that would most likely be appreciated, however the current state of support for that format seems a bit light right now.
  8. Exept solving a different issue that doesn't apply in every detail doesn't help, but pointing that out seems to be nonsense. Ah well, I guess doing research first seems to be a strange way of operation, same as first asking questions instead of providing "complete" "solutions".
  9. Because you haven't even bothered to look at the actual code at work here, so your "proposal" will fall apart when confronted with reality. The first hint would be that the lobby doesn't use HTTP, so using HTTPS would be more than cumbersome. Same for that secure downloads ticket where you have more text that confuses issues, doesn't clearly state the actual issue (or at least I stopped reading after seeing that wall of text), and ignores that the downloads are already mirrored somewhere. Also tickets are for somewhat workable issues, not long walls of text that call for discussion. I'd strongly suggest finding out what is actually used before all those proposals, as currently you are just making it harder for anyone actually wanting do work on any of those.
  10. Except it requires updating the clients to only use that mechanism (you'd want to prevent clients from using the old one, right?), someone to actually do the work, quite some testing so it actually works properly. There is a difference between what is the required amount of work needed in theory, and what needs to be done in practice. You suddenly used the word "Web". If you start using words in a context where they just appear to indicate that you didn't think about the problem, then you'll have to deal with being called out on that. If the server is compromised an attacker doesn't even need to look at the passwords to impersonate anyone. And in this case they could just try a downgrade attack to get the actual password (we did disable the plain mechanism, but a few of the supported ones aren't that hard to break). We've known that for quite a while, the issue is that someone needs to do the work. threat model No, they are not secure. You just increase the amount of work an attacker needs to do to get possible candidates that match (and how many users do you know with very long passwords (phrases would be better, but I digress). That's not really long, then again you haven't defined your threat model at all, so if the attacker is someone with brains and a Pentium, then you might have a point. If we are talking about server farms or tons of graphics cards that's something completely different. Windowed mode without decorations, or run things in some other X server, or copy the password, then start the game, or get a better program to handle your passwords. Some things are more interesting than others to work on. And so far I've seen lots of talk and no single line of code. Welcome to the internet, I see you must be new here. Only if you try common passwords, at which point the issue is that you are using a common password. One could just try the list from that one Yahoo! leak and get quite far. Unless rate limiting kicks in. True one can just use something distributed to try those, but that wasn't listed in the attacker model. And there is no issue with that, as long as the places they reuse it for are things that for some reason require an account, so they just use hunter2, because if it gets leaked nobody will even care. Depends on whether they used the same password for something that doesn't need a lot of security as for something that most likely should. Why not? Because someone might get offended because they themselves are doing stupid things? How do they remember 500 accounts? But something that you could fix quite easily (probably a diff with about 5 lines (and most of that is adding a checkbox)). Could maybe be done without any interruption, but most likely couldn't. At least it didn't seem that way last time I checked (which allegedly has been quite some time). Well, I'm not responsible for the lobby in any way anymore, so meh. Also you should really define threat model, attacker model, and most of all help with fixing things instead of writing lots of prose. (Eg upgrading the lobby server to something that isn't mostly unsupported, enabling TLS for lobby communication, getting the actual game download links to use HTTPS, ...) It isn't. Not server admins?
  11. Patches welcome. Yes. See the comment earlier about us needing to invalidate all accounts if we were to switch to another SASL mechanism, since at least last I checked there was no way to nicely upgrade that otherwise. By the standard definition of "Web" this isn't a "Web Application" :P Yes, this does suck a little, however so far nobody really cared about passwords for some random game, and we don't even send the actual password (true, one could build a table for that, but the same is true if one hashes on the server; so whatever you do you just make it harder for some attacker once they have already gotten too far). Secure against what? A server compromise? Well, no, but neither would it be if we did hash it there too. It just makes things a lot more work intensive. One could store the password in some password manager or keychain and just copy it into the game every time one logs in. That'd require not storing the password as an option though. So they should use file system encryption, or encrypted containers. And how many multi-user machines are likely to run games and include users that don't trust each other? I haven't heard of anyone deciding to run it atop of a rump kernel so far, but I don't consider that impossible. Without a desktop environment, I haven't run one of those for years. If someone uses the same password for their nukes (instead of the default 00000000) and some random game they deserve what they get. The user will get more stupid to work around your "fixed" technology, so you can either make things useless to people able to read the documentation, or you should stop rewarding people unwilling to read.
  12. Triggered Day and Night Cycle

    Not without changes to both the simulation (to enable it to set the light environment; currently it doesn't even know that there is one) and the renderer.
  13. We are hashing the password on the local machine and only storing that. If you are worried about your password getting compromised you should be more interested in getting TLS enabled, which might need some work to get some Let's Encrypt cert handed to the lobby server, and then switching the authentication mechanism used to one that only stores the hash on the server (in our case the hash of the hash of whatever the user enters) (and yes, this would mean invalidating all accounts currently existing). Your attacker definition seems to include at least read access to your local file system, in which case you are more than screwed already. If you are considering backups, well encrypt those, same for your file system in case you are worried about that. The keyring "solution" has quite a few issues. What if a user changes their OS? What if they just change their desktop environment? What if they don't use one? And all of that doesn't really do anything but protect you against an attacker that allegedly already has quite some access, at which point they could just hook the game and get your password. If you really don't want that hash to be stored in the config file, write a patch that adds a checkbox to save the password only when it is checked. While you're at it you might also want to prevent copying the text that is in the password field. Also don't use the same password for some random game you found on the internet as you do for your banking or your nuclear power plant controls. And don't use quite a few other programs that save passwords, you might be surprised by quite a few (I'll just list Pidgin here, since that seems somewhat similar to the lobby).
  14. I might port Hyrule Total War to 0AD

    I was unsure about this, but I checked the code, and both work.
  15. FMOD might be gratis for "small" users, but still uses a proprietary license, which prevents us from using it.
×