| Time |
Nick |
Message |
| 02:15 |
|
crazylad joined #luanti-dev |
| 02:22 |
|
[MatrxMT] joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:37 |
|
trompetin17 joined #luanti-dev |
| 05:42 |
|
SpaceManiac joined #luanti-dev |
| 09:31 |
|
[MatrxMT] joined #luanti-dev |
| 09:31 |
|
[MatrxMT] joined #luanti-dev |
| 10:05 |
|
erbium joined #luanti-dev |
| 10:37 |
|
[MatrxMT] joined #luanti-dev |
| 12:53 |
|
erbium joined #luanti-dev |
| 12:55 |
Krock |
^ @luatic In case you'd have some spare time to look at it. You're the expert here, after all :) |
| 13:58 |
|
Farooq joined #luanti-dev |
| 14:41 |
|
Farooq joined #luanti-dev |
| 15:44 |
|
Farooq joined #luanti-dev |
| 16:16 |
|
Farooq joined #luanti-dev |
| 16:20 |
|
Farooq joined #luanti-dev |
| 16:22 |
|
Farooq joined #luanti-dev |
| 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 |
| 17:17 |
|
Panquesito7 joined #luanti-dev |
| 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:14 |
|
red-001 joined #luanti-dev |
| 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 |
| 20:40 |
|
Pexin joined #luanti-dev |
| 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 |
| 22:14 |
|
Panquesito7 joined #luanti-dev |
| 22:33 |
|
panwolfram joined #luanti-dev |
| 22:54 |
|
Juri joined #luanti-dev |
| 22:54 |
|
Niklp joined #luanti-dev |
| 23:12 |
|
[MatrxMT] joined #luanti-dev |
| 23:26 |
|
[MatrxMT] joined #luanti-dev |
