erlehmann's wishlist & todos

[erlehmann]

wishlist (policy changes or things that I think are too complicated for me):

• better handling of API changes (ideally backwards compatible, require proper upgrade plan if not)
• do not send network messages when entity properties are set to current value (warn in debug builds)
• deprecate [png texture modifier before it gets widespread use (it is not human readable & very wasteful)
• nodes with an associated formspec (so I do not have to use node meta and LBMs to change the formspec)
• make minetest CI use asan, msan, ubsan for unit tests (but do not block merges if no new bugs are introduced)
• remove ability to commit directly to master branch for anyone
• apply coredev approval rules for irrlichtmt changes too
• make irrlichtmt a git submodule to ease bisects
• CSM GUI (to activate and deactivate CSMs)
• SVG support for textures (at least game icons)

todo (stuff I intend to do … eventually):

• fuzz irrlichtmt using afl-fuzz
• figure out how to fuzz minetest networking code
• create version of Minetest 5.4.1 with all non-functional upgrades
• add CSM APIs from dragonfire and waspsalive that can not be used to cheat
• overhaul minetest build system to make it faster and able to correctly build incrementally
• remove BMP from irrlichtmt (replace with TGA, which is both simpler and more powerful)
• fix botched handling of A1R5G5B5 and 16 bit grayscale+alpha texture formats in irrlichtmt
• figure out how to become coredev so I can review wuzzy PRs and have it mean something
• log entry deduplication for spam (i.e. if the same log message occurs several times in a row)
• add texture modifiers [pbm [pgm [pnm for small human-readable textures (limited to 16×16 pixel payload)
• add test nodes to devtest for JPEG, PNG, TGA, Ogg Vorbis (to test/demonstrate all media format options)
• create a cleaned-up history for irrlichtmt where the monster commit hecktest made is split so tooling does not crash
• figure out how irrlichtmt commit 7d1dc8b2d54ada305e4e2caa38debf35a171c52d affects performance on windows, context: https://github.com/minetest/irrlicht/issues/94

[Blockhead]

wishlist (policy changes or things that I think are too complicated for me):

-snip-

You probably want to remove the references to cheat clients from your post because they're a violation of the forum rules to even mention their names.

[Linuxdirk]

remove ability to commit directly to master branch for anyone

This won’t happen because the devs do not use branches in the Minetest repositories.

CSM GUI (to activate and deactivate CSMs)

According to some older discussions enabling CSM functionality was a mistake but can’t be reverted because people started using it. CSMs are a byproduct of the work on SSCSM and were never intended to be used on their own. If this still stands then it’s unlikely that anything regarding CSM will change until someone starts actively working on SSCSM.

And SSCSMs should be 100% configurable by the client. Each SSCSM should send a descriptive string on what it’s for and should reqwuest permissions for doing that. The string and permissions should be shown to the player and need to be actively whitelisted before being able to play on a the server that sends them.

[v-rob]

Not the hijack this thread about (SS)CSM, but I think I'm starting to learn towards the opinion that SSCSM really isn't feasible (both in manpower and security), and that CSMs are mostly worthless and are difficult to add functionality to that don't allow cheating, so I'm starting to be of the opinion that SSCSM should be scrapped and CSMs removed (they aren't officially supported after all, and likely never will be), and focus on methods to solve things from the server.

To tweak one of erlehmann's favourite examples: Web browsers don't need to embed JavaScript on the client side for animation. SVG animation can do a lot without being Turing-complete. Obviously, it can't do everything, but applying that sort of principle to, say, entity movement could get us far without touching SSCSM. For instance, precalculate the path of your entity over the next few server steps and send that to the client: the client then moves the entity along that path until it gets a new path from the server. Like move_to with multiple positions and time for each movement. Things of that nature might be of more benefit to us as they are things we can actually do now.

On the other hand, most of the stuff in here is generally stuff I don't have a very strong opinion on one way or the other or somewhat disapprove of, but I think I've made my opinion clear in other places, so no sense in going into it again here.

[Linuxdirk]

I think I'm starting to learn towards the opinion that SSCSM really isn't feasible (both in manpower and security), and that CSMs are mostly worthless and are difficult to add functionality to that don't allow cheating, so I'm starting to be of the opinion that SSCSM should be scrapped and CSMs removed (they aren't officially supported after all, and likely never will be), and focus on methods to solve things from the server.

Quoted for emphasis.

[sorcerykid]

I still am failing to understand how SSCSM is inherently insecure, if it doesn't have the ability to do anything outside of a strictly controlled sandbox. There are so many things that can be accomplished more efficiently when handled client-side, particularly when it comes to sound-effects, animations, etc.

[rubenwardy]

if it doesn't have the ability to do anything outside of a strictly controlled sandbox

This is ultimately the problem.

It's very hard to design a completely effective sandbox. Perfectly safe looking functions may lead to vulnerabilities, due to side channel attacks like Spectre or due to bugs with memory. Web browsers have huge teams, and people dedicated to information security, yet they still mess it up. What hope do we have?

[jwmhjwmh]

You could put the server-sent code in a separate process without shared memory. That way you could use OS-level sandboxing, which must be pretty well-tested.

Edit: The code could still potentially cause problems through the exposed API, of course.

[sorcerykid]

It's very hard to design a completely effective sandbox. Perfectly safe looking functions may lead to vulnerabilities, due to side channel attacks like Spectre or due to bugs with memory. Web browsers have huge teams, and people dedicated to information security, yet they still mess it up. What hope do we have?

But couldn't that be said of server-side mods too?

I mean we already have the ability to do a lot of things to manipulate the client, just indirectly from the server. Consider: I could teleport the player out of bounds of the map. Now you might say, the server has sanity checks for such conditions, before ever sending such a packet to the client. But it's just a matter of me recompiling my server to remove that bounds check in hopes that it might overflow some variable in the client that could lead to a heap overflow.

The client-server system that Minetest has in place right now already poses significant security risks since there's no guarantee that servers (and by extension server-side mods) are always going to abide by the "rules". So many things have to function exactly as expected for multiplayer games to work correctly, and it's nearly impossible with a project the complexity of Minetest to anticipate every possible condition that could arise. I have no doubt there's already security holes in the client-server protocol that haven't been exploited yet only because nobody's invested the time or effort to do so. Just some food for thought :)

[erlehmann]

You probably want to remove the references to cheat clients from your post because they're a violation of the forum rules to even mention their names.

I am not trying to sneakily lead people to cheat clients. Any one who wants a cheat client can use a search engine.
I merely think that alternate clients have non-cheat capabilities that could be included in the base game.

For example, cora has modified waspsaliva to log all coordinates of received particle spawners.
She then used that new capability to verify that a coordinate exploit was properly patched.

If Minetest had logged such things, maybe the exploit would not have happened!

Edit: A coordinate exploit is when some bug in a game allows players to figure out where other players are.
I read that on old Clamity, the player ”dankmemer” used such a thing to find player bases and destroy them.

[erlehmann]

remove ability to commit directly to master branch for anyone

This won’t happen because the devs do not use branches in the Minetest repositories.

The core devs definitely use branches for PRs.
But at times ppl commit things directly to master IIRC.

I think that is a bad practice, especially in the case of irrlichtmt.
Now you can say some changes are not dangerous, but I doubt it.

CSM GUI (to activate and deactivate CSMs)

According to some older discussions enabling CSM functionality was a mistake but can’t be reverted because people started using it. CSMs are a byproduct of the work on SSCSM and were never intended to be used on their own. If this still stands then it’s unlikely that anything regarding CSM will change until someone starts actively working on SSCSM.

And SSCSMs should be 100% configurable by the client. Each SSCSM should send a descriptive string on what it’s for and should reqwuest permissions for doing that. The string and permissions should be shown to the player and need to be actively whitelisted before being able to play on a the server that sends them.

I do not believe that servers should be able to require specific CSMs.
I have so far seen no CSMs that were really necessary for gameplay.

I see CSMs more like browser extensions, and less like JS on web pages.
Everything must be possible without using them, but they can be an option.

The only server I would maybe somewhat trust regarding CSMs is ContentDB.

[Blockhead]

I am not trying to sneakily lead people to cheat clients. Any one who wants a cheat client can use a search engine.
I merely think that alternate clients have non-cheat capabilities that could be included in the base game.

Don't worry, I agree with you that alternate clients are actually valuable to Minetest as a whole, but I just wanted to err on the side of caution when it comes to the interpretation of forum rules. The first client you name is particularly famous as a cheat client, so someone following a strict interpretation of the rules could possibly rule you to be in violation. But if nobody in forum administration takes issue with it, it must be ok right? Until maybe it isn't one day?

[v-rob]

I mean we already have the ability to do a lot of things to manipulate the client, just indirectly from the server. Consider: I could teleport the player out of bounds of the map. Now you might say, the server has sanity checks for such conditions, before ever sending such a packet to the client. But it's just a matter of me recompiling my server to remove that bounds check in hopes that it might overflow some variable in the client that could lead to a heap overflow.

This is a valid point. Anyone who is dedicated to finding an exploit will find one in any piece of software, and a networked open source one like ours with a small team of maintainers definitely stands no chance. By the same token, one could argue that that's no reason to add fuel to the fire with SSCSM, which would probably make it easier than ever for the average coder to find exploits of some form or another.

However, I think that the biggest argument against SSCSM is that we really wouldn't be able to handle it--no one has ever gotten even close to implementing it, and it would be twice the modding API to maintain. So, security is kind of a moot discussion if no one will even implement the dang thing in the first place. Don't get me wrong: I'd love a SSCSM API if it were really feasible, but I don't think it is, so I don't want to waste any time daydreaming, especially not by wasting time on the CSM API.

Somewhat more on topic:

I see CSMs more like browser extensions, and less like JS on web pages.
Everything must be possible without using them, but they can be an option.

The difference between browser extensions and Minetest CSMs is that one is used to enhance web browsing, and the other is used to enhance a game engine client. Enhancing a game engine client usually implies getting an unfair advantage over other people, i.e. cheating.

What are concrete examples of CSM APIs that would be genuinely be useful and could NOT be used for cheating? Any API that allows cheating is entirely out of the question. Many of the examples you gave me on IRC could be useful, such as the fighting fires, removing falling water, getting rid of people who hang around spawn and kill new players, etc., but any API that would allow those things 100% could and would be used for cheating. That doesn't seem to leave much besides colored chat and whatnot.

[sorcerykid]

But here's the thing, SSCSM doesn't need to be an overly complicated API. Personally, I would like to see the initial phase of SSCSM implemented exclusively for formspecs and the HUD (although hopefully the HUD would eventually be handled using a similar, if not the same, API as formspecs).

In this way, SSCSM would be so limited in its feature-set, that it's hard to believe there would be any additional vulnerabilities by allowing direct client-side control of the GUI, since whatever the client-side mod is able to do with formspecs and the HUD should be identical to whatever the server-side mod can do, albeit more efficiently of course.

[MisterE]

my big hope for SSCSM is physics. I really want to be able to change the player physics, and have the client able to predict the physics. That *could* be implemented as an engine feature, however, though it would be best as a CSM.

[erlehmann]

What are concrete examples of CSM APIs that would be genuinely be useful and could NOT be used for cheating? Any API that allows cheating is entirely out of the question. Many of the examples you gave me on IRC could be useful, such as the fighting fires, removing falling water, getting rid of people who hang around spawn and kill new players, etc., but any API that would allow those things 100% could and would be used for cheating. That doesn't seem to leave much besides colored chat and whatnot.

For you to accept my answers you would have to agree on what is considered cheating in a game.

I have a very basic definiton of that: A game action is cheating if it takes a player out of the gameplay.
To illustrate, I will give five examples that automate game actions – but only two may be cheating:

Autoforward – Having to actually hold down the forward key for many minutes is uncomfortable.
Autoforward functionality is indeed in Minetest. However, it does not play the game all by itself.
A player autoforwarding can still be attacked by monsters, walk into lava, or fall into a ravine.

Autofly – This is a quite simple CSM that allows users to fly towards previously set waypoints.
It only automates the basic trigonometry that players usually have to do to figure out the way.
Basically, the player is aligned with the vector to some location and then autoforwards there.
Autofly is not included in Minetest – but if you can fly, pointing in a direction is not cheating.

Autokill – This is a CSM that punches entities or players in range – thus it fights automatically
Players could configure it to punch only specific mobs or only enemy players. Still, it is cheating!

Friend/Enemy list – color player names according to your own rules. Good privacy. No cheat.

Kamikaze – This CSM is an autokill bot that aims towards nearest hostile withers or explosives.
It then punches the target, and often perishes, just to respawn and do the thing again and again.
The Kamikaze CSM has been used to clean up hostile mobs and explosive crystals at spawn.
Doing this is very inefficient and only serves to avoid grindy tasks – but I consider it cheating.

[erlehmann]

Sometimes the question comes up if something is cheating or an accessibility feature. Consider:

Increasing brightness/contrast by a bit – I can see low contrasts worse than other players.
This means that normal-eyesight players have an unfair advantage, unless I use a modified client.

Fullbright / Bright Night – These CSMs enable players to avoid acquiring and placing torches.
Additionally, they make it possible to avoid enemies in the dark, where they should not be visible.
This is cheating, because it takes a fundamental gameplay aspect (lighting) out of the gameplay.

[erlehmann]

CSM APIs that would be genuinely be useful and could NOT be used for cheating

APIs that pass information to external programs

For example, the mumble CSM just forwards players relative directions to mumble, so you they get 3D sound.
My friend is creating a rumble CSM; I plan to use that to connect Minetest to Intiface, so hardware can go brrr.

Currently, it seems to me as if CSMs always need some program that reads the log output, which is not good.
If Minetest would allow CSMs to talk with web servers explicitly listed in the configuration, that would be great!

[erlehmann]

my big hope for SSCSM is physics. I really want to be able to change the player physics, and have the client able to predict the physics. That *could* be implemented as an engine feature, however, though it would be best as a CSM.

People keep bringing that up – but I have never seen any examples. Do you have an implementation or proposal?

[v-rob]

Autoforward/fly essentially recommends an API of programmatic access to player controls. This doesn't sound too bad in and of itself, but consider: programmatic access to the keyboard would also allow auto-digging, auto-building, and the like, which could be cheating depending on the game. Additionally, an autoforward that avoids ravines, lava, and whatever, requires knowledge of the nodes in the world. This is problematic because people could use that API to find all the good ores in the world and dig them up, perhaps automatically, which is cheating without a doubt.

So, you see the difficulty: we have these legitimate use-cases for CSM, but the problem is that the same APIs that can be used for cheating. I find it difficult to come up with APIs that are both useful but can't be used for cheating. Like I said, "colored chat and whatnot" are some of the only things that CSM can support without also supporting cheating.

As for increasing brightness/contrast, that's a prime feature for a setting. It would actually be easier to program a setting for it without exposing it to CSM than to make a CSM API for it, and a setting would also be easier for the average user to use.

As for CSMs talking to other programs: I think CSMs don't allow os.execute or io.popen for security reasons, and hence CSM APIs to talk to external programs would also fall under that umbrella. Not entirely sure about that, however.

my big hope for SSCSM is physics. I really want to be able to change the player physics, and have the client able to predict the physics. That *could* be implemented as an engine feature, however, though it would be best as a CSM.

People keep bringing that up – but I have never seen any examples. Do you have an implementation or proposal?

I don't know if an API proposal has ever been made, but the need is certainly easy to see. Try using Advtrains without increasing your server step from the default: the trains are really jerky and move about oddly. Increasing the server step increases network traffic, however, bogging the server down and making it unplayable for people with bad internet connections. A SSCSM API, even if it was exactly the same as the API for SSM entities, would allow people to control physics client-side, so in Advtrain's case, there would be no jerkiness, but very smooth. I, for one, would love smooth trains.

Advtrains is only one example. There's lots of mods that suffer from slow entity handling. It's even worse if you want to do anything with player physics.

[sorcerykid]

This same problem occurs with the very simple Boost Cart. It doesn't really take much at all to notice the lack of synchronization when dealing with moving entities.

[erlehmann]

Autoforward/fly essentially recommends an API of programmatic access to player controls. This doesn't sound too bad in and of itself, but consider: programmatic access to the keyboard would also allow auto-digging, auto-building, and the like, which could be cheating depending on the game.

I wish for programmatic access to player controls so I can test my mod code better.
So I think this should be a feature that should exist for local debug builds at least.

It would only be cheating if it is indeed possible to remove the player from a decision loop.
Parkour can definitely not be cheated if you can only ever do “autoforward in this direction”.

Cora has a mod that uses the node in hand and places it on all similar nodes in reach.
This is very useful for building castles or towers – you still need to have the materials.

Additionally, an autoforward that avoids ravines, lava, and whatever, requires knowledge of the nodes in the world. This is problematic because people could use that API to find all the good ores in the world and dig them up, perhaps automatically, which is cheating without a doubt.

I do *not* want an autoforward that avoids danger. This removes the player from the decision loop.

And it could be quite easy to avoid though! You could make a variable or scope acquire a “taint” flag when it gets information from the game world and disable any movement for as long as that information is in used or in scope.

So, you see the difficulty: we have these legitimate use-cases for CSM, but the problem is that the same APIs that can be used for cheating. I find it difficult to come up with APIs that are both useful but can't be used for cheating. Like I said, "colored chat and whatnot" are some of the only things that CSM can support without also supporting cheating.

Automated playtesting is one thing. If you only allow these things for local play in debug builds, there is little danger.

As for increasing brightness/contrast, that's a prime feature for a setting. It would actually be easier to program a setting for it without exposing it to CSM than to make a CSM API for it, and a setting would also be easier for the average user to use.

I must admit I just redefined the default light level for nodes to 1, so I could see them.

As for CSMs talking to other programs: I think CSMs don't allow os.execute or io.popen for security reasons, and hence CSM APIs to talk to external programs would also fall under that umbrella. Not entirely sure about that, however.

Well right now the CSM needs to write to debug log and then another program reads that log.

my big hope for SSCSM is physics. I really want to be able to change the player physics, and have the client able to predict the physics. That *could* be implemented as an engine feature, however, though it would be best as a CSM.

People keep bringing that up – but I have never seen any examples. Do you have an implementation or proposal?

I don't know if an API proposal has ever been made, but the need is certainly easy to see. Try using Advtrains without increasing your server step from the default: the trains are really jerky and move about oddly. Increasing the server step increases network traffic, however, bogging the server down and making it unplayable for people with bad internet connections. A SSCSM API, even if it was exactly the same as the API for SSM entities, would allow people to control physics client-side, so in Advtrain's case, there would be no jerkiness, but very smooth. I, for one, would love smooth trains.

Advtrains is only one example. There's lots of mods that suffer from slow entity handling. It's even worse if you want to do anything with player physics.

For movement prediction, I would take an inspiration from the SVG path syntax:
Basically, you need to specify a (possibly interrupted) movement in 3D space.

What if an entity at 0,0,0 had an attribute movement_path with the following value?

Code: Select all

0.5 M 3,0,0 ; 1 L 0,0,0 ; 5 C 0,0,1 0,0,-1 0,0,2

Where each letter is a duration for a movement followed by a movement type and absolute coordinates.

“M” is move to (instant teleportation).
“L” is move along a line.
“C” is a cubic bezier function.

(Like SVG, small letters would indicate relative coordinates.)
This could cause a prediction on the client like the following:

1. The object goes instantly to 3,0,0 after 0.5 seconds.
2. The object moves to 0,0,0 and that takes 1 seconds.
3. The object moves to 0,0,2 and that takes 5 seconds. It moves along a cubic bezier function with control points 0,0,1 and 0,0,-1.

Surely hashing out a really useful path syntax with object rotation and proper timing would be a bit more work, but it seems like actually allowing the engine to predict this based upon an object property would not be that difficult.

Just having the line syntax would probably help to make a lot of stuff less jerky.

[v-rob]

I wish for programmatic access to player controls so I can test my mod code better.
So I think this should be a feature that should exist for local debug builds at least.

That makes CSM a pretty hefty feature for development. However, I can see more of where you're coming from then.

I do *not* want an autoforward that avoids danger. This removes the player from the decision loop.

And it could be quite easy to avoid though! You could make a variable or scope acquire a “taint” flag when it gets information from the game world and disable any movement for as long as that information is in used or in scope.

Oh, I misunderstood then. Although, the more CSM APIs we'd add, the more of these edge cases and "taint" flags would start popping up and making things a complicated mess.

For movement prediction, I would take an inspiration from the SVG path syntax:
Basically, you need to specify a (possibly interrupted) movement in 3D space.

<snip>

Actually, I proposed this sort of thing above, and would support an implementation:

For instance, precalculate the path of your entity over the next few server steps and send that to the client: the client then moves the entity along that path until it gets a new path from the server. Like move_to with multiple positions and time for each movement.

However, SSCSM would still be the superior solution for interactive entity stuff (say, a mobs mod where monsters do more than just run at you randomly, but showing some "intelligence" and making interactive movements on the spot, which static paths can't achieve). A path API also doesn't help when extending player motion (while running, the player presses the jump key next to a wall, he does an extra high jump; "wall climbing")

[Linuxdirk]

However, SSCSM would still be the superior solution for interactive entity stuff

Everyone always speaks about entity movement prediction and better physics when it comes to SSCSM but neither should be SSCSM but a built-in part of the client.

[v-rob]

Everyone always speaks about entity movement prediction and better physics when it comes to SSCSM but neither should be SSCSM but a built-in part of the client.

I'm not arguing, but more genuinely curious: how could one implement special player physics like wall climbing with only general engine APIs and no client side scripting?