[SSCSM] Plans to move forward

[pyrollo]

A try to revive this project of having server sent scripts executed on client.
I have not in mind all possibilities it could add but yet I imagine formspec interaction and HUD control with no useless client/server dialog, sound control, responsive things.

Instread of long « Server Send Client Side Mod », I propose « Server Sent Script » as name.

Actually working on it in this WIP branch : https://github.com/pyrollo/minetest/tree/sscsm

TLDR

Try to have a draft version of SSCSM :

• The server sends to the client all scripts found in each mod client directory ;
• The client receives and stores scripts in memory ;
• The client runs all init.lua scripts in the order given by the server (same as server mod order) ;
• Client Lua environment very limited (minimum required) ;

Plans

Basic plan: have a working, not optimized version, test security and then make things shiny.

Server side

Code to be sent to client will be:

• In builtin directory (what to send is to be determined) ;
• In client directory of each server mod ;

At startup, server grabs files to send, compress them, keep them in memory ready to be sent.

On client connection, following information is sent:

• mods loading order (using same order as server mod order) ;
• files contents, indexed by path (relative to mod client folder) and mod name ;

Client Side

Client has to perform follining tasks :

• Receive scripts ;
• Store scripts ;
• Run scripts ;

Script reception

No particular problem for this.

Script storage

Proposal have been made to use a specific folder on disk for server sent script storage. I’m not convinced with this approach and prefere memory storage because :

• Storage should be volatile (don’t keep anything after disconnection) ;
• Storage should be instance specific (if two clients are running, they should not share any server sent code) ;
• CSM already implements memory storage(*) ;
• Risk is low (client OOM), and could be reduced by a size limitation in scripts ;

Creation of a set of classes for script storage would be very convenient : ScriptStorage (pure virtual), ScriptFileStorage and ScriptMemoryStorage. Each scripting would have it’s storage given at initialization.

Script execution

For each mod, in the server mod order, client/init.lua will be loaded and executed.

dofiles and so should only be able to load server send scripts from the same mod.

Risks

Basic rule will be : If server sent script has no possibility to do evil, it won’t.

I mean, never trust what server sends, trust only client security.

Acceptable risks

• Server crashing client (no risk for player, he/she would probably just stop connecting to this server).

Inacceptable risks

• Server altering anything on client computer. This includes no file access.
• Server getting any information from client computer, except game related.

For storage, server sent script should only use minetest provided storage (mod storage, maybe other client side storage related to map, player, game…).

Other considerations

We'll have to deal with client version compatibility versus server sent script code.

Existing stuff

Important readings

