Time Nick Message 08:25 mohanwavale Hello, #minetest-dev! What do you think about login and password manager for multiplayer in minetest? 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? 10:50 MTDiscord mohanwavale: if you are still around, I am in the process of writing a launcher for minetest that stores passwords securely 10:50 MTDiscord also, sfan5, good cryptographic algorithms exist today 10:51 MTDiscord AES, ChaCha20 etc 11:02 pgimeno I don't think it's about the cryptographic algorithms 11:11 MTDiscord 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 > 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 > 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 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 as a password? not the best of passwords, no more than 122 bits of entropy 11:47 MTDiscord 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 ah 13:03 MTDiscord 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 People who are currently storing passwords are doing so using shell scripts and launcher shortcuts which are already plaintext. 13:05 MTDiscord 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 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 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 Something like what ~/.netrc does though should be fine... 13:14 MTDiscord I would have just stored them in minetest.conf or the server favorites file or something. 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:51 celeron55_ interesting 16:19 MTDiscord I can see a benefit to async already for a lot of mods that play with entities 16:19 MTDiscord Especially with how heavy pathfinding actually is 16:23 rubenwardy it's a worker thread, you can't access globals or most of the Lua API 16:24 MTDiscord 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:30 sfan5 would make sense if you could run the pathfinder on a vmanip 16:38 MTDiscord 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 Voxelizer might benefit from this. Currently voxelization just blocks the main thread. 16:45 MTDiscord 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:10 MTDiscord 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 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 LÖVR's thread module might be relevant: https://lovr.org/docs/lovr.thread 19:22 MTDiscord Usecase is everything which doesn't need it's state resetted 19:23 MTDiscord 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 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: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: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 ? 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 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 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 Still working on that solution for position based map lookups 21:25 MTDiscord 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 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 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.