| Time |
Nick |
Message |
| 00:03 |
Zughy[m] |
can we please think about having a decent mainmenu first and then bother about the launcher? |
| 00:05 |
Zughy[m] |
Reminder that that menu is the main cause people leave (you have to win their attention again, starting with a malus) and/or don't try MT in the first place |
| 00:17 |
|
diceLibrarian joined #minetest-dev |
| 00:19 |
MTDiscord |
<savilli> What's so bad about the current mainmenu? |
| 00:19 |
MTDiscord |
<savilli> I mean it works |
| 00:24 |
MTDiscord |
<Warr1024> Read the Issue for it. |
| 00:25 |
MTDiscord |
<savilli> #6733 ? |
| 00:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/6733 -- Improve mainmenu [See proposal] |
| 00:26 |
MTDiscord |
<Warr1024> That looks like it might be the Table of Contents to what's wrong with the current main menu. |
| 00:27 |
MTDiscord |
<savilli> Sure, they're nice design improvements, but what's so critical about them? |
| 02:12 |
|
diceLibrarian joined #minetest-dev |
| 02:25 |
schwarzwald[m] |
<Zughy[m]> "Reminder that that menu is the..." <- How do we know this? |
| 03:35 |
MisterE[m] |
Zughy: all C55 said was that its worth watching. Its not like having a 3rd party launcher detracts from minetest development. Also, there was agreement that if it eventually became official in any sense, then it would be in the sense that Minetest would say... We endorse this launcher. IIUC |
| 03:36 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:27 |
|
calcul0n_ joined #minetest-dev |
| 07:15 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:26 |
celeron55 |
some users want fancy things, not minimalist and robust things. it could be that the main menu can never satisfy those users |
| 07:27 |
celeron55 |
this doesn't mean the main menu shouldn't be developed. it means exactly the opposite |
| 07:30 |
celeron55 |
you could even just directly copy the launcher's design and features if they end up liked a lot. don't think of it as competition |
| 09:18 |
|
freshreplicant[m joined #minetest-dev |
| 09:58 |
|
Fixer joined #minetest-dev |
| 10:51 |
|
kilbith joined #minetest-dev |
| 11:23 |
rubenwardy |
the main menu isn't even that minimalist, it's just poorly designed |
| 11:24 |
rubenwardy |
the fact that it includes a package manager and content installer means it's no longer minimalist |
| 11:24 |
rubenwardy |
My problem with launchers is that it makes in-game UIs second class. It would be nice to use a mainmenu redesign to dogfood our GUI APIs and improve them |
| 11:30 |
rubenwardy |
The current main menu is a terrible first impression. It's ugly, has bad UX, and doesn't promote Minetest's unique selling points |
| 11:32 |
celeron55 |
i don't mean minimalist functionally, but technically |
| 11:33 |
celeron55 |
it uses almost no resources and almost no code compared to a webview + node.js thing |
| 11:33 |
rubenwardy |
most users don't care about that |
| 11:34 |
rubenwardy |
most users care about the experience |
| 11:35 |
celeron55 |
anyway, what can one say. just improve it then? :D |
| 11:36 |
celeron55 |
i think you will agree the launcher is a good showcase for what the main menu could be |
| 11:36 |
rubenwardy |
very difficult given how painful formspecs and Irrlicht GUI is |
| 11:36 |
rubenwardy |
yeah |
| 11:36 |
rubenwardy |
making a third party launcher allows you to use a good GUI framework |
| 11:38 |
celeron55 |
i still think having a Lua 2D drawing API and building a Lua UI on top of that would make sense. it would be useful for the main menu and client-side mods. what the relation to formspecs would be, that remains to be answered |
| 11:39 |
rubenwardy |
v-rob was working on that, but is currently AWOL |
| 11:39 |
rubenwardy |
a GUI replacement would be an option alongside formspecs, and formspecs would be deprecated |
| 11:40 |
rubenwardy |
there's a big problem with people disappearing to take on gigantic bits of work |
| 11:41 |
rubenwardy |
they rarely finish as they end up burning out |
| 11:41 |
rubenwardy |
and if they do finish, it ends up unreviewable and hasn't received ongoing feedback |
| 11:41 |
rubenwardy |
the work needs to be split up and done in a staging branch or a feature flag in `master` |
| 11:45 |
pgimeno |
I've just been reading about v-rob's objections re Lua UI, they all affect client-server communication... that's something that kind of tells me that he was not using the right approach |
| 11:46 |
pgimeno |
https://github.com/minetest/minetest/issues/6527#issuecomment-1094125868 |
| 11:46 |
pgimeno |
s/tells me/suggests to me/ |
| 11:46 |
rubenwardy |
yeah, a server-side drawing API like that is a bad idea |
| 11:48 |
rubenwardy |
the server-side API should just be Lua DSL that represents a GUI. That can be sent using some structured format like BSON/JSON and then handles using a client-side Lua GUI framework - Lua UI |
| 11:49 |
rubenwardy |
Honestly, feels like using some HTML/CSS inspired thing like Rocket lib is the least bad option. Devs are familiar with it, these subsets can end up a lot lighter than chromium |
| 11:49 |
rubenwardy |
doing that would be a lot less work than making your own UI framework |
| 11:50 |
pgimeno |
I see that I misunderstood, that comment was not about why he closed #10801; the reasons for that are in the last post of the latter |
| 11:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/10801 -- Add CSM 2D Drawing API by v-rob |
| 11:50 |
kilbith |
I think v-rob scammed us all |
| 11:51 |
rubenwardy |
v-rob has done more than hecks |
| 11:51 |
kilbith |
who was talking about hecks? |
| 11:51 |
pgimeno |
define "scam" |
| 11:52 |
rubenwardy |
v-rob joined as a formspec dev and then felt pressured to work on a formspec replacement, and then inevitably burnt out |
| 11:52 |
kilbith |
predicting his fabled "GUI replacement" during years, showing nothing |
| 11:52 |
rubenwardy |
I assume |
| 11:52 |
pgimeno |
showing nothing? see the commits in 10801 linked above |
| 11:53 |
kilbith |
first it's the second class CSM API and it's very incomplete |
| 11:55 |
pgimeno |
I bet what burnt him out is that he'd have to start again, after realizing that his design was not powerful enough for what he aimed for |
| 11:55 |
pgimeno |
and that's demoralizing |
| 11:56 |
kilbith |
"done" is better than "perfect" |
| 12:03 |
rubenwardy |
it's important to do development in an iterative way rather than all at once. Starting with a Lua drawing API could be a good start for that |
| 12:03 |
rubenwardy |
a Lua drawing API invokes the question of CSM and SSCSM though |
| 12:06 |
pgimeno |
by the question do you mean whether they should be finished and deployed? |
| 12:07 |
rubenwardy |
yes. And also things like security, maturity, and direction |
| 12:16 |
pgimeno |
can Minetest currently run client-side Lua code apart from CSM? I'd say the menu does that, but I'm not sure if it's the internal server that runs it before connecting |
| 12:18 |
rubenwardy |
the menu is a separate environment |
| 12:18 |
rubenwardy |
there's no client or server at that point |
| 12:25 |
|
jwmhjwmh joined #minetest-dev |
| 12:26 |
jwmhjwmh |
Merging #12728 in 5m. |
| 12:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/12728 -- Consolidate API object code by TurkeyMcMac |
| 12:40 |
|
YuGiOhJCJ joined #minetest-dev |
| 12:42 |
rubenwardy |
merging #12834 in 5 |
| 12:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/12834 -- Make bloom shaders compatible with GLES2 by x2048 |
| 12:50 |
celeron55 |
i was talking about SSCSM on discord some... months ago (i guess?), one thought is that now that cdb works as well as it does, the arguments for SSCSM are getting less valid and instead the platform could be flipped around in such a way that what would have been done using SSCSM would be done using client-side mods that when in development would be installed like now, but regular users would |
| 12:50 |
celeron55 |
install them from cdb, and in addition that there could be some very limited "micro mods" that are lua code sent by the server but that have very limited APIs. i mean, a regular user and a regular developer will see SSCSM or any aim towards it to be a weakness of the engine, and what really would give the performance + features to users and devs is the turned-around model, with no real downside |
| 12:51 |
celeron55 |
it's against some of my original principles but my reasons against it are getting weaker as time goes by |
| 12:51 |
|
troller joined #minetest-dev |
| 12:52 |
celeron55 |
anyway, in that scheme formspecs could essentially disappear and be completely replaced by a client-local framework |
| 12:53 |
celeron55 |
again increasing the perforamnce and features |
| 12:53 |
celeron55 |
performance* |
| 12:54 |
celeron55 |
i guess the question is, can someone come up with an actual reason why that would fall apart |
| 12:55 |
rubenwardy |
how would a server/game request a client have a csm installed? |
| 12:55 |
celeron55 |
the original problem is that having to install client-side mods is a pain, thus SSCSM is the solution - but if you make installing them not a pain, then you don't have to solve any of the difficult problems that result |
| 12:56 |
rubenwardy |
I suppose the server could request CSMs in the initial handshake, and a ContentDB dialog could be shown on the client |
| 12:56 |
celeron55 |
yes |
| 12:56 |
celeron55 |
it's centralized, but the argument is that nobody cares |
| 12:56 |
rubenwardy |
it's centralised but you could also install the CSMs manually |
| 12:56 |
celeron55 |
and a client could have a whitelist of multiple cdbs and the server could use a full URL |
| 12:57 |
celeron55 |
which also gets around some of the problem of centralization |
| 12:58 |
sfan5 |
this sounds like its too specific for the "games come with CSMs" usecase |
| 12:58 |
sfan5 |
but if you have a server where the game is proprietary and not on CDB that kinda doesn't work |
| 12:59 |
sfan5 |
you'd probably end up with users installing a "sscsm loader" mod which just executes some code that server shoves over a modchannel |
| 12:59 |
sfan5 |
which is not any different from SSCSM |
| 12:59 |
celeron55 |
well the argument related to that is, it's probably ethical to allow users to see (or refer to a peer of theirs to review) any client-side code they run on their machine |
| 13:00 |
celeron55 |
so it would be ok to require proprietary servers to publish their client-side code |
| 13:00 |
celeron55 |
that's true |
| 13:00 |
celeron55 |
however, it's already possible |
| 13:00 |
celeron55 |
why isn't it in widespread use? |
| 13:01 |
sfan5 |
I'd say because enabling and setting up csms is a (somewhat intentionally) complicated process |
| 13:01 |
sfan5 |
and also the csm APIs don't really do everything game writers would hope |
| 13:02 |
celeron55 |
so the argument for SSCSM is that there's no sense in going around it, because proprietary servers will force the equivalent on their players anyway |
| 13:03 |
nrz_ |
i like the effort you put over the primitives i developed a time ago, is there any big mod using mod channels nowadays ? i saw the inteeresting mod about mumble and CSM yesterday it's fcool |
| 13:03 |
sfan5 |
here's a comprehensive game-bound CSM example however -> https://github.com/oilboi/crafter_client |
| 13:04 |
sfan5 |
celeron55: sort of that's part of it, fundamentally having the server send exactly the code it wants over to the client is much more flexible |
| 13:05 |
sfan5 |
also you run into problems with permissions if CSMs are only loaded from the client disk and not somehow verified -> free xray |
| 13:05 |
celeron55 |
i think we (the core team) should publish a set of reasonings for the current client-side modding plan, eg. based on this discussion, so that it could be referred to by anyone wondering about it |
| 13:05 |
sfan5 |
because you want "real" CSMs to do things like influence rendering, which should be up to the game |
| 13:06 |
sfan5 |
I wouldn't say there is really a plan :D |
| 13:06 |
celeron55 |
well, there's no plan, but there are good reasons to not do some things some people are suggesting |
| 13:07 |
sfan5 |
you could probably piece relevant information together by reading (ss)csm discussions that already happened on the bug tracker a while ago |
| 13:07 |
celeron55 |
one of the ideas that also comes up is that the quickest safe solution should be put in place, because otherwise it will take ages to have anything |
| 13:07 |
celeron55 |
what that would be, is a good question |
| 13:08 |
celeron55 |
a problem is that this issue ties particularly hard to the UI stuff |
| 13:09 |
celeron55 |
if there was a way to relieve this somehow, it would move everything forward |
| 14:01 |
|
troller joined #minetest-dev |
| 14:06 |
Zughy[m] |
A mainmenu and a launcher can't be designed separately: if you do, both the parties will waste time in implementing the same thing on each other's side. There must be some sort of dialogue, a thoughtful approach about what to put where and how. We can't just say "well, let's leave people do their thing" |
| 14:07 |
Zughy[m] |
And then implement the fastest approach, forcing the other one to adapt |
| 14:08 |
Zughy[m] |
If I know people wants a launcher, I'll design my mainmenu differently, because I'll be conscious that some aspects are better ported onto the launcher rather than the mainmenu. And viceversa |
| 14:12 |
Zughy[m] |
Instead, what we have now is a launcher that features a multiplayer section (why?), games (why?) and I'm not sure if there is CDB as well. This will turn into a mess pretty soon because we're just letting the dude do what they want and then maybe implement it as kind-of-official one day. That's not how things should be done, in my opinion. And as someone who's directly involved in designing the mainmenu, I'm also kind of offended by such |
| 14:13 |
Zughy[m] |
a similar approach |
| 14:17 |
|
jwmhjwmh joined #minetest-dev |
| 14:17 |
celeron55 |
well first of all, if someone wants to make a launcher, you can't prevent it. it's up to them |
| 14:18 |
celeron55 |
second, the launcher obviously will not launch MT into the main menu. it will launch MT directly into a game |
| 14:18 |
celeron55 |
it's essentially an alternative main menu, there's no need for dialogue |
| 14:19 |
celeron55 |
third, you shouldn't be offended but rather take in ideas and improve. it's not like the main menu will be removed |
| 14:19 |
kilbith |
we have had to develop a proprietary launcher when I worked at kidscodde |
| 14:20 |
celeron55 |
it's silly to expect the launcher project to get finished to begin with, let alone be maintained for a long time |
| 14:20 |
kilbith |
with auto-updating of mods/worlds, in Steam fashion |
| 14:20 |
rubenwardy |
if you make it fullscreen, it's pretty much just a mainmenu anyway |
| 14:24 |
kilbith |
now imagine if someone invent a moddable launcher, it will relegate the main menu experience to an old bad memories |
| 14:24 |
kilbith |
and we'll no longer need it |
| 14:25 |
celeron55 |
definitely wouldn't count on that happening, but it would be interesting to see. also, quite a challenge to make it work on all platforms |
| 14:26 |
kilbith |
I mean with Qt it's the right way to go |
| 14:26 |
rubenwardy |
I just think it would be a bit funny if we made an external program to handle an engine GUI because minetest's GUI sucks |
| 14:26 |
rubenwardy |
like, games and mods don't have that option |
| 14:26 |
celeron55 |
i can also see it could play out this way in the next decade: someone makes a launcher which almost everyone uses because UI work stays stuck due to client side modding concerns, then at some point the UI work gets done including a better main menu and people move back to that |
| 14:27 |
kilbith |
what about strip MT to a bare in-world experience wihtout a mainmenu? |
| 14:29 |
celeron55 |
you have to somehow have all the other menus though |
| 14:29 |
celeron55 |
including in-game and mod-specific menus |
| 14:29 |
celeron55 |
again, on all platforms, including touchscreens and phones |
| 14:30 |
celeron55 |
if you manage to make it work and it looks nice techncially and visually, i guess why not. but the only valid proof that it can work is actually making it |
| 14:30 |
celeron55 |
because it sounds silly |
| 14:30 |
kilbith |
MT would just operate from the command line options that a launcher orders |
| 14:30 |
kilbith |
and the mod formspecs are out of the question ofc |
| 14:31 |
celeron55 |
well it already can do it, no need to strip |
| 14:31 |
celeron55 |
it can be stripped some day if we find out nobody is using the main menu anymore |
| 14:31 |
celeron55 |
however that seems extremely unlikely |
| 14:32 |
celeron55 |
i do have to say the support for launchers is 100% intentional |
| 14:33 |
celeron55 |
i'm fairly certain --go was added by me and i knew it could be used for a launcher even back then |
| 14:34 |
kilbith |
and if CDB has an API to update its content, you're good to know to recreate Steam |
| 14:34 |
kilbith |
* to go |
| 14:35 |
rubenwardy |
I shameless steal design elements from GitHub and Steam for CDB's frontend |
| 14:36 |
kilbith |
because Steam is the platinium standard for launchers |
| 14:37 |
rubenwardy |
I'd like to launch Minetest to Steam, but a new mainmenu would be a requirement |
| 14:37 |
rubenwardy |
a third party launcher that uses minetest's cli is functionally a main menu |
| 14:38 |
Zughy[m] |
If there is someone that's doing the work for me and people are now discussing to get rid of MT mainmenu as a whole, there's no need for me to continue my design |
| 14:38 |
Zughy[m] |
Which is good, because was a pain in the arse |
| 14:39 |
Zughy[m] |
Also they don't have to deal with MT limitations, which are a malus to say the least |
| 15:03 |
|
Desour joined #minetest-dev |
| 15:37 |
Desour |
regarding the suggestion from earlier to let users install CSMs from the CDB instead of adding SSCSM: Please don't do that, it's a really bad idea for several reasons: (1) It provides barely any security benefit to layman users, who don't read through the stuff. (2) It's implementation-wise probably not less complicated than just sending the mods. (I.e. you'd still have to create a separate env for these not-sent-SSCSMs (NSSSCSMs), and make hashsums to |
| 15:37 |
Desour |
avoid cheating.) (3) Users would already know about the installed mods before they join, and will be confronted with spoilers of the game content. (4) It breaks with one of the biggest strengths of minetest: You can just join any modded server without installing anything locally first. And the list goes on. |
| 15:39 |
rubenwardy |
The security benefit is providing authorship information and some code review of less trusted authors |
| 15:39 |
Desour |
If you want to show users what mods are installed to avoid potential cheating, you could still do this afterwards as an optional client-side feature, where you list the mods on join, with hashsums of their files and links to the CDB, that are looked up via these hashsums. |
| 15:39 |
celeron55 |
well, i don't believe the list goes on that much. but yes, those are the well known arguments for it |
| 15:40 |
celeron55 |
(for SSCSM that is) |
| 15:40 |
sfan5 |
Zughy[m]: fyi there's no say that the mainmenu has to be built with normal formspec elements |
| 15:40 |
rubenwardy |
another benefit is having a record of versions, I'd make it so you can't delete client-side mod releases |
| 15:41 |
sfan5 |
you can invent new ones as you want, as specific as you want and we don't have to support them for ingame mods |
| 15:41 |
Desour |
(5) It's centralized, meh. (6) It's bad for testing. (7) You'd have to maintain the mods in your local hard drive. |
| 15:41 |
sfan5 |
if you were meaning to say "irrlicht limitation" instead of "mt limitations" then yes that still applies |
| 15:42 |
rubenwardy |
I'd be happy with SSCSM if work was put in to secure the environment and solve LuaJIT issues, and there was a killswitch to disable SSCSM on known insecure versions of MT |
| 15:43 |
celeron55 |
probably the hardest part in getting SSCSM rolling is that someone has to define a Lua environment and declare it sandboxed safely enough to run server-sent code |
| 15:43 |
rubenwardy |
you'd also have to have some way to declare licenses or at least allow for Debian disabling the feature, because they would |
| 15:43 |
celeron55 |
(i'm saying, it's not technically difficult) |
| 15:43 |
celeron55 |
(after someone does that) |
| 15:43 |
rubenwardy |
the level of security I'm looking for with SSCSM is "as secure as our current network protocol" :D |
| 15:44 |
sfan5 |
the annoying part is moving/writing csm apis in a way it can be moved to a sandboxed process, which requires IPC |
| 15:44 |
rubenwardy |
and that's not even considering cryptominers |
| 15:44 |
sfan5 |
rubenwardy: I believe Debian does not ship browsers with javascript disabled |
| 15:44 |
rubenwardy |
oh good point |
| 15:45 |
celeron55 |
using sandboxed processes does simplify the "is this safe?" question |
| 15:45 |
celeron55 |
and moves the trouble towards the amount of implementation work |
| 15:46 |
MTDiscord |
<savilli> Debian also doesn't ship browsers which didn't pass security review |
| 15:46 |
MTDiscord |
<savilli> Who want to pay for security review for minetest? |
| 15:46 |
Desour |
If you want to sandbox a process, don't just do that on the lua running thing, but on the whole client. |
| 15:46 |
rubenwardy |
yeah, "authorship information" allows the user to know whose code they're trusting |
| 15:47 |
sfan5 |
Desour: that doesn't work |
| 15:47 |
Desour |
sfan5: why? |
| 15:47 |
celeron55 |
as long as the security review isn't obnoxiously expensive, i believe it could be crowdsourced |
| 15:47 |
rubenwardy |
<rubenwardy> yeah, "authorship information" allows the user to know whose code they're trusting |
| 15:47 |
rubenwardy |
which makes it more like installing mods rather than running remote code |
| 15:47 |
celeron55 |
or some company might directly donate a review. dunno |
| 15:47 |
celeron55 |
in any case it doesn't sound impossible if it's needed |
| 15:48 |
rubenwardy |
there's no way it'll be cheap |
| 15:48 |
celeron55 |
it would depend on how the sandbox is implemented |
| 15:48 |
celeron55 |
if it has a simple interface, it should be less work to review |
| 15:48 |
rubenwardy |
I'd like to release to Steam. If we formed a non-profit for Minetest, we could charge a couple of $ for it on Steam as a way to raise money |
| 15:48 |
Desour |
they'd have to look into minetest's whole codebase, and that for each version, right? |
| 15:49 |
rubenwardy |
people will pay for the convenience |
| 15:49 |
sfan5 |
Desour: the entire client has way too many things it is allowed to do, assuming an attacker can break out of lua there's still way too much to do |
| 15:49 |
sfan5 |
there's a reason browsers aren't doing the "sandbox the whole process" thing |
| 15:49 |
rubenwardy |
will, browsers have access to a lot of information like history and bookmarks |
| 15:50 |
rubenwardy |
whereas a lot of Minetest's info is low importance, it's the host system we need to protect against |
| 15:50 |
rubenwardy |
if MT's info was important then we'd have network encryption :) |
| 15:50 |
Desour |
^ and cookies |
| 15:50 |
sfan5 |
for example here's a diagram for chromium https://docs.google.com/drawings/d/1TuECFL9K7J5q5UePJLC-YH3satvb1RrjLRH-tW_VKeE/edit |
| 15:50 |
rubenwardy |
The reason that installing CSMs from CDB is suggested over SSCSM is that it side steps the whole security issue, and makes it more like installing mods |
| 15:51 |
MTDiscord |
<savilli> It would be nice if people who actively agitate for SSCSM pay for it XD |
| 15:51 |
rubenwardy |
oh that's useful |
| 15:51 |
MTDiscord |
<savilli> But I don't think it would be enough |
| 15:51 |
Desour |
I'll pay with my time at some point |
| 15:55 |
rubenwardy |
I suspect there's a lot of unknown security issues in the network protocol |
| 15:55 |
celeron55 |
i guess it would make sense to start building it from the ground up, so sandboxed Lua process(es) first, then some APIs and then see where it goes from there |
| 15:55 |
MTDiscord |
<savilli> And if security audit would find tons of vulnerabilities in lua compiler, who would fix them? I'm sure that LuaJIT author wouldn't particularly motivated to fix them. |
| 15:56 |
celeron55 |
of course including the IPC system |
| 15:56 |
rubenwardy |
LuaJIT is likely to be a problem if used by the client-side env. We might be able to resolve it be disabling JIT, but we might have to switch to PUC Lua for that |
| 15:57 |
celeron55 |
well as long as client-side Lua runs in a sandboxed process, LuaJIT will barely be a problem. but PUC is the better bet |
| 15:57 |
|
kilbith joined #minetest-dev |
| 15:58 |
celeron55 |
sfan5 seems to have a pretty good idea where the pain points are in actually making this work with reasonable risk |
| 15:59 |
MTDiscord |
<savilli> What kind of process sandbox would it be? Writing a good cross-platform sandbox is hard, ask chromium developers. |
| 16:00 |
celeron55 |
i'd imagine there are some libraries. but it comes down to launching a child process and setting up IPC to it, and then serializing the script API over the IPC |
| 16:00 |
sfan5 |
seccomp on linux, https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox.md apparently describes what chromium does on windows |
| 16:00 |
sfan5 |
(appears to be part of win32) |
| 16:01 |
celeron55 |
(and of course, revoke all possible system privileges from the child process) |
| 16:02 |
sfan5 |
macos, bsd and android users are probably out of luck |
| 16:04 |
sfan5 |
this was my list for csm last time https://user-images.githubusercontent.com/1042418/97895938-b65d3a00-1d34-11eb-9603-d05d73e87999.png |
| 16:04 |
rubenwardy |
looks good |
| 16:05 |
celeron55 |
that seems like a much more lightweight approach with much more risk |
| 16:05 |
celeron55 |
it could be fine. who knows |
| 16:05 |
MTDiscord |
<GoodClover> "unknown security issues in the protocol". Well, considering it's trivial to accidentally segfault the client via the protocol… |
| 16:06 |
MTDiscord |
<GoodClover> (and no, I haven't opened any issues, that requires identifying the problem) |
| 16:06 |
sfan5 |
I also considered that there could be accelerated process where sandboxing isn't done yet™ but that probably users end up enabling sscsm anyway unaware of potential security issues |
| 16:06 |
sfan5 |
because users love features |
| 16:07 |
celeron55 |
the question seems to be, can we accept the risk of allowing a malicious server to run Lua code in the main client process, or is it essential that we only run it in an unprivileged child process and only touch that with a long pole (i.e. IPC) |
| 16:07 |
celeron55 |
threads don't help much. it's mostly about the address space. same process = same address space |
| 16:08 |
sfan5 |
@GoodClover it's always funny hearing about issues that are an open secret but apparently nobody bothers to report |
| 16:08 |
Desour |
latter makes sense iff the lua interpreter is buggier than our code |
| 16:08 |
celeron55 |
the lua interpreter isn't buggy, but we expose a lot of stuff to it creating a large attack surface |
| 16:09 |
celeron55 |
(or, it could be buggy, but the point is that doesn't matter) |
| 16:09 |
celeron55 |
it's enough that we expose buggy C++ stuff to it |
| 16:09 |
celeron55 |
also called "minetest APIs" |
| 16:11 |
celeron55 |
essentially the required security boils down to the same level that would be needed if we downloaded mod code as dynamic libraries and just loaded them right up |
| 16:11 |
celeron55 |
it's kind of funny |
| 16:11 |
Desour |
but if we expose stuff to it via IPC, it's not directly more isolated. mods can just alter data in the main client process via the IPC (just like currently the server can) |
| 16:12 |
celeron55 |
yes but the IPC is much more controllable. it can enforce length checking all data and whatnot. that's why i refer to it as a long pole |
| 16:12 |
celeron55 |
after all it's what modern browser security is also based on |
| 16:12 |
Desour |
but we could do exactly the same checks in the normal lua/C API |
| 16:14 |
celeron55 |
it would be interesting to hear the opinion of someone who does security reviews professionally |
| 16:14 |
|
jwmhjwmh joined #minetest-dev |
| 16:15 |
celeron55 |
the nature of IPC is fairly close to the nature of our current network connection between the client and the server |
| 16:15 |
celeron55 |
i.e. security inherently does not get worse, as long as the system handles process sandboxing properly |
| 16:15 |
Desour |
btw. the "sandboxing in lua isn't safe, do process isolation" stuff refers to the idea of running untrusted lua code *in* lua. this is hard to do, but if you don't expose anything in the whole lua state, it should be somewhat fine, AFAIK |
| 16:16 |
celeron55 |
i mean, whatever the security is currently is pretty much the level after the addition too |
| 16:19 |
celeron55 |
if you use Lua as the sandbox instead of a sandboxed process, then the nature of the attack surface changes: instead of being essentially a network connection, it becomes Lua itself plus directly all functions and data exposed to Lua. from the attackers perspective, instead of being able to affect essentially a serial data stream, they can call various functions in any order they want, with any |
| 16:19 |
celeron55 |
parameters they want |
| 16:20 |
celeron55 |
calling it an orders of magnitude difference is an understatement |
| 16:21 |
celeron55 |
of course when you look at the forest made by the trees, the IPC will end up being abstracted as functions that take parameters |
| 16:21 |
celeron55 |
that's where i'd like to hear what the professional security auditor would have to say |
| 16:22 |
Desour |
well true. and doing the same kind of checks, but without IPC, you'd just do deserilaize(serialize(...)), which wouldn't be much easier to do |
| 16:22 |
celeron55 |
i bet it's something like "better have multiple levels of security rather than one" |
| 16:22 |
|
MTDiscord joined #minetest-dev |
| 16:22 |
|
fluxionary joined #minetest-dev |
| 16:22 |
|
book` joined #minetest-dev |
| 16:22 |
|
ShadowNinja joined #minetest-dev |
| 16:22 |
|
ShadowBot joined #minetest-dev |
| 16:22 |
|
jonadab joined #minetest-dev |
| 16:22 |
|
TheCoffeMaker joined #minetest-dev |
| 16:22 |
|
dzho joined #minetest-dev |
| 16:22 |
|
sofar joined #minetest-dev |
| 16:22 |
|
Thomas-S joined #minetest-dev |
| 16:22 |
|
cheapie joined #minetest-dev |
| 16:23 |
rubenwardy |
I suspect the security auditor will probably say something like "what the fuck are you doing in my house, get out before I call the place" |
| 16:23 |
|
MTDiscord1 joined #minetest-dev |
| 16:23 |
rubenwardy |
I suspect the security auditor will probably say something like "what the fuck are you doing in my house, get out before I call the place" |
| 16:24 |
|
rubenwardy joined #minetest-dev |
| 16:25 |
celeron55 |
"you're making a game, right? why don't you then just make a game instead of this BS" |
| 16:25 |
schwarzwald[m] |
Didn't erlehmann have some background in security auditing, or was that something else? |
| 16:25 |
Zughy[m] |
Erlehmann is gone |
| 16:25 |
schwarzwald[m] |
Well, that's a bummer. |
| 16:28 |
pgimeno |
what's wrong with using LuaJIT instead of PUC Lua? |
| 16:28 |
pgimeno |
security-wise |
| 16:28 |
rubenwardy |
JIT + complex implementation + less eyes |
| 16:28 |
pgimeno |
jit.off() -> no JIT |
| 16:28 |
rubenwardy |
s/less/fewer |
| 16:29 |
pgimeno |
^.^ |
| 16:29 |
Desour |
the interpreter is also more complex than PUC |
| 16:29 |
celeron55 |
Lua itself is simple enough that almost any programmer has the capacity to review it in its entirety |
| 16:29 |
celeron55 |
that's a really good thing for security |
| 16:30 |
celeron55 |
PUC Lua, i mean |
| 16:31 |
celeron55 |
LuaJIT isn't terribly bigger, less than double. but it's more, and it's JIT |
| 16:31 |
pgimeno |
it's not JIT if the JIT is disabled |
| 16:31 |
sfan5 |
probably nobody except mike pall understands the JIT parts of luajit |
| 16:32 |
rubenwardy |
is there a way to link the secure process to Lua and the main process to LuaJIT |
| 16:32 |
celeron55 |
if you literally remove the JIT capability from the code and then review the end result, then i guess it's pretty much the same deal. but why would you even do that |
| 16:32 |
rubenwardy |
that would probably be a bit crazy |
| 16:32 |
sfan5 |
in any case especially because we'll be dealing with unmaintained software (5.1) or a complex beast (luajit) potential CSMs should be in a separate, sandboxed process |
| 16:32 |
rubenwardy |
celeron55: so you can still run server-side/singleplayer mods in JIT |
| 16:33 |
celeron55 |
of course you can link a different process with a different library |
| 16:33 |
celeron55 |
that's a no-brainer |
| 16:33 |
pgimeno |
celeron55: because it's still faster, and because you can disable the JIT without removing it, so you can use the same interpreter for the normal mods and the CSM |
| 16:34 |
pgimeno |
I agree, the JIT *must* be disabled for security in CSM |
| 16:34 |
celeron55 |
being able to enable JIT sounds like a fun attack surface in itself |
| 16:34 |
celeron55 |
the first thing an attacker will try to do 8) |
| 16:34 |
pgimeno |
you can't do that without the jit namespace in the first place |
| 16:34 |
pgimeno |
or without the jit.on() function |
| 16:34 |
celeron55 |
namespace is just a logical thing. the attacker will think in address space |
| 16:35 |
rubenwardy |
hard to do if bytecode is disabled |
| 16:35 |
pgimeno |
yeah, bytecode must be disabled of course |
| 16:35 |
pgimeno |
I assumed that, it's a known attack vector |
| 16:35 |
rubenwardy |
and if this is with C shenanigans then you have bigger issues |
| 16:35 |
Desour |
then the attacker first has to find a way to write in address space, but then they already got too far |
| 16:35 |
celeron55 |
they do need to have already found a vulnerability before that, of course. but it just makes it more fun afterwards |
| 16:36 |
celeron55 |
the security i trust in is all about making the potential attacker's life miserable in every possible way |
| 16:36 |
celeron55 |
so that they get depressed and won't even try |
| 16:37 |
celeron55 |
might be too inconvenient for us though |
| 16:37 |
Desour |
the ultimate solution: add really demotivating code comments |
| 16:37 |
rubenwardy |
the ultimate solution: delete all the code, defenestrate your computer, and live in woods |
| 16:38 |
Desour |
TIL: the word "defenestrate" exists, thank you! |
| 16:38 |
celeron55 |
i'm almost doing that already |
| 16:39 |
celeron55 |
anyway |
| 16:39 |
celeron55 |
it's true that with the process sandboxing luajit could be used with not much risk |
| 16:40 |
celeron55 |
it's fun to think of it like this: |
| 16:40 |
celeron55 |
what essentially happens is the server sends the client an untrusted process, that the client then sets up and runs, and then talks with it as a black box that can't do anything else than talk |
| 16:41 |
pgimeno |
gimp already does that with plugins |
| 16:41 |
celeron55 |
that's kind of the goal |
| 16:41 |
pgimeno |
IPC + shared memory to share stuff... it gets complex though |
| 16:42 |
celeron55 |
well. it seems to come down to either doing it or not. if not, then there will be no SSCSM |
| 16:42 |
celeron55 |
unless someone comes and explains why the risk isn't too big |
| 16:45 |
pgimeno |
I can think of an intermediate solution... have servers send the server-sent mods to the CDB, and then the server requests installation from the CDB instead of sending it directly to the client |
| 16:46 |
Desour |
I don't trust the CDB |
| 16:46 |
Desour |
it's content I man |
| 16:47 |
Desour |
mean* |
| 16:47 |
pgimeno |
I know it's content |
| 16:47 |
Desour |
if you send it to CDB first and let it download from there, it still comes from the server and wasn't checked in any way |
| 16:47 |
Desour |
its* |
| 16:47 |
pgimeno |
ah |
| 16:48 |
pgimeno |
not what I had in mind |
| 16:48 |
pgimeno |
what I had in mind is to only allow reviewed mods to be requested by the server and installed automatically |
| 16:49 |
Desour |
ah |
| 16:49 |
Desour |
reviewing would be too much work though |
| 16:50 |
pgimeno |
it's the only way to make it work without very rigorous sandboxing of the kind that celeron was suggesting, I believe |
| 16:50 |
celeron55 |
pgimeno: that's where this discussion started. i asked people to think about that option |
| 16:51 |
celeron55 |
you should read what sfan5 commented to it |
| 16:51 |
celeron55 |
like this: |
| 16:51 |
celeron55 |
17:40:34 <+sfan5> [15:59:52] you'd probably end up with users installing a "sscsm loader" mod which just executes some code that server shoves over a modchannel |
| 16:51 |
Desour |
celeron55: nah, the discussion started with mods on the cdb (not reviewed) that users install manually |
| 16:51 |
Desour |
ah, ok, yes |
| 16:52 |
rubenwardy |
The sandbox could remove loadstring to make sscsm loaders impossible |
| 16:52 |
rubenwardy |
Or ContentDB could prohibit them |
| 16:52 |
celeron55 |
a user can still install it manually |
| 16:52 |
Desour |
^ one could then just write an interpreter in lua |
| 16:52 |
pgimeno |
well, you can't prevent users from shooting themselves in the foot, I don't think you can blame MT for that |
| 16:52 |
rubenwardy |
Then it's not our problem |
| 16:53 |
celeron55 |
ok so that's one way to think about it: where is the line of "not our problem" |
| 16:53 |
Desour |
just make it off by default and add a big warning stating it should never be activated. => it's always the user's fault |
| 16:53 |
pgimeno |
that counts to me as the same as the user installing a mod that erases the root dir |
| 16:54 |
celeron55 |
one opinion is that no mod should ever be able to erase the root dir, regardless of settings |
| 16:55 |
pgimeno |
I mean, users can flip the "trusted" flag on any mod they want and then that mod has full access to FFI and the whole C API, is that our problem? |
| 16:55 |
Desour |
you could launch minetest with firejail if that's your opinion |
| 16:56 |
celeron55 |
sandboxing the entire client process would be a good way to prevent really bad things happening directly, that could be enough, like someone mentioned |
| 16:56 |
pgimeno |
good luck with that :) |
| 16:57 |
celeron55 |
but it might be very iffy given GPU use and whatnot |
| 16:57 |
celeron55 |
so part of it has to be non-sandboxed anyway |
| 16:58 |
celeron55 |
which means, there has to be IPC anyway |
| 16:58 |
celeron55 |
which means, might as well put that where there has to be an API anyway |
| 16:59 |
celeron55 |
the data has to live in the GPU process in any case for performance reasons so that might as well as be the main process |
| 16:59 |
celeron55 |
so, nothing changes |
| 17:02 |
Desour |
you don't need to open arbitrary files (i.e. in the /home dir) to do graphics. so there is at least some sandboxing possibility |
| 17:03 |
celeron55 |
it's worth looking into |
| 17:09 |
pgimeno |
it's true that the GPU could be an attack vector - Second Life had griefers DoSing clients by sending certain bloom parameters |
| 17:10 |
Desour |
we aren't protecting from dos attacks |
| 17:12 |
celeron55 |
yes, it's probably unfeasible to go after all DoS possibilities |
| 17:12 |
pgimeno |
it's an example; I'm not sure how well reviewed are the GL implementations, security wise, especially given that many of them are closed source |
| 17:13 |
pgimeno |
I can imagine a possible buffer overflow or the like |
| 17:14 |
celeron55 |
the thing about those is, you already run GLES in the web browser. not exactly the same, but not very far either |
| 17:14 |
pgimeno |
fair point |
| 17:15 |
celeron55 |
what i would be more afraid of is that some opengl implementation would require some sort of essentially random access to the file system or something else in order to function |
| 17:15 |
celeron55 |
would be stupid of course, and probably web browsers have already cleared this path for us, due to the reason i mentioned |
| 17:17 |
celeron55 |
the main reason this could work which was already mentioned but which i do agree with is that MT isn't used (or meant to be used) for processing secrets like banking details or any such things, which means an attacker, just by gaining access to the rest of the MT client itself, doesn't gain much |
| 17:19 |
celeron55 |
as long as process level permissions are set up tightly enough |
| 17:22 |
celeron55 |
then if the client would additionally only use PUC Lua, it starts to look reasonable from a security perspective, given the two barriers each of which has a reasonable likelihood of stopping an attacker doing anything harmful to anything else than MT itself |
| 17:23 |
celeron55 |
the Lua API needs way more consideration than what's currently done though |
| 17:23 |
celeron55 |
if it would be considered to be any kind of security barrier |
| 18:18 |
|
jwmhjwmh joined #minetest-dev |
| 18:58 |
MTDiscord |
<x2048> Pushing https://gist.github.com/x2048/bec7b282fcebb6852aa734ecdbe55023 soon, fixes undersampling without shaders. |
| 19:03 |
MTDiscord |
<x2048> Done |
| 19:38 |
pgimeno |
nice catch |
| 20:15 |
|
kilbith joined #minetest-dev |
| 20:22 |
|
diceLibrarian joined #minetest-dev |
| 20:34 |
kilbith |
that's only what I get with a 11th i9, 32 GB of RAM and RTX 3050 Ti @ 200 nodes render distance and shaders enabled: https://i.imgur.com/FqEUrRc.png |
| 20:34 |
kilbith |
tell me what's going on with MT already |
| 20:35 |
kilbith |
my laptop is a freaking monster and it can't cope with MT |
| 20:40 |
MTDiscord |
<savilli> Hardware issue |
| 20:43 |
kilbith |
h/w issue what? I run Doom Eternal on high settings @ 60 FPS at 4K man |
| 20:43 |
kilbith |
the joke |
| 20:47 |
kilbith |
would probably run better on a 10 yo Thinkpad, the target hardware MT has been optimized for |
| 21:01 |
rubenwardy |
doubtful |
| 21:01 |
rubenwardy |
runs very well on my steam deck |
| 21:02 |
rubenwardy |
MT is cpu bound and that's a good spec cpu, there's probably something random limiting it, perhaps nvidia related |
| 21:03 |
rubenwardy |
you should look into renderdoc or whatever, see where the time is being spent |
| 21:04 |
rubenwardy |
not really my area of expertise though |
| 21:15 |
kilbith |
well it may be PRIME failing to enable the GPU but still... it's a freaking i9! |
| 21:48 |
|
jwmhjwmh joined #minetest-dev |
| 21:56 |
MTDiscord |
<savilli> Integrated GPU can't process shaders, so they're calculated on CPU instead |
| 21:56 |
MTDiscord |
<savilli> Ofc it's laggy |
| 22:26 |
MTDiscord |
<Benrob0329> I'm pretty sure that's false, since every modern OpenGL pipeline requires custom shadercode |
| 22:27 |
MTDiscord |
<Benrob0329> and I don't mean "modern games need shaders" I mean that literally per the spec modern OpenGL versions need the application to provide it's own shaders |
| 22:30 |
rubenwardy |
Yeah, integrated GPUs are pretty good these days and can run shaders well |
| 22:33 |
pgimeno |
I'd be curious to see the scene being rendered, the number of polygons on screen and whatnot... let's not forget Minetest has no LOD support |
| 22:33 |
rubenwardy |
We could use some rendering benchmarks |
| 22:37 |
|
panwolfram joined #minetest-dev |
| 23:12 |
|
jwmhjwmh joined #minetest-dev |
| 23:34 |
|
kilbith joined #minetest-dev |
