| Time |
Nick |
Message |
| 01:13 |
|
kilbith joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:07 |
|
Noisytoot joined #minetest-dev |
| 07:42 |
MTDiscord |
<jordan4ibanez> We have now overtaken platinum arts sandbox graphically. Or, at least what I remember it being. Woooo |
| 07:44 |
MTDiscord |
<jordan4ibanez> Wait a second, stop the presses. Platinum arts sandbox is now based off Minetest :O :O :O |
| 08:07 |
|
Baytuch_2 joined #minetest-dev |
| 09:18 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:19 |
|
calcul0n joined #minetest-dev |
| 09:22 |
|
Warr10246 joined #minetest-dev |
| 09:35 |
|
Fixer joined #minetest-dev |
| 11:51 |
|
proller joined #minetest-dev |
| 13:13 |
|
kilbith joined #minetest-dev |
| 13:13 |
|
kilbith joined #minetest-dev |
| 13:19 |
|
kilbith joined #minetest-dev |
| 14:00 |
|
Fixer joined #minetest-dev |
| 14:19 |
MTDiscord |
<MisterE> no, thats a new project he is working on called "D's Sandbox", and it is based off of a glitched version of minetest 0.4.13 |
| 14:23 |
|
m42uko joined #minetest-dev |
| 14:35 |
|
kilbith joined #minetest-dev |
| 15:39 |
sfan5 |
@x2048 you have a review |
| 15:43 |
|
fluxionary joined #minetest-dev |
| 16:05 |
|
vampirefrog joined #minetest-dev |
| 16:08 |
|
Desour joined #minetest-dev |
| 16:17 |
|
Desour_ joined #minetest-dev |
| 16:28 |
|
proller joined #minetest-dev |
| 17:02 |
|
jwmhjwmh joined #minetest-dev |
| 17:46 |
|
Desour joined #minetest-dev |
| 17:52 |
Krock |
sfan5: https://github.com/minetest/minetest/pull/13133#discussion_r1083473272 conditional and increment is incorrect |
| 17:53 |
Krock |
also I wonder whether that would change anything because the compiler places the struct on stack anyway. if it's intelligent enough, it might even do this automatically |
| 17:54 |
Krock |
s/the struct/the iterated variables xyz/ |
| 18:02 |
jwmhjwmh |
Is there a meeting here now? |
| 18:02 |
Krock |
I don't think so. nothing's announced |
| 18:02 |
Krock |
but if there's other devs online we could look at PRs and issues nonetheless |
| 18:03 |
jwmhjwmh |
One seems to be scheduled for today: https://dev.minetest.net/Meetings#2023-01-22 |
| 18:04 |
Krock |
nothing on github though. it seems that I simply copied it over after saving the last meeting. I don't know who's available now |
| 18:08 |
jwmhjwmh |
Perhaps core devs who are here can look at the "SSCSM execution" section at that meeting link I posted. I'd like some assistance with the PR. |
| 18:12 |
Krock |
why exactly are separate processes needed? |
| 18:13 |
jwmhjwmh |
Process sandboxing. |
| 18:14 |
jwmhjwmh |
E.g. seccomp. |
| 18:15 |
Krock |
is blacklisting API functions not secure enough? just wondering |
| 18:16 |
Desour |
iirc, we wanted to do the process sandboxing for the case that the lua sandbox somehow failed |
| 18:17 |
Desour |
btw. jwmhjwmh did you implement other sandboxing things than seccomp yet? |
| 18:18 |
jwmhjwmh |
The sandbox is implemented on Mac OS. For Windows I tried using the Windows Integrity Mechanism, but I don't know if it works. It should restrict file writes. |
| 18:18 |
jwmhjwmh |
SSCSM could be disabled on systems for which sandboxing is not enabled. |
| 18:20 |
Krock |
and there's no way to apply that to specific threads? I'm asking because there's many wrapper functions and IPC-related processing that add 1) overhead and 2) maintenance costs |
| 18:21 |
Desour |
afaik, seccomp works on threads. but it's quite useless if we don't have a separate memory space |
| 18:21 |
Desour |
quite = completely |
| 18:22 |
Desour |
(i.e. you could just do ROP on the main thread) |
| 18:22 |
Desour |
on the main thread's stack* |
| 18:23 |
Desour |
jwmhjwmh: did you think about also putting the process in different namespaces in linux? |
| 18:23 |
Krock |
it would be somewhat fancy if we could convert individual events like CSM_C2S_RUN_HP_MODIFICATION into a function lookup + automatic value forwarding using va_args |
| 18:24 |
jwmhjwmh |
Desour: I haven't looked into that. Seccomp seemed to do the job. |
| 18:24 |
Krock |
i.e. to make all parameter handling dynamic since we already know the function signatures |
| 18:32 |
Zughy[m] |
My bad for the meeting, pretty busy weeks, I can hardly label issues. Wsor asked to be a triager as well, a few weeks ago. Please let them, I can't handle everything on my own in these days |
| 18:33 |
Zughy[m] |
I think the main thing was, feature freeze now: yes/no |
| 18:35 |
jwmhjwmh |
Krock: That might be possible. We could have serialization functions for tuples, vectors, etc. I can look into that. |
| 18:35 |
sfan5 |
<+jwmhjwmh> SSCSM could be disabled on systems for which sandboxing is not enabled. |
| 18:36 |
sfan5 |
I think it's obvious but disabling one of our main features on windows is out of question |
| 18:36 |
Krock |
jwmhjwmh: if you can find a way, that would have potential to reduce the wrapper functions part to a fraction of what it currently is |
| 18:37 |
jwmhjwmh |
sfan5: Yes, hopefully blocking filesystem writes is adequate as the Windows sandbox. I don't think a full sandbox is available. |
| 18:38 |
sfan5 |
how does chromium do it? |
| 18:38 |
Krock |
firefox can do it as well. even without Intel Virtualization Technology or AMD whatever it is called |
| 18:39 |
Krock |
unless I am mistaken about the virtualization aspect. it might also be a hardened API that checks for file permissions for every javascript call |
| 18:45 |
rubenwardy |
RE: Android - I guess fork() is unavailable? |
| 18:48 |
jwmhjwmh |
fork() is available, but it seems impossible to include an executable in the APK. Maybe it could be done with some hackery in the Makefile to make libMinetest.so executable. |
| 18:49 |
sfan5 |
if you do fork you won't need an executable |
| 18:51 |
sfan5 |
anyway maybe for android we can leave it unsandboxed since the OS already does a great job? |
| 18:54 |
jwmhjwmh |
I guess the process could fork without exec, but that would probably waste a lot of memory since forked memory is CoW. |
| 18:55 |
jwmhjwmh |
I think seccomp is available on Android, so we might as well sandbox. |
| 18:57 |
jwmhjwmh |
I guess to avoid wasting memory the process could fork at the very beginning then the forked process could fork itself as needed. |
| 19:11 |
|
kilbith joined #minetest-dev |
| 19:30 |
|
proller joined #minetest-dev |
| 19:36 |
kilbith |
sfan5: here's an improved (I believe) MinGW build script that automatically MT alongside with irrlicht (or forks): https://gist.github.com/kilbith/2d218c27d0e1e4a1fea865a305d6cac2 |
| 19:36 |
kilbith |
* automatically build, oops |
| 19:37 |
kilbith |
it's also a more "straightforward" build process than buildbot |
| 19:38 |
kilbith |
so you don't have to build irrlicht on mingw separately, this script takes care of everything at once |
| 20:06 |
|
proller joined #minetest-dev |
| 20:23 |
|
proller joined #minetest-dev |
| 20:46 |
|
kilbith joined #minetest-dev |
| 21:34 |
|
vampirefrog joined #minetest-dev |
| 21:35 |
|
kilbith joined #minetest-dev |
| 22:27 |
MTDiscord |
<x2048> sfan5: Thank you |
| 22:31 |
|
Fixer_ joined #minetest-dev |
| 23:18 |
MTDiscord |
<x2048> Merging #13151, #13157, #13165 |
| 23:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/13151 -- Clear exposure compensation textures on creation. by x2048 |
| 23:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/13157 -- Implement --debugger option to improve UX when debugging crashes by sfan5 |
| 23:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/13165 -- Decrease minimum for repeat_place_time by Desour |
| 23:20 |
MTDiscord |
<x2048> Done |
