Minetest logo

IRC log for #minetest-dev, 2021-03-28

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext