openSUSE has issued an advisory today (January 3):
The issue is fixed upstream in 5.6.0:
Fixed upstream in 5.6.0
Thanks for the report. I'll push the latest feature release as it's needed for current servers compatibility.
Updated minetest package provides version 5.6, fixes security vulnerability
This update provides minetest 5.6.1, the latest stable release of the open
source voxel game. This updates provides a number of feature and bug fix
changes compared to the previous version 5.4.0 provided in Mageia 8. See the
linked release notes and changelogs for details.
The update also improves compatibility with hosted game servers, which
typically run and expect the latest stable release.
The update also fixes a security vulnerability affecting single player with
malicious mods (GHSA-663q-pcjw-27cc):
In single player, a mod could set a global setting that controls the Lua
script loaded to display the main menu. The script would be loaded as soon as
the game session is exited.
The Lua environment the menu runs in was not sandboxed and could directly
interfere with the user's system.
SRPM in core/updates_testing:
RPM in core/updates_testing:
Fixed upstream in 5.6.0 =>
The last time I tested minetest, I installed the old version first, then updated over it. This time I decided to try a straight install, rather than an update.
Downloaded the candidate with qarepo, then used MCC to install it and its dependencies in a VirtualBox MGA8-64 Plasma guest. But when I went to run it, the gui only partially loaded, with parts of it flashing on and off.
Before running here with that, I did the same type of install on real hardware, AMD Phenom II X4, AMD HD 8490 graphics, also a Plasma system. No installation issues there, either. This time, the game gui came up as it should, and was stable. I created a world, attempted to play the game, but managed to dig myself into a hole where I couldn't go anywhere. But the game played as it should.
On a hunch, I went back to the virtual machine, this time disabling 3D acceleration before running the guest. This time, the game came up fine, and ran as it should. I created yet another world, downloaded a tutorial game from within the game, played around a bit. Everything worked.
So, the problem was that my VirtualBox guest settings were wrong. I don't think that's enough to hold it back, so I'm giving it a 64-bit OK.
Foolishness, my real 32-bit hardware, was right here handy, so I thought I'd give it a try. It has a 32-bit P4, 2GB of RAM, AMD RV200 graphics, and is running an Xfce system. Task-gnome-minimal has also been installed, but so far not used.
There were no installation issues. When I ran the game, the gui's text was... off, but readable. I was again able to create a world, but when I went to play the game, several error messages appeared superimposed over the screen. They spoke of fatal errors due to a "texture not owned by this driver" and other messages indicating that my video hardware isn't up to the task of running this game. And when I went to play it anyway, the controls were sluggish to the point of making it unplayable.
I cannot in good conscience give this a 32-bit OK, but I don't think the problems I'm seeing are new regressions, either. I think they are the result of inadequate video hardware, and have been around for quite a while. This is not the first game to show this kind of thing, so if there are no objections, I will validate this in a day or two, based on the 64-bit performance.
I revisited the 32-bit version, this time in a 32-bit Plasma install on real 64-bit hardware. (AMD Phenom II X4, 8GB RAM, AMD HD 8490 graphics, using the 32-bit server kernel)
This time everything worked as I believe it should. I created another world, played the game without knowing what the eventual goal is supposed to be, chopped down a tree, destroyed a bush, dug a hole and jumped back out of it, walked into a stone wall(seemingly without hurting myself).
The GPU in Foolishness is only capable of OpenGL 1.6, while the one in this system is capable of MUCH higher. I believe that is what made most of the difference.
So, because it seems to need a certain level of 32-bit hardware to be playable, I'm going to send this on with just a 64-bit OK. If this were years ago, when there was more real 32-bit hardware in actual use, I might have held it back.
Validating. Advisory in Comment 1.
An update for this issue has been pushed to the Mageia Updates repository.