Time |
Nick |
Message |
00:10 |
|
kilbith_ joined #minetest-dev |
00:19 |
v-rob |
#11980 - just to make sure |
00:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/11980 -- Bump formspec version by v-rob |
00:20 |
kilbith_ |
thanks buddy |
00:41 |
|
AliasAlreadyTake joined #minetest-dev |
00:49 |
|
Toothless joined #minetest-dev |
01:26 |
|
troller joined #minetest-dev |
01:31 |
|
troller joined #minetest-dev |
02:01 |
|
v-rob joined #minetest-dev |
03:29 |
|
queria joined #minetest-dev |
03:33 |
|
queria joined #minetest-dev |
03:34 |
|
tekakutli joined #minetest-dev |
04:05 |
|
Toothless joined #minetest-dev |
04:08 |
|
v-rob joined #minetest-dev |
04:14 |
|
Toothless joined #minetest-dev |
04:21 |
|
Baytuch joined #minetest-dev |
04:31 |
Baytuch |
Good morning |
05:00 |
|
MTDiscord joined #minetest-dev |
05:41 |
|
dzho joined #minetest-dev |
05:49 |
|
cheapie joined #minetest-dev |
06:06 |
|
jordan4ibanez joined #minetest-dev |
07:08 |
sfan5 |
v-rob: dunno if the takeaway is to bump formspec version *every* release, but I bet this release has had new features (right?) so a bump is justified anyway |
07:09 |
v-rob |
That's what I didn't remember, whether we were bumping every release or not. The issue didn't really say as far as I could see. |
07:09 |
v-rob |
I know we are for protocol at least |
07:09 |
sfan5 |
yeah |
07:09 |
v-rob |
I actually don't think we have any new elements this release, but lemme check |
07:13 |
v-rob |
NVM, we added padding[] |
07:13 |
v-rob |
So bump then |
07:14 |
v-rob |
I'd better document that in lua_api.txt under the new version 5 |
07:17 |
v-rob |
Neat, formspec versions are currently synced with minor release number. Version 4 was for 5.4, version 5 will be for 5.5 |
07:19 |
v-rob |
PR updated |
07:21 |
|
dzho joined #minetest-dev |
08:52 |
|
dzho joined #minetest-dev |
09:44 |
|
nemo42 joined #minetest-dev |
09:45 |
|
calcul0n_ joined #minetest-dev |
09:45 |
|
Fixer joined #minetest-dev |
10:07 |
|
erlehmann joined #minetest-dev |
11:51 |
|
YuGiOhJCJ joined #minetest-dev |
13:15 |
|
troller joined #minetest-dev |
14:52 |
|
kilbith joined #minetest-dev |
15:04 |
|
nemo42 joined #minetest-dev |
15:06 |
|
kilbith_ joined #minetest-dev |
15:39 |
|
kilbith_ joined #minetest-dev |
15:50 |
|
v-rob joined #minetest-dev |
15:56 |
|
kilbith__ joined #minetest-dev |
16:14 |
kilbith |
one should backport this PR into upstream as MoNTE48 is telling his developers not to do this: https://github.com/MultiCraft/MultiCraft2/pull/25 |
16:16 |
|
appguru joined #minetest-dev |
16:28 |
|
kilbith_ joined #minetest-dev |
16:33 |
|
kilbith__ joined #minetest-dev |
16:36 |
|
Toothless11 joined #minetest-dev |
16:39 |
|
kilbith_ joined #minetest-dev |
17:33 |
|
behalebabo_ joined #minetest-dev |
17:49 |
|
erlehmann joined #minetest-dev |
17:51 |
sfan5 |
asking again: does anyone agree that #11922 can be in 5.5 despite being a feature? |
17:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/11922 -- Allow resetting celestial vault elements by leaving its arguments empty by Zughy |
17:55 |
erlehmann |
sfan5 to be useful, it would at least need #11930 too |
17:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/11930 -- set_sun/set_moon: setting textures to something and then to their default name again creates dummy broken images |
17:56 |
sfan5 |
from what zughy said that looked like an edge case not likely to happen |
17:58 |
sfan5 |
anyway the defaults are clearly wrong, there is no such sun.png texture |
18:01 |
erlehmann |
by the way i looked into the stuff i uncovered using the TGA test nodes. it seems the grayscale tga pictures get a yellow tint indeed because irrlicht assumes at this point anything 16 bit is A1R5G5B5 and thus having a grayscale image with an alpha channel *somewhat* works. but obviously not correctly at all |
18:04 |
erlehmann |
somewhat unrelated, A1R5G5B5 images have no functioning alpha channel right now, because they get converted to 24bpp RGB colors internally and not 32bpp RGBA colors |
18:05 |
erlehmann |
and also there might be endianness bugs in getPixel() ? i have to verify that some time later |
18:08 |
erlehmann |
does anyone here have access to a big endian machine? |
18:34 |
|
HuguesRoss joined #minetest-dev |
18:40 |
|
HuguesRoss joined #minetest-dev |
18:41 |
|
HuguesRoss joined #minetest-dev |
19:27 |
|
v-rob joined #minetest-dev |
19:40 |
|
troller joined #minetest-dev |
20:04 |
|
troller joined #minetest-dev |
20:05 |
|
behalebabo_ joined #minetest-dev |
20:19 |
|
book` joined #minetest-dev |
20:26 |
erlehmann |
once i can execute lua code in a minetest server (mod) context, what would be the best way to get outside of it? |
20:26 |
erlehmann |
like to escape the sandbox, so to say |
20:26 |
erlehmann |
(i am thinking about this from the perspective of an minetest client attacker, not a mod author) |
20:27 |
MTDiscord |
<Warr1024> Do you mean like in a "having help on the outside" sense, like to connect to some external helper thing? |
20:27 |
rubenwardy |
if there are any trusted_mods, then you can try to see if it leaks the environment |
20:28 |
MTDiscord |
<Warr1024> Personally I have built a few things using LuaSockets to allow the mod to listen on a unix-domain socket in the worldpath, and then I can connect external helpers that way. Haven't found a portable way to do it with mod security enabled though. |
20:28 |
MTDiscord |
<exe_virus> Erlehmann: mostly because it packages a lot of stuff we don't care about like test scripts, readmes, and yet another jsonhpp. Ideally we wouldn't require all that bloat. Plus the format is not truly dead, so we may want to support our own extensions someday far in the future. |
20:28 |
MTDiscord |
<Warr1024> A lot of people have given me "well duh, that's easy, you just X" solutions that work in about 80% of cases. |
20:29 |
erlehmann |
exe_virus sorry, context? |
20:29 |
MTDiscord |
<exe_virus> Yesterday, the tinygltf thing |
20:30 |
MTDiscord |
<Jonathon> if i recall correctly you can escape the sandbox be serializing code and then exicuting it |
20:30 |
erlehmann |
ah |
20:30 |
MTDiscord |
<exe_virus> The serialization thing has been closed |
20:30 |
erlehmann |
Jonathon, yeah that works for normal lua, but does it works for a minetest mod? |
20:30 |
erlehmann |
uh when was it closed? |
20:30 |
MTDiscord |
<exe_virus> While back, I'd have to git blame |
20:30 |
MTDiscord |
<exe_virus> Probably 2020 |
20:30 |
rubenwardy |
the question is about a server mod context |
20:30 |
rubenwardy |
not about a mod's sandbox |
20:31 |
rubenwardy |
so deserialize won't make a difference |
20:31 |
erlehmann |
exe_virus oh do you mean the client-sent server mods thing in 5.3 that was removed from 5.4? |
20:31 |
erlehmann |
or something else |
20:31 |
MTDiscord |
<exe_virus> Gotcha, thanks ruben |
20:31 |
rubenwardy |
erlehmann: if you passed deserialize into a sandbox like mesecons luacontroller, they could use it to escape to the mod environment |
20:31 |
MTDiscord |
<exe_virus> File system hacks is how I would do it |
20:32 |
MTDiscord |
<exe_virus> Like: before the world generates, make a map.sqlite that is designed to break out of the context due to a bug in SQLite or similar |
20:33 |
erlehmann |
rubenwardy, i see. now … they can only hang the server, right? |
20:34 |
erlehmann |
by creating a lot of strings |
20:34 |
rubenwardy |
with that, you can do anything you can do in a mod environment. Change passwords, ban users, access chat, etc |
20:34 |
rubenwardy |
oh right, *now* |
20:34 |
erlehmann |
yeah, i know that it was insecure before |
20:34 |
rubenwardy |
yeah, now it should be fine - just might freeze the server |
20:35 |
erlehmann |
i remember that your-land.de required you to build like 3 non-trivial mesecons machines before you could get access to that |
20:35 |
erlehmann |
because of the potential for lag machines |
20:36 |
erlehmann |
my best lag machine was something i used to destroy a bunch of duped sponges i stole from fleckenstein hehe |
20:36 |
erlehmann |
it dropped all the sponges into lava, but that meant they existed as items in flight for a while, i.e. entities |
20:36 |
sfan5 |
offtopic stories -> #minetest |
20:36 |
erlehmann |
ok |
20:36 |
erlehmann |
back to mod security |
20:37 |
erlehmann |
i already know that you can cheat inside the game once you have gained the mod level (i.e. outside of sandbox) |
20:37 |
erlehmann |
right? |
20:37 |
sfan5 |
which sandbox are you talking about? the engine has only one sandbox that protects the OS from mods |
20:37 |
erlehmann |
but a mod can only write into its own directory. how is that mediated and may there be holes? |
20:38 |
rubenwardy |
erlehmann: not after load time |
20:38 |
erlehmann |
sfan5 the one that does not let you play serialize games |
20:38 |
rubenwardy |
sfan5: setfenv in mesecons luacontrollers |
20:38 |
rubenwardy |
erlehmann: mods don't get any special privileges after load time, they can only get handles to write/etc whilst loading in their own init.lua files |
20:38 |
erlehmann |
rubenwardy wait, at *load* time a mod can write somewhere else? or what can it do? |
20:39 |
rubenwardy |
no, at load time a mod can write to its own directory. After load time, a mod cannot write to its own directory (unless it has an open handle) |
20:39 |
erlehmann |
uh, well the maps mod in mcl2 and mcl5 does write tga files there though. i assume it has a handle … to the directory? |
20:40 |
erlehmann |
is a handle an inode or sth? |
20:40 |
erlehmann |
i guess all security escalation techniques ultimately come down to finding an existing gadget, like the domain socket that wsor1024 mentioned |
20:40 |
erlehmann |
and subverting it |
20:40 |
erlehmann |
thank you all! |
20:42 |
MTDiscord |
<exe_virus> It can also always write to the world folder |
20:42 |
erlehmann |
can anyone who understands C++ much better than i do figure out if this is indeed an endianness bug? because if it is, minetest has it inherited: https://sourceforge.net/p/irrlicht/bugs/431/ |
20:43 |
|
v-rob joined #minetest-dev |
20:43 |
MTDiscord |
<exe_virus> Endianess bugs are typically hardware specific |
20:44 |
MTDiscord |
<exe_virus> Either way, I wanted a core devs opinion on the gltf thing. Should I just bring the single MIT header into the PR or should I submodule about 10 files? |
20:44 |
MTDiscord |
<exe_virus> It would introduce two competing jsonhpp does into our codebase if I submodule |
20:44 |
MTDiscord |
<exe_virus> Deps* |
20:44 |
sfan5 |
"jsonhpp"? |
20:46 |
erlehmann |
exe_virus competing in what way? |
20:53 |
v-rob |
sfan5: I'm fine with #11922 going into 5.5, it does have two approvals after all, so we might as well |
20:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/11922 -- Allow resetting celestial vault elements by leaving its arguments empty by Zughy |
20:54 |
[0] |
We already depend on jsoncpp, I'd prefer to not have two JSON libraries. |
20:54 |
sfan5 |
agreed |
20:54 |
sfan5 |
v-rob: okay thanks, guess I'll merge that then when it's ready |
20:54 |
sfan5 |
(waiting on this https://github.com/minetest/minetest/issues/11930#issuecomment-1018744481) |
20:55 |
|
troller joined #minetest-dev |
20:55 |
v-rob |
OK |
20:55 |
Pexin |
erlehmann: isn't that sourceforge example explicitly re-ordering the bytes into something that's not big OR little endian? |
20:56 |
MTDiscord |
<exe_virus> Kk, that's what I figured. I'll make sure it uses our jsoncpp |
20:56 |
MTDiscord |
<exe_virus> Thanks for the input |
20:59 |
welfarejazz |
through the lua api is there a way to change the player's step height? |
20:59 |
v-rob |
It would be sane if SColor stored its bytes in the native platform's endianness. It's in-memory after all. I don't know if Irrlicht is sane, however. |
21:00 |
sfan5 |
welfarejazz: yes, part of object properties (set_properties) |
21:00 |
welfarejazz |
thank you |
21:05 |
Pexin |
erlehmann: as I read it, that bug report refers to 2 potential problems. endianness (which may or may not be a problem if interpreted unchanged as u32?) and the unrelated swap of R and B |
21:06 |
v-rob |
erlehmann: Looking at the source for SColor, it does use platform-native endianness. As long as libpng (and other image loading libraries) flip endianness properly, there should be no issue. |
21:06 |
v-rob |
I would assume that they do |
21:06 |
v-rob |
It would be somewhat ludicrous if a library as established as libpng didn't work on big-endian systems :) |
21:07 |
MTDiscord |
<exe_virus> Is minetest C++11, or C++14? |
21:07 |
v-rob |
11 |
21:08 |
erlehmann |
Pexin middle-endian, they call it lol |
21:08 |
v-rob |
Minetest does not need to work on a PDP-11, please and thank you |
21:09 |
erlehmann |
Pexin, well ABGR is a real thing |
21:13 |
Pexin |
don't quote me, but I suspect that "solution" actually _creates_ an endianness problem.. you should definitely get an expert opinion though |
21:15 |
Pexin |
oh wait nevermind that's a constructor |
21:17 |
Pexin |
this is what happens when you offer advice while distracted |
21:19 |
Pexin |
the fact remains the point of that report was BR swap |
21:27 |
|
v-rob joined #minetest-dev |
21:52 |
|
appguru joined #minetest-dev |
21:56 |
|
calcul0n joined #minetest-dev |
22:51 |
sfan5 |
#11976 review plz |
22:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/11976 -- [NO SQUASH] Database-related changes by sfan5 |
22:51 |
sfan5 |
and I have no idea what to do with #11831, there's way too much code for what should be a simple fix |
22:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/11831 -- Don't go out of the map during raycast by savilli |
23:04 |
erlehmann |
sfan5 does it depend on the android version if the workaround is needed or is simply havivng new enough sqlite for android enough? |
23:05 |
sfan5 |
it'll be the latter |
23:07 |
MTDiscord |
<Bastrabun> I will try to add 11976 to the main server and report back whether it helped. Is there anything else I can do to further it in any direction? |
23:08 |
sfan5 |
nah that's all :) |
23:17 |
|
v-rob joined #minetest-dev |
23:46 |
|
kilbith_ joined #minetest-dev |