| Time |
Nick |
Message |
| 01:32 |
|
specing_ joined #minetest-dev |
| 01:34 |
|
olliy joined #minetest-dev |
| 01:53 |
|
Seirdy joined #minetest-dev |
| 02:51 |
|
Seirdy joined #minetest-dev |
| 03:54 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:23 |
|
mohanwavale joined #minetest-dev |
| 08:25 |
mohanwavale |
Hello, #minetest-dev! What do you think about login and password manager for multiplayer in minetest? |
| 09:07 |
|
hlqkj joined #minetest-dev |
| 09:07 |
sfan5 |
the feature has been much requested but there's some disagreement about whether it's possible to implement it securely |
| 09:39 |
mohanwavale |
What about extension for integrating pass, lastpass, keepass and other? |
| 09:41 |
|
calcul0n_ joined #minetest-dev |
| 10:23 |
|
Fixer joined #minetest-dev |
| 10:40 |
|
tech_exorcist joined #minetest-dev |
| 10:49 |
|
hlqkj joined #minetest-dev |
| 10:50 |
MTDiscord |
<srinivas> mohanwavale: if you are still around, I am in the process of writing a launcher for minetest that stores passwords securely |
| 10:50 |
MTDiscord |
<srinivas> also, sfan5, good cryptographic algorithms exist today |
| 10:51 |
MTDiscord |
<srinivas> AES, ChaCha20 etc |
| 11:02 |
pgimeno |
I don't think it's about the cryptographic algorithms |
| 11:11 |
MTDiscord |
<srinivas> then what else? the way to store it? the way to send it? |
| 11:19 |
sfan5 |
I think it's more whether we trust ourselves to write a basic secure password manager, cryptography is not easy to get right |
| 11:23 |
pgimeno |
how to uniquely identify a server (in order to pick the right password) sounds like a problem to me |
| 11:28 |
MTDiscord |
<srinivas> > how to uniquely identify a server (in order to pick the right password) sounds like a problem to me server addr + port is normally unique enough |
| 11:29 |
pgimeno |
servers change address and/or port, and sometimes a different server can appear at the same address/port as a previous one |
| 11:30 |
MTDiscord |
<srinivas> > cryptography is not easy to get right True enough, but there are enough things to draw inspiration from. for example iirc keepassx uses chacha20, and a fairly standard kdf |
| 11:31 |
MTDiscord |
<srinivas> the idea of password managers have been around for a long time, Secure ways can be found via platform specific libraries, or if you want to have something more sso'ish or with sync, storage on public infrastructure is not too difficult to implement |
| 11:32 |
pgimeno |
something like a server-sent UUID would help |
| 11:47 |
MTDiscord |
<srinivas> as a password? not the best of passwords, no more than 122 bits of entropy |
| 11:47 |
MTDiscord |
<srinivas> a good password should have more than that |
| 11:57 |
pgimeno |
as a server-side ID in order to identify a server uniquely even if it changes its address |
| 12:01 |
MTDiscord |
<srinivas> ah |
| 13:03 |
MTDiscord |
<Warr1024> Just store the passwords plaintext, and users should be using secure filesystem permissions, and not putting too much value into their MT credentials in the first place. |
| 13:04 |
MTDiscord |
<Warr1024> People who are currently storing passwords are doing so using shell scripts and launcher shortcuts which are already plaintext. |
| 13:05 |
MTDiscord |
<Warr1024> At best you could mildly obscure them like base64, rot13, or some static-keyed cipher with maybe a random IV, but that would only protect against casual shoulder surfing anyway. At least, it's probably not possible to make security worse than it already is. |
| 13:08 |
MTDiscord |
<Warr1024> Reinventing a password manager sounds pointless. If I have to enter a password to unlock a password then I might as well just enter my password as the server password and let SRP do the work. |
| 13:10 |
Calinou |
maybe we should just have a way to read a system environment variable to use as a password, and let the user set it securely |
| 13:10 |
Calinou |
perfect is the enemy of good, yadda yadda :) |
| 13:13 |
MTDiscord |
<Warr1024> An env bar might be alright but if a user has to set those in bashrc or something so that it's always available for MT, it may effectively get pushed into other places, like atjobs or something. |
| 13:13 |
MTDiscord |
<Warr1024> Something like what ~/.netrc does though should be fine... |
| 13:14 |
MTDiscord |
<Warr1024> I would have just stored them in minetest.conf or the server favorites file or something. |
| 13:34 |
|
specing_ joined #minetest-dev |
| 13:47 |
|
Fixer_ joined #minetest-dev |
| 14:00 |
|
Wuzzy joined #minetest-dev |
| 14:20 |
sfan5 |
feedback wanted: ä11131 |
| 14:20 |
sfan5 |
damnit |
| 14:20 |
sfan5 |
#11131 |
| 14:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/11131 -- Async environment for mods to do concurrent tasks by sfan5 |
| 14:23 |
|
I_am_6r1d joined #minetest-dev |
| 14:47 |
|
hlqkj_ joined #minetest-dev |
| 14:51 |
celeron55_ |
interesting |
| 16:00 |
|
Taoki joined #minetest-dev |
| 16:19 |
MTDiscord |
<Jordach> I can see a benefit to async already for a lot of mods that play with entities |
| 16:19 |
MTDiscord |
<Jordach> Especially with how heavy pathfinding actually is |
| 16:21 |
|
absurb joined #minetest-dev |
| 16:23 |
rubenwardy |
it's a worker thread, you can't access globals or most of the Lua API |
| 16:24 |
MTDiscord |
<Jordach> I didn’t say you couldn’t just pack a local area of the map into numeric IDs much the same way VMs work |
| 16:29 |
|
red-001 joined #minetest-dev |
| 16:30 |
sfan5 |
would make sense if you could run the pathfinder on a vmanip |
| 16:38 |
MTDiscord |
<Warr1024> It would make sense if the pathfinding algo is much heavier than serializing the vmanip to ship it to a worker, but most algs probably aren't really that slow. |
| 16:44 |
MTDiscord |
<appguru> Voxelizer might benefit from this. Currently voxelization just blocks the main thread. |
| 16:45 |
MTDiscord |
<appguru> It'd be nice of there were some kind of channels, not just like a worker process which receives some input and finishes with some output |
| 16:56 |
sfan5 |
what's your usecase for those? |
| 17:04 |
|
olliy_ joined #minetest-dev |
| 17:10 |
MTDiscord |
<Benrob0329> I could probably push IKEA's Lua pathfinder into a worker thread, and passing data and functions should be possible, correct? |
| 17:22 |
sfan5 |
data yes, functions no |
| 17:34 |
MTDiscord |
<Warr1024> you could pass functions as strings and parse them destination-side ... but that probably doesn't let you actually do anything you couldn't already do by just having the code already there in the first place. |
| 19:22 |
MTDiscord |
<appguru> LÖVR's thread module might be relevant: https://lovr.org/docs/lovr.thread |
| 19:22 |
MTDiscord |
<appguru> Usecase is everything which doesn't need it's state resetted |
| 19:23 |
MTDiscord |
<appguru> For example, pathfinding: Initiate the pathfinder with a world state (VoxelManip), then provide start and end pos and get a path somewhen |
| 19:23 |
MTDiscord |
<appguru> The "world state" doesn't have to always be provided anew entirely |
| 19:30 |
sfan5 |
if you had a worker thread to yourself you could push the initial state through as a job and updates, the actual pathfinding instructions, etc. the same way |
| 20:14 |
sfan5 |
I have a suspicion that debug.setupvalue should not be on the security whitelist |
| 20:14 |
|
proller joined #minetest-dev |
| 20:18 |
rubenwardy |
lol definitely not |
| 20:18 |
rubenwardy |
that's crazy |
| 20:23 |
red-001 |
In fairness it doesn't directly leak the insecure environment |
| 20:23 |
red-001 |
unlike ~50% of mods that use it |
| 21:00 |
|
DS-minetest joined #minetest-dev |
| 21:01 |
sfan5 |
rubenwardy: btw I was thinking of raising the default curl timeout, since 5s a thigh goal if you consider connection retries, dns, ... |
| 21:01 |
rubenwardy |
yeah makes sense to me |
| 21:01 |
sfan5 |
most other applications also just wait 60s or until user abort |
| 21:01 |
sfan5 |
alright, good |
| 21:01 |
sfan5 |
as a new default probably either 15s or 20s is good IMO |
| 21:02 |
sfan5 |
s/thigh/tight/ lol |
| 21:02 |
rubenwardy |
I think 20-30s for curl and 60 for downloads |
| 21:02 |
rubenwardy |
although heh |
| 21:02 |
rubenwardy |
does timeout include transfer time? |
| 21:03 |
sfan5 |
only connection establishment I'd think |
| 21:03 |
rubenwardy |
ContentDB used to time out when it took >10s |
| 21:04 |
rubenwardy |
so it's at least time until first response |
| 21:07 |
sfan5 |
// Timeout for the whole transfer, in milliseconds |
| 21:07 |
sfan5 |
long timeout; |
| 21:07 |
sfan5 |
? |
| 21:07 |
MTDiscord |
<Jordach> ? |
| 21:09 |
rubenwardy |
first response and full transfer should be different limits really |
| 21:11 |
sfan5 |
there are different limits but (except for remote media) they are set to the same |
| 21:13 |
MTDiscord |
<Warr1024> Mesaage-passing worker threads would be great for compute-heavy work, but not necessarily for access-heavy work. So, like, an A* pathfinding algo might not be great to run in a worker because the work of serializing the space to search would be comparable to running the algo ... But if you wanted to then run a ramer-douglas-peucker path simplification on the result, that might make it worthwhile. |
| 21:14 |
MTDiscord |
<Warr1024> Having the tool would be really useful, but figuring out when it helps and when it doesn't could be tricky. |
| 21:17 |
nerzhul |
currently MT is not really heavy we don't have thousands of entities :) |
| 21:17 |
rubenwardy |
you can do, with something like pipeworks |
| 21:18 |
DS-minetest |
mods would make more entites if they weren't so heavy |
| 21:18 |
rubenwardy |
the low hanging fruit would be object collision and lookup. It's currently O(n^2) and O(n) |
| 21:25 |
sfan5 |
@Warr1024 if you continually keep a shadow copy of active mapblocks up-to-date running pathfinding in a worker would be free |
| 21:25 |
MTDiscord |
<exe_virus> Still working on that solution for position based map lookups |
| 21:25 |
MTDiscord |
<exe_virus> So we can support way more entities haha |
| 21:26 |
sfan5 |
question remains is it worth to defer work to a thread when it only takes N*100 ms? |
| 21:26 |
MTDiscord |
<Warr1024> Shadow copy ... interesting idea ... but probably the work of identifying changes and syncing them efficiently to the worker could end up itself being a lot of work. |
| 21:26 |
sfan5 |
pgimeno: the default metatables lua has are on strings, correct? |
| 21:27 |
sfan5 |
the only* |
| 21:27 |
MTDiscord |
<Warr1024> what makes the most sense to me is to do like webworkers/serviceworkers: spin up a long-lived worker thread, pass arbitrary messages to it, and have an event pump running inside. |
| 21:28 |
|
appguru joined #minetest-dev |
| 21:33 |
|
MTDiscord joined #minetest-dev |
| 22:42 |
|
red-001 joined #minetest-dev |
