Time  Nick       Message
12:55 Krock      ^ @luatic In case you'd have some spare time to look at it. You're the expert here, after all :)
16:23 rubenwardy https://github.com/luanti-org/serverlist/issues/78
16:36 Sheriff_U3 Is there any more recent data available for that issue? Nov 2025 is almost a year ago, and before some of the more recent security fix releases.
16:37 rubenwardy sfan5?
16:38 rubenwardy can update the graphs if you make new stats
19:58 cheapie    FWIW I personally tend to be in favor of not intentionally breaking compatibility with old stuff just because it's old (although in this case I don't think any extra effort needs to be spent to keep it working, it just kind of breaks whenever it breaks), although if there's some way to perhaps warn players that might not be a bad idea.
19:58 cheapie    Maybe for versions older than a certain value, always return a fake server at the top of the list, with a warning message as its name and more information in the description?
20:17 red-001    on https://github.com/luanti-org/serverlist/issues/78 rubenwardy I'm not sure how exploitable the mesh parser bugs really are in practice, a lot of what was fixed was probably no security impact (e.g. read out of bound going into a mesh buffer), perhaps the memory safety stuff just doesn't get GHSA's which I think is an issue here
20:17 red-001    it's pretty contradictory to block clients for something that on the other end was not disclosed to users as a vulnerability through the security advisory process used by the project
20:19 red-001    on the small player base for 0.4, this is somewhat an argument against actually doing this, obviously these people choose to play on an older version for whatever reason, blocking old 5.x clients should provide a more clear benefit here where they can upgrade to the most recent version
20:20 red-001    (on the GHSA, none of https://github.com/luanti-org/luanti/security/advisories?state=published are disclosing exploitable memory safety issues as far as I can tell, certainly not any that are documenting a risk for the client, and not the server)
20:22 red-001    on a UX level I'm a little anxious at the prospect of communicating updates to players through that, this seems a little like implementing the kill-switch proposal but without the purpose-made UX for it
20:23 red-001    if the project can inject messages through the server list so can bad actors and unless someone wants to pay for an OpenAI API key there's not really any automated way to block and detect that
20:24 red-001    probably *fine-ish* if just disabling the list and returning one informational message like cheapie suggested
20:24 cheapie    My suggestion was to return an informational message at the top of the list) and _not_ disable the list
20:25 red-001    apologies
20:26 red-001    (speaking of security #15078 still needs a reviewer 2, so the engine finally stops storing non-SRP protected password/legacy passsword hashes)
20:26 ShadowBot  https://github.com/luanti-org/luanti/issues/15078 -- [no-sq] Return SRP-style hash from `core.get_password_hash` by red-001
20:26 cheapie    I can't remember if the client or server decides the ranking of entries in the server list, but either way the list server could just forge numbers on the fake/informational "server" so it always ranks above all actual servers
20:27 cheapie    This "server" doesn't even need to be reachable, it could just point to localhost or something
20:28 red-001    probably pointing it at an official domain of the project or a documented unreadable IP address (if one exists, there's a documentation range, not sure off the top of my head if it's documented to be unreadable)
20:28 red-001    would be best there
20:28 red-001    localhost we might connect to *something* so it's a bit sloppy I think
20:29 cheapie    I wonder if the client would complain about seeing a server list entry with a blank address?
20:29 red-001    blank would be localhost I believe
20:30 cheapie    I'm not sure about older versions, but in 5.18-dev pushing login with a blank address doesn't do anything at all
20:31 red-001    maybe it's blocked on the menu level
20:31 sfan5      we're more interested in overall feedback. these are technical details
20:33 red-001    I said my part already on that, there's a phishing risk if you establish that legitimate communication can be done through the server list, instead of through a dedicated security disclosure flow (aka the "kill-switch")
20:34 red-001    and that 0.4 users are on that version for a reason, security improvement there would have to imply they would be willing to switch which is difficult to accept at this point
20:35 red-001    blocking old 5.x versions seems more reasonable
20:35 sfan5      "the luanti project can phish you"  doesn't seem like it would fit in an reasonable threat model
20:36 red-001    anyone can start a server
20:37 red-001    how are you going to reliably block malicious information in a server announcement? I know there's layers to the server list ranking but that's putting a lot of trust in ranking code that a new server will never end up never the top of the list
20:39 red-001    if you're happy to take on that responsibility of the equivalent of scam ads now seeming more legitimate than they did before, that's fine, but it does shift the model a bit from having to just filter for servers with offensive or defamatory content
20:40 red-001    or I guess the entire bee movie script or whatever under copyright safe harbor
21:47 sfan5      I think the main obvious sign is "entire list is replaced with a fake server" vs. "one fake server appears at the top"
21:47 sfan5      but in any case we don't necessarily *have to* do that