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: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: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
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
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:26 jwmhjwmh       Merging #12728 in 5m.
12:26 ShadowBot      https://github.com/minetest/minetest/issues/12728 -- Consolidate API object code by TurkeyMcMac
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: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: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 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: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: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: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: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 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: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: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: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: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