Server-provided client-side scripting (#5393)
CSM mod sending design (#7043)
Client-side API sandboxing (#7041)
Add network encryption into minetest (#10206)

Existing code

CSM: A lot has already be done for CSM. Maybe lot of code could be reused.
Desour work on script sending (branch)
This branch contains work for grabing, compressing, sending, receiving and uncompressing files.
I started from there but I’m not sure to keep it all at the end. Some information are missing : mods & mods loading order.

Implement CSM mod sending (nerzhul - closed)
Very little changes, not interresting so far.

SSCSM implementation (Kimapr - closed)
Wrong way to implement SSCSM I guess.

[red-001]

Sending builtin means that future builtin code needs to be backwards compatible with old versions of the game which isn't currently the case for builtin. Might be easier to just implement that whole checksumming builtin scheme, I was thinking just have a python script in util that someone re-runs every time they change a part of builtin the client loads, seemed like an okay workflow when I made a PoC for it.
Could probably cut down on the code duplication if you add a csm_type argument to the ClientScripting constructor, especially since UI re-design in Lua could mean a third Lua state/sandbox running on the client.

[pyrollo]

Sending builtin means that future builtin code needs to be backwards compatible with old versions of the game which isn't currently the case for builtin. Might be easier to just implement that whole checksumming builtin scheme, I was thinking just have a python script in util that someone re-runs every time they change a part of builtin the client loads, seemed like an okay workflow when I made a PoC for it.

I guess there will be (long) discussions about builtin stuff sent by server and builtin stuff shipped with client. Anyway, base mechanism can be developed before that.

I don't catch the checksumming thing. Would it be a way to ensure compatible versions between server and client ? If it's to rigid, it wont be usable (same client connecting to different server versions).

Could probably cut down on the code duplication if you add a csm_type argument to the ClientScripting constructor, especially since UI re-design in Lua could mean a third Lua state/sandbox running on the client.

ScriptApiBase constructor has already a ScriptingType parameter, I think it would become a bit messy to have another one in ClientScripting. But I couldn't tell yet, maybe later in dev.

I'm still wondering if CSM will be kept after SSCSM is implemented.

[red-001]

I don't catch the checksumming thing. Would it be a way to ensure compatible versions between server and client ?

Just load the code locally but check it against checksums embedded in the executable, basically means scripting can't make cheating easier since you still need to recompile the client. No point really trying to verify this server side, a modified client can always lie.

ScriptApiBase constructor has already a ScriptingType parameter, I think it would become a bit messy to have another one in ClientScripting. But I couldn't tell yet, maybe later in dev.

Yeah I'm well aware in-hindsight that enum wasn't the greatest design decision it's only used to skip loading some libs and simplify script loading code. It another enum would be more useful for ClientScripting than the existing one was for ScriptApiBase, would allow switching the location it loads mods from and restrictions with ease and avoiding a lot of code duplication.

I'm still wondering if CSM will be kept after SSCSM is implemented.

I can't comment on that but if UI is moved to Lua two sandboxes might still be needed.

Edit: Is there any usecase for in-memory ModStorage? I think server provided mods should just not have access to ModStorage instead of a largely useless in-memory store.

[sfan5]

As red-001 already said letting the server send builtin won't work. The solution to this should be #6925 instead.

I'll also copy my comment from #10530 (comment) here since it details what needs to be done first:

The promised elaboration:

To make CSM truly useful it needs APIs that do things without waiting for the server, unlike the sorta read-only access it has presently. One example for this would be node placement/dig prediction, see #8057 for more.
And assuming that CPCSM is kept (I personally think it should be), it needs to be denied access to those APIs for obvious reasons.

This is where one design decision still needs to be made and implemented. The options are:

• Keep CPCSM and SSCSM in the same Lua environment, using a solution similar to minetest.request_http_api() (this is almost certainly insecure, don't do this)
• Have one Lua environment for CPCSM and one for SSCSM, this provides strict security boundaries and separation of APIs

(There is a closely related problem of how restrictions such as the the node or itemdef lookup can be made to apply only to CPCSM, to which the latter is a very obvious answer.)

Once that is done, APIs that accommodate the server mod's interests can be added and subsequently tested by server owners and users who are willing to opt into SSCSM in an experimental stage.
Securing builtin should follow soon, but is not strictly necessary to move SSCSM to a testing phase (since it's all opt-in, server owners who wish to test SSCSM can opt in with the knowledge that it (currently) also allows cheats).

[v-rob]

Might just be best to design this with CSM in mind. It may be that CSM will be removed (although it seems (?) that a majority is in favor of keeping it), but it's probably easier to remove it after SSCSM is implemented than to re-add it. Server Sent Script (SSS) sounds like a good name; after all, it's not actually a mod, but is part of one.

[red-001]

It's a good name but not the greatest initialism, maybe SPS (Server Provided Scripts)? Apologies for the bikeshedding.
How would the UI rework factor into this, I feel the design and scope of that should in some way factor into how SSS works.

[rubenwardy]

SSS and SPS are both much better than SSCSM

The actual sending and executing of Lua files in SSS/SPS is one of the easier parts. Ensuring that the sandbox is working correctly (#7041) and other such things are considerably harder. We may need to add encryption support if we want to ensure that the scripts are coming from the server (#10206)

sfan5 had a todo list for this that he shared a few months ago as an image, that may be helpful for discussion here

[red-001]

Re: sandboxing
OS-level sandboxing is obviously the most secure approach, but has the downside of being complex to implement and maintain, not sure if disabling JIT would help actually make the sandbox more secure or not. Afaik there isn't really any good way to prevent resource exhaustion without using OS-level sandboxing, hooks can be used to catch some accidental infinite loops.
Re: Encryption
If implemented well would be a nice feature to have, would this use a PKC akin to how SSL or TLS use it or would it use the password as the shared secret it's built around?

[sfan5]

sfan5 had a todo list for this that he shared a few months ago as an image, that may be helpful for discussion here

Here's it again:

1 and 2 are things I'd consider a good idea (you don't see a browser crash on bad JS do you?).
The issue with 3 is mentioned in my comment above
7 is an implementation detail, could be different too.

[pyrollo]

Afaik there isn't really any good way to prevent resource exhaustion without using OS-level sandboxing, hooks can be used to catch some accidental infinite loops.

IMO resource exhaustion is an acceptable risk, regarding to corruption or spying. It could happen with web browser and in that case, the conclusion would be I wont come back to the server.

[red-001]

A separate thread is a good idea, it would mean that OS-level sandboxing would remain an option, if desired at a later point. Not sure how that would work with the plan to move formspecs to Lua. It does have the downside of not being able to share as much code with the server modding implementation. Also not sure replicating the webbrowser behavior of still trying to run even if provided broken scripts is desirable. Don't think really see the issue with disconnecting if the code crashes and letting whoever supplied it fix the issue.

Links to mention issues/prs for convenience (#8708, #8058, #8057, #6925)

[Ekdohibs]

My opinions about that:

• I think reimplementing a protocol for sending/receiving lua files would lead to code duplication, when we already have the media files for this. However, I think media files probably deserve some automatic cleaning of the cache, to avoid it getting too large (especially with Lua files, and the translations files we have, since these are likely to change quite often)
• About "server crashing client" being an acceptable risk, I'd take it further and say a Lua crash is okay, but a crash inside the rest of the code (for instance, a segfault, or even any assertion failure) should be considered a security risk (there are risks to exploit these crashes and get arbitrary code execution, with no sandbox).

[hecktest]

You can still handle lua errors with pcall, that's not something that must be built into the modding API.

@sfan5
Why must JIT be disabled? That would be a huge loss, we're talking about an order of magnitude in performance.
Is there a concrete reason for it other than a vague bad feeling? What about letting the user whitelist a server for jit if they think there's no risk?

[Ekdohibs]

I created #10598 for the cache cleaning, so the discussion here can stay on SSCSM.

[AFCMS]

@pyrollo Are you still working on SSCSM?

[AFCMS]

* Storage should be volatile (don’t keep anything after disconnection)

I don't agree. Or at least it should be 2 kind of storage, with 1 local storage. It would be useful to store configuration values per server with SSCSM.

[AFCMS]

Clarification:
Minecraft is hard-codded, so per player settings / configuration isn't a problem to store.
Modded Minecraft servers use custom launchers, there is also no problem to store additional settings.

With minetest, there is no launcher, you have one single client and you are able to connect every 5.0 server.

SSCSM will allow modders to add some handy features client side without forcing use CSM / unnecessary network connection.
On the biggest french minecraft PvP faction, players are able to customize position and color / toggle some accessibility features like armor displayed in the HUD, show CPS, pressed keys, etc.
I am recreating the modpack of this server for mcl2, but that would be a pain if server must store these settings, as they are entirely client side.

So I support adding a static client storage, usable by SSCSM. After all, isn't server media already cached on client?

[ExeVirus]

As a starting point, can we merely start with the assumption that this is a separate lua instance from normal CSM's and that it's unlikely much of any of built-in will be exposed to this lua environment at first?

That would simplify a lot as a starting point. JIT vs no JIT is one we should probably not worry about, as those kinds of security issues are on the level of security issues with the client itself or server itself. I.e. We trust our skills in defending against our client bugs, JIT is a similar sort of trust.

Sending, receiving, etc is mostly already done, except concerns about file cache bloat.

For out of memory concerns, we can provide a restricted malloc to the lua environment that fails at say 1.5 GB of net total memory requested, this part is relatively easy.

As for when to run these csm's, they should have an init phase similar to normal mods, and they should at a minimum be able to register a global step function. As for other things we expose, personally I like the idea of just starting with little to nothing exposed, so we can do this in bite sized PR's.

Hard to say what should be next on the list to expose, but we obviously would be able to scrutinize them better individually.

[v-rob]

I still say that the very first step is getting some really basic Lua SSCSM implementation working with nothing exposed to it yet and putting it under a big, fat, "EXPERIMENTAL AND DANGEROUS" setting that is disabled by default. Then, we can fix security issues in successive PRs. Then, APIs can be hammered out, and stuff can be exposed. It should be taken in very small steps at first because we've got to overcome static friction before we can really get anywhere.

[ExeVirus]

How does one find security issues in that case? Do the devs just try to be dastardly and see what happens?

[v-rob]

No; the setting has a warning label on it. Anyone who enables it while the warning is still there is taking the risk of insecurities of their own accord, and it's their fault if anything happens because they took the risk before it was stable. My plan would be to take each potential security issue one at a time before removing the warning instead of trying to do everything at once in one monolithic PR.

Edit: Basically, a roadmap, where each bullet point is one or more PRs, but each bullet point must be done separately, not multiple in one PR.

• Super basic implementation where scripts can be sent but no functions are exposed and security is ignored for now. Under a disabled setting with a warning label.
• Multiple security PRs to fix all potential security issues that we can think of.
• Warning is removed, but setting is still experimental.
• Add SSCSM-specific APIs like mod communication, better than modchannels.
• Expose most CSM API functions to SSCSM
• Formalize the API and remove the setting (or make it enabled by default).

[erlehmann]

Multiple security PRs to fix all potential security issues that we can think of.

When you send a sufficiently powerful input language from the server to the client, no amount of testing can fix all security and performance issues vulnerabilities. Enabling this feature will make it so that clients can be exploited by servers.

[ExeVirus]

They already can be in many ways. This is just another. Ways they can be exploited: 1. Overload with media 2. Send malformed packets (strategically) 3+: Different forms of #2.

…

On Mon, Sep 13, 2021 at 7:04 PM Nils Dagsson Moskopp < ***@***.***> wrote: Multiple security PRs to fix all potential security issues that we can think of. When you send a sufficiently powerful input language from the server to the client, *no* amount of testing can fix all security and performance issues vulnerabilities. Enabling this feature will make it so that clients can be exploited by servers. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10594 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKT7N2VUB5XRR6D4KEGT5CTUBZ7N7ANCNFSM4THN4SXA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Dallas DeBruin ***@***.*** ***@***.***> 740-300-0456

[erlehmann]

@ExeVirus for every input that is context-free, regular or calc-regular, you can (and should) make a validator that can consume the input and determine if the data is valid and should be processed – or if it should not be processed. For a turing complete programming language like Lua computer programs you can not do that since your validator then has a halting problem.

If you do not understand the above summary, you can read the following two LANGSEC papers and come to the conclusion yourself that having powerful scripting languages sent to clients – like web browsers to with JavaScript – is an endless source of security, reliability, and performance bugs, whereas sending and receiving less powerful languages can easily be made secure.

• Security Applications of Formal Language Theory, Len Sassaman, Meredith L. Patterson, Sergey Bratus, Michael E. Locasto, Anna Shubina http:https://langsec.org/papers/langsec-tr.pdf
• The Seven Turrets of Babel: A Taxonomy of LangSec Errors and How to Expunge Them, Falcon Darkstar Momot, Sergey Bratus, Sven M. Hallberg, Meredith L. Patterson http:https://langsec.org/papers/langsec-cwes-secdev2016.pdf

TL;DR: It is a law of nature that a computer program can not distinguish “good” computer programs from “bad” ones, unless the language for the programs is appropriately limited (which Lua is not, until proven otherwise).

[erlehmann]

Yep, fully with you on the argument.

Please don't lead with stuff like that, if the rest of the post is “but actually, not”. I find it irritating.

[ExeVirus]

Well it's the truth, I agree it's a security risk. It's obviously a risk, browsers with JavaScript are a risk. It's a risk I personally will try to have us take, and encourage it. Forked if need be, but that's open source in general. I'm sorry that disagreement in part is infuriating, I can't do much for that specifically. Anyways, you kinda skipped over the ideas for making it buyer-beware safe. Did you have any thoughts about it at all, or just saying "throw it out", and calling it a day?

…

On Tue, Sep 14, 2021, 8:31 AM Nils Dagsson Moskopp ***@***.***> wrote: Yep, fully with you on the argument. Please don't lead with stuff like that, if the rest of the post is “but actually, not”. I find it irritating. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10594 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKT7N2UYSN5XGJUTGUM3CI3UB46CLANCNFSM4THN4SXA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[erlehmann]

Anyways, you kinda skipped over the ideas for making it buyer-beware safe.
Did you have any thoughts about it at all, or just saying "throw it out",
and calling it a day?

Yes. The proposal looks like a lazy non-solution.

It just shifts the blame for breakage from careless programmers to users who can not evalute the risks.

A proper solution is to figure out why CSMs are called for and implement that subset of features in a safe manner.

Any CSM needs to be safe from the start. Once it is complex enough to be unsafe, you can literally never go back – see JavaScript.

[erlehmann]

I agree it's a security risk. It's obviously a risk,
browsers with JavaScript are a risk. It's a risk I personally will try to
have us take, and encourage it.

If the risk is 100% for something to be dangerously insecure, that's not a risk – it's a guarantee.

[erlehmann]

I'm sorry that disagreement in part is infuriating,

You seem to not understand that such an architectural choice for/against CSMs must be an either/or by its very nature.

You are either for designing something limited that can be made safe … or against making a safe system, ever.

Too complex input languages can be “a bit insecure” in the same way that an animal can be “a bit dead”.

[ExeVirus]

Then why do we let users download any mods at all?

Because right now, we let users deal with that exact issue. We even let them provide an insecure environment to mods as they desire.

CSM is just another side of the modding coin. It doesn't have to be SSCSM, it could be simply they download the required CSM, and the server just does a checksum on the csms before letting you join. That brings us to like a huge spectrum of options:

1. No CSMs ever. Everything must be agreed upon by the almighty core devs for client side.
2. CSMs only "experimentally" and servers just have to hope users have them sometimes, same for single player games.
3. CSMs are checksum verified at the very least, so the server can assume they have the expected CSMs
4. CSMs are sent from the server, and the user must self verify before the server sees those checksums and lets you join.
5. CSMs are sent from the server, and minetest has a list of vetted CSM's internally (checksum based), and these are allowed by default (have less restrictions than normal engine PRs), everything else as option 4.
6. CSMs are sent from the server, and the user can just say, sure I trust these csm's based on my trust in the server
7. CSMs are sent from the server, and the user has it preset that they accept all csms.

Somewhere on this spectrum makes sense, because it made sense to allow Server side mods in the first place. Why? Because of the ability to add features, as it is with all games.

We already include lua and have all the problems you are afraid of for server side mods.

We already decided it was worth the risk of security for the benefits of extensibility. This is an engine, there's no reason to restrict game devs to only server side when it can be done in a single player game willy nilly. I.e. I can put all sorts of dangerous input into a "game" mod_pack just as well as I could into a CSM.

Do you trust the modding community in minetest currently? do you play with mods that you haven't fully vetted? Have you vetted every line in the engine or built-in lua mods? (I'm getting there, it takes forever haha, 3 years and counting on that front)

Propose a better solution for extendible client interactions. Ones that don't rely in server lag and delay. That's all we're really trying to do with CSM's at the end of the day. Make the engine more responsive in a flexible manner.

For example, let's say I want to make a bouncy ball phsyics engine so player can be like the Monkey ball game online. That requires rebuilding the client controls, server side physics predictions, and client side physics predictions. Without client side modding, you will have to rely on latency to control yourself. And we've all experienced that delay: it's unplayable. And getting core devs to add such a physics option? maybe. for that one case.

What about other cases? Spaceship movement, vehicular movement, sonic movement, rewiring the controls entirely, cannon physics, wind effects, energy effects, directional gravity, angled viewpoints (i.e. allow roll in the player's view axis), etc.

All those features start to really add up. Great ones can get engine treatment, but small ones won't and cannot. It's just bloat at that point. Small ones would be say the physics of ice skating. Too specific for an engine to support on the C++ side.

There are other examples than just physics or view angles, but I hope you understand that CSM's are a must in some regard. So I ask for a better solution than lua. One that is safe as you describe. I really am all ears, because all the people that recommend "data driven" solutions typically require us baking in all these different data points into the engine and we get major major code bloat to the point of un-maintainability. Better to leave that maintenance to the scripting languages.

As for:

If the risk is 100% for something to be dangerously insecure, that's not a risk – it's a guarantee.

You need someone to take advantage of that risk, and cause harm to a user. Users are not blindly dumb as you describe and you seem to be implying some elitist idea that somehow our core devs are going to be vastly superior. We are better than general public, yep, But we can't design a truly safe client, not in a million years.

Name one game or game engine that connects to the internet that is not a security risk to your computer. The OS already sandboxes us, we can sandbox (and do sandbox) lua further within minetest.

Finally: A server is a pretty weak attack vector for a sufficiently smart hacker. They have to convince users to join. Then they have to find a way to hack their clients via our imperfectly, but still decently, sandboxed environments. Then they can only hack like 100 players max at a time, unless they infect over time, and even that would take years to get to say 1000 people. A phishing scam would be far more effectively detrimental than trying to use CSMs or SSCSMs as an attack vector.

[erlehmann]

Propose a better solution for extendible client interactions. Ones that don't rely in server lag and delay. That's all we're really trying to do with CSM's at the end of the day. Make the engine more responsive in a flexible manner.

Indeed, that is about the only use case I have heard so far for SSCSMs.

Even if it was possible to do this in a secure way, the main human problem I see has two aspects:

1. The cause for almost all of the laggy gameplay experience I had was careless programming, mostly in MineClone2 – and the one that was not could be solved in a very simple way by stuff like adding formspecs for blocks with inventory to node definitions or new node or rendering types.

2. Developers who cannot write code that does not lag the server now loudly scream for the ability to lag the client too. What exactly makes you think that people who can not write good server-side code will suddenly write good client-side code?

@Wuzzy2 has done a lot of work that basically fits the “try to figure out the use case and extend the engine so it works” pattern. What is wrong with it, in your opinion? In my opinion, the main problem is that core devs do not work enough on @Wuzzy2 PRs. 😜

[erlehmann]

We already include lua and have all the problems you are afraid of for server side mods.

I think random users already have the ability to crash servers using a Lua controller item.

How could that be a good justification for giving them also the ability to crash other clients?

[erlehmann]

@ExeVirus btw, do you know about cheatdb? It is like contentdb but for cheat client CSMs: https://cheatdb.elidragon.com/

[v-rob]

Indeed, that is about the only use case I have heard so far for SSCSMs.

That's like saying that the U.S. is the only place that doesn't use the metric system, so people can just ignore them. That's ludicrous; the U.S. is an important country with millions of people. Client-side physics and handling is an extraordinarily large and useful feature that many, many people want. Mobs are not laggy because of "careless programming"; they're laggy because there's no good way to do that feature from the server.

Please, stop acting like features like SSCSM have no useful features and are terrible risks. You are blowing way too many things out of proportion.

[erlehmann]

Please, stop acting like features like SSCSM have no useful features and are terrible risks. You are blowing way too many things out of proportion.

I am not saying that the problems that performance SSCSMs can (alledgedly) solve are not real.

I am saying those problems should not be solved with SSCSMs because there are the wrong tool!

[v-rob]

I am saying those problems should not be solved with SSCSMs because there are the wrong tool!

There is no other tool. There's no other way to do these things. ExeVirus has already said this.

[ExeVirus]

Well, no good tool. Most of this CAN be done in C++, but that would dominate the pipeline and be a headache for the next 10 years or so haha. So a sane solution is CSM. For now, let me try to make a compelling branch that exposes the prediction code to the client, movement buttons, and movement code for csms, and exposes server side prediction and rules so that new physics can be enforced. Ill start with say vehicular physics at first and we can use that as an example for a compelling case. I think SSCSM discussions are a bit premature until we have a compelling reason to enable them as things currently stand.

…

On Tue, Sep 14, 2021, 7:20 PM Vincent Robinson ***@***.***> wrote: I am saying those problems should not be solved with SSCSMs because there are the wrong tool! There is no other tool. There's no other way to do these things. ExeVirus has already said this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10594 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKT7N2WECKVFQZPXMLHPK43UB7KC3ANCNFSM4THN4SXA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[erlehmann]

CSM is just another side of the modding coin. It doesn't have to be SSCSM, it could be simply they download the required CSM, and the server just does a checksum on the csms before letting you join. That brings us to like a huge spectrum of options:

Why should the server have any say about what code I run on my computer? My client could lie! (I mean … it does that already.)

1. No CSMs ever. Everything must be agreed upon by the almighty core devs for client side.
2. CSMs only "experimentally" and servers just have to hope users have them sometimes, same for single player games.

Realistically, Minetest has been at step 2 for quite some time. Users of cheat clients like Dragonfire or Waspsaliva have been writing their own CSMs, taking advantage of the better APIs that cheat clients provide. This provides much more flexibility to a user than sending a CSM from the server and also means that they can improve the behaviour on their own terms or install new versions of CSMs that they exchange which each other.

3. CSMs are checksum verified at the very least, so the server can assume they have the expected CSMs

Clients can lie.

4. CSMs are sent from the server, and the user must self verify before the server sees those checksums and lets you join.

Clients can lie. Alternatively, clients can be exploited easier than now (and it can never be fixed).

There will be no real choice. Servers will probably try to kick users who reject their exploit-ridden payload.

You can see this on websites already. Sites like imgur or Forbes asked users to turn on JavaScript, then served malware.

5. CSMs are sent from the server, and minetest has a list of vetted CSM's internally (checksum based), and these are allowed by default (have less restrictions than normal engine PRs), everything else as option 4.

Clients can lie. Alternatively, clients can be exploited easier than now (and it can never be fixed).

Who would do the vetting? What if there is a vulnerability in a “vetted” CSM? Do you know that Apple actually once had “vetted” a version of git with a security vulnerability? While GNU/Linux users got a more secure version right away, Apple only “vetted” a new git version when they got negative PR for it.

6. CSMs are sent from the server, and the user can just say, sure I trust these csm's based on my trust in the server

Yeah … because the server will totally never be backdoored and tart sending malicious code to everyone.

7. CSMs are sent from the server, and the user has it preset that they accept all csms.

That is the most realistic and by far most scary proposition.

[v-rob]

A normal mod can do just as much as a SSCSM. A normal mod could exploit holes in Minetest and trash your computer in singleplayer. But you use mods, right? Of course you do. Realistically, you could probably infect the same number of people using a bad mod uploaded to ContentDB as you could with a bad SSCSM. Maybe even more. It's common to get a few hundred downloads on ContentDB within less than a week for a mod with a good-looking screenshot.

[erlehmann]

For now, let me try to make a compelling branch that exposes the prediction
code to the client, movement buttons, and movement code for csms, and
exposes server side prediction and rules so that new physics can be
enforced.

That sound interesting. Here is what I think will happen:

1. At one point you will want to encode the movement prediction patterns to ensure that server and client side code behave the same – and also to make it easier to add new movement prediction patterns by just encoding a new prediction pattern.
2. That encoding will most likely be a quite usable intermediate format to send to the client to initialize the client side prediction. I think of JSON, TSV, a Lua table or something similar with a regular or context-free structure and no executable code.
3. If the solution is any good, someone will suggest to consume the same or a similar format in the engine directly and then use C++ code or a previously vetted builtin CSM (not server-sent). This would focus the work on the predictor and make it possible to improve it directly in the engine.

@ExeVirus surely you think it will happen differently, but which step do you think is unrealistic?

[erlehmann]

A normal mod can do just as much as a SSCSM. A normal mod could exploit holes in Minetest and trash your computer in singleplayer. But you use mods, right? Of course you do. Realistically, you could probably infect the same number of people using a bad mod uploaded to ContentDB as you could with a bad SSCSM. Maybe even more. It's common to get a few hundred downloads on ContentDB within less than a week for a mod with a good-looking screenshot.

Well, that is bad already, but requires users to download some mod manually.

If you join a server, that server will hopefully not execute any new Lua code on your machine.

So because the situation is not good now, you want to make it even worse? What kind of ethics is that?

[erlehmann]

Most of this CAN be done in C++, but that would dominate the pipeline and be a headache for the next 10 years or so haha.

Are CSMs basically “I do not trust the core devs to get this right, so I want a backdoor?”.

[v-rob]

Are normal mods basically "I do not trust the core devs to get this right, so I want a backdoor?" No, they're not, and neither are SSCSMs.

I don't want the situation to be more insecure. Stop acting like people are saying that. I want it more useful. Insecurity is a risk for absolutely everything. If you want no insecurities, throw away your computer.

[ExeVirus]

@erlehmann step 2: unlikely to become a format the server and client send to each other. Each physics use case will have different ways to ensure no cheating. In fact, we should allow servers to have even more access to movement code in general to really capture cheaters better. It's just never going to be a data-only solution....

As for other things to clear up:

1. Servers CANNOT trust clients ever. This is the case for web dev, for game dev, for closed source, and for open source. Because all clients can be hacked or send malicious code. Allowing clients to lie is already always an assumption by default. So, for the discussion of which solutions we want: 3-4 are essentially already feasible, but not used yet much by the community. I'm hopeing we can get to 5 or 6. 5 is a mess, I agree.

If you join a server, that server will hopefully not execute any new Lua code on your machine.

Absolutely! Unless users truly don't care about their machine (totally possible) we should have them, by default, from official minetest branches, have a big disclaimer and force them to accept that execution on a per file basis and probably only temporarily for that session. Like, they can inspect the downloaded file before allowing that execution ideally.

3. Servers will be middle-man attacked, or DDOS'd, or or sort of malicious things. Server owners know that. Clients should also be aware of that possibility. Especially anytime they downlaod any mod from the forums haha. There's just so many ways for malicious code to be distributed, this one vector is a weak target.

4. CSM's are for the user's BENEFIT. Technically I could make a server that does monkey ball physics, but no players would play that server or game because it would be a lag fest of frustration. Same for directional gravity, such as planets in space or something. CSM's allow th player to experience those physics or interactions in realtime, and they can choose NOT to allow it. There will always be that option. Especially with an open source client you can change anytime you want.

5. There are other use cases than phsyics. All revolve around movement or input that is dependent on the client. Such as rain droplet particles over the player's head. Those should be done client side. Same for music interactions. If you hit a button and do a smash-bros like move, it would ideally make a sound, and that would preferably happen at the moment you press the button, on the client side. not 80 ms later. Etc.

But yeah I'll work on making a compelling use case. It will absolutely just use a limited lua environment. Likely requiring a user to register functions for callbacks like register_globals do.

[erlehmann]

Same for directional gravity, such as planets in space or something.

I actually tried implementing that some time back. I think it should be in the engine.

[anon55555]

While no program can determine in advance whether any given program will do something invalid, it's possible for an interpreter to stop one if it tries to do something invalid.

For example, if an SSCSM interpreter was formally proven in a computer-verifiable manner to be a pure function using bounded memory of what goes over the network which returns network packets I think the only possible problem would be execution time, either it leaking information (e.g. though microarchitectural side-channels such as Spectre) or being too long.

[Splizard]

What if when you join a server, there is a list of ContentDB-hosted recommended client side mods that you can optionally choose to download before joining the server.
This way, the server doesn't send anything and we can leverage the trust and moderation of ContentDB to ensure that the client side mods are safe.

[Desour]

I'd like to propose, that there's not a simple client-side on/off setting for SSCSM, but an enum describing the "worst" case where SSCSM is still on: off, singleplayer, loopback, lan, worldwide
I.e. if you set it to lan, SSCSM is enabled in singleplayer and on servers where the ip is a loopback or local address, otherwise it is disabled (that is, on public servers).

That way it's easier to start developing without having to worry too much about security at first.
Here are some steps that the development could be divided in:

1. Implement file sending and storing.
2. Load mods with a very minimal environment (i.e. not even all lua std lib; doesn't need to be secure though), and only allow SSCSM in singleplayer and loopback.
3. Add the lua std lib.
   Fill with features.
   Make sure, the API is secure.
   Do some hardening if possible.
   (All of this can be done in parallel.)
4. Allow worldwide SSCSM.
5. Continue with more features.

In the worst case we will never come to step 4, because we don't trust in the security.
But even in this case we have a better API for singleplayer games, and we can use this API and client-provided SSCSM builtin (with a digest checked in C++, of course) (this builtin can always be enabled, even on worldwide servers) to implement server API features more easily in lua.

[rubenwardy]

Not been any discussion here for a while, closing as duplicate of #5393