Minetest logo

IRC log for #minetest-dev, 2015-01-02

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

All times shown according to UTC.

Time Nick Message
00:03 paramat joined #minetest-dev
00:11 shadowzone joined #minetest-dev
00:21 MinerDad joined #minetest-dev
00:22 Wayward_One joined #minetest-dev
00:23 paramat hmmmm thanks for the merges. i suggest not bothering with MC's fractal biome system considering the amount of more important work you have. looking at a MC biome map, the edges are nicaly crinkled but i find it a little boring, like a jigsaw puzzle of near-equal sized pieces
00:53 paramat (unless of course it's for your v8)
00:55 Selah joined #minetest-dev
01:00 Selah joined #minetest-dev
01:28 crazyR joined #minetest-dev
01:42 Megaf joined #minetest-dev
01:51 paramat left #minetest-dev
01:58 shmancelot joined #minetest-dev
02:11 hmmmm well i was going to implement it anyway as part of the minecraft mapgen
02:11 hmmmm since we'll have multiple biome systems this should be trivial to do
02:11 hmmmm to do in a clean manner
02:11 Zeno` joined #minetest-dev
02:12 MinerDad joined #minetest-dev
02:28 paramat joined #minetest-dev
02:28 paramat thats cool
02:34 paramat hmmmmm https://forum.minetest.net/vi​ewtopic.php?f=11&t=10888 i wrote a simple mapgen last night, primarily to demonstrate to you how floatlands and lava underworlds can be simply generated in a 3D noise mapgen by manipulating the density gradient only
02:52 MinerDad joined #minetest-dev
02:54 paramat next i'll be using a periodic function for grad above ground to create multiple levels
03:10 MinerDad joined #minetest-dev
03:12 deltib left #minetest-dev
03:14 Zeno` https://github.com/minetest/minetes​t/blob/master/src/mapgen_v7.cpp#L43
03:14 Zeno` ^^ hmmmm, I don't understand why that's an array
03:15 Zeno` flagdesc_mapgen_v7[0] is the only thing that (seems to be) ever used
03:19 Zeno` err... nvm
04:02 MinerDad joined #minetest-dev
04:11 deltib joined #minetest-dev
04:37 paramat left #minetest-dev
04:38 hmmmm joined #minetest-dev
05:31 sol_invictus joined #minetest-dev
05:40 alexxs joined #minetest-dev
06:12 hmmmm :/
06:12 hmmmm i'm gonna need to do real work tomorrow
06:18 hmmmm anybody familiar enough with irrlicht know if I could use its texture saving/loading capabilities to write arbitrary images to png without having to add a libpng dependency?
06:19 paramat joined #minetest-dev
06:28 kahrl hmmmm, sure
06:28 kahrl see Client::makeScreenshot for an example
06:29 hmmmm ahh great!
06:30 hmmmm probably not a good idea on second though since what i'd like to do would require both client and server to be built
06:38 Hunterz joined #minetest-dev
07:02 cib0 joined #minetest-dev
07:15 paramat interesting that the LVM will light-up light sources but does not spread the light of them, not even an ABM using nodeupdate(pos) does, i have to 'remove' it and 'place' it again
07:15 hmmmm it does spread light sources
07:16 hmmmm if you're saying that doesn't spread light sources, then the mapgen doesn't, and mapgen lighting is completely broken
07:25 ImQ009 joined #minetest-dev
07:29 paramat yes it's weird the code looks okay. sunlight is spread but my underworld lux ore (light = 14) is not. it's been this way since LVM was added
07:35 hmmmm how does that happen
07:35 paramat https://cdn.mediacru.sh/4/46BrBS4P1XNy.png also lava light is somewhat spread but not smoothly
07:35 hmmmm lava is a light source that isn't sunlight and it seems to spread it just fine
07:36 hmmmm perhaps i should stop liquid flow and see again
07:37 paramat ah lava liquid update would perhaps be updating the lava light
07:39 paramat actually that lava light spread i perhaps okay, the sudden light falloff in the image may be due to light level saturation
07:39 paramat *is
07:40 hmmmm can confirm
08:00 paramat the mapgen where this happens ends with: vm:set_data(data) vm:set_lighting({day=0, night=0}) vm:calc_lighting() vm:write_to_map(data) vm:update_liquids()
08:00 hmmmm thisi s really odd
08:00 hmmmm i have a different problem at the moment... the light is tinted blue rather than yellow
08:01 hmmmm that only happens if the light source == LIGHT_SUN if i recall correctly
08:06 MinerDad joined #minetest-dev
08:09 paramat ^ RealBadAngel might have insight on tinting
08:10 hmmmm ahh i found an instance of a light source acting like your screenshot
08:11 hmmmm how much you wanna bet if i change content_ignore to propogate sunlight, it'll work properly
08:14 RealBadAngel hmmmm, the only code that could make it blue is imho finalColorBlend
08:14 hmmmm no shit...
08:14 RealBadAngel in mapblock_mesh and in shaders
08:15 paramat heh i wouldn't bet against you
08:18 paramat my affected light sources are mostly well away from ignore nodes
08:35 paramat left #minetest-dev
08:36 jluc joined #minetest-dev
08:38 hmmmm my tests confirm that content ignore not propogating sunlight does not affect this
08:38 hmmmm funny enough, if content ignore propogated sunlight, minetest would crash
08:38 hmmmm with calcLightingOld it won't crash, because the block will never finish emerging
08:39 hmmmm with my optimized calcLighting, the block emerges fine but then crashes because of a stack overflow in Map::spreadLight
08:39 hmmmm haha
08:39 hmmmm ... :/
08:43 hmmmm calcLightingOld has this problem to some extent as well
08:57 kilbith joined #minetest-dev
09:13 Krock joined #minetest-dev
10:05 ImQ009 joined #minetest-dev
10:16 chchjesus joined #minetest-dev
10:32 nore joined #minetest-dev
10:36 chchjesus joined #minetest-dev
10:40 Taoki[mobile] joined #minetest-dev
10:47 Taoki[mobile]_1 joined #minetest-dev
11:14 alexxs joined #minetest-dev
11:21 Zeno` joined #minetest-dev
11:27 Zeno` #2037 ... I'm sure there is another issue already like this but I can't find it
11:27 ShadowBot https://github.com/minetest/minetest/issues/2037 -- World mod configuring is broken
11:33 alexxss joined #minetest-dev
11:49 loggingbot_ joined #minetest-dev
11:49 Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/
11:50 sfan5 is back.
11:50 celeron55 wiki and dev
11:50 sfan5 i always forget about those
11:50 celeron55 looks like everything is back up now
11:51 celeron55 seems like an intended reboot of the server
11:51 sfan5 yup
12:11 Zeno` why is struct used instead of class in so many places?
12:18 Zeno` Surely there is a reason.
12:18 Zeno` celeron55?
12:26 Zeno` Probably should turn most of them into class if there is no reason
12:26 alexxs joined #minetest-dev
12:51 jin_xi joined #minetest-dev
12:52 celeron55 i never use class in my new code because it's useless
12:53 celeron55 it could be removed from the language for all i care
13:01 Zeno` ?
13:01 Zeno` Not sure I understand the reasoning :)
13:06 Zeno` class is bad because... ?
13:06 Taoki joined #minetest-dev
13:09 celeron55 because it's completely redundant
13:09 celeron55 struct does the same things with saner defaults (it's public by default)
13:10 celeron55 and when you use only one, you don't get some compilers complaining when you accidentally don't remember which one you used
13:10 celeron55 and you never have to think which one to use, because you use only one
13:10 celeron55 everything goes smoother
13:15 Taoki joined #minetest-dev
13:21 Zeno` Have you told the C++ committee?
13:22 jin_xi lol they gonna add structclass or so
13:27 celeron55 Zeno`: i don't think they would listen to me
13:27 celeron55 and they have to preserve compatibility anyway
13:39 chchjesus joined #minetest-dev
13:46 selat joined #minetest-dev
14:08 sol_invictus joined #minetest-dev
14:12 UnknownSentinel joined #minetest-dev
14:22 chchjesus joined #minetest-dev
14:22 ImQ009_ joined #minetest-dev
14:34 est31 joined #minetest-dev
14:36 sapier joined #minetest-dev
14:36 est31 Hello, any plans to improve in the login situation? The hashes are still unsalted and password reuse still enables malicious server owners to take over accounts on other servers.
14:37 est31 and replay vulnerability
14:37 sapier in order to improve login situation whole server communication or at least the login process needs to be rewritten not sure if there's anyone willing to do that work ;-)
14:38 sapier it's been discussed multiple times but any single improovement suggested was worthless without encrypted client server communication for that initial phase
14:39 est31 and then either encrypt anything or nothing, c55 didn't want two connections. I remember a discussion I had some time ago on this channel.
14:39 est31 but wouldn't call it worthless
14:40 sapier well I agree to this encrypting everything is way better then only part of it
14:40 est31 main argument was latency
14:40 sapier encrypting login/passwd change is just minimum you have to do to get passwords at least somehow secure
14:41 sapier true yet there are quite fast encryption algorithms
14:41 ImQ009 joined #minetest-dev
14:41 sapier and  main issue is we'd have issues with package loss
14:41 est31 no that can be met
14:41 est31 there is ZRTP
14:42 sapier never heared about it
14:42 est31 its made for that purpose: encryption over UDP
14:42 est31 in fact its TLS over UDP
14:42 sfan5 isb
14:43 sapier but according to wikipedia zrtp is only key exchange
14:43 est31 it doesn't break with package loss, but adds sequence numbers to UDP. The expensive thing on TCP however is package loss.
14:43 sfan5 why not DTLS then?
14:43 sapier not encryption
14:43 est31 sorry DTLS
14:43 sapier for our packet sizes some cbc encryption would be required but cbc only works if there's no packet loss
14:48 sapier dtls seems to be interesting
14:48 sfan5 wasn't cbc insecure?
14:48 Eivel joined #minetest-dev
14:48 sapier not if you use it correct
14:49 sapier but you may not loose any packet for cbc
14:49 sapier so it's not gonna work for us
14:50 est31 why is cbc neccessary?
14:50 sapier usually because it's fast for encrypting streams
14:51 sapier and to avoid known plaintext attacks ;-)
14:51 sapier our packets are quite small and contain a quite predictable starting pattern
14:51 est31 ok because of that.
14:51 sapier so risk is high someone can use that information to reverse engeneer the key
14:52 sfan5 who said the whole packet is going to be encrypted?
14:52 sapier maybe we need to append some random dummy data at the end of the packet
14:53 sapier well encrypting only part of it will make it even more vulnerable ;-)
14:53 sapier unless
14:53 sapier no we can't even encrypt our data as it's usually only a few bytes
14:54 sapier unless I'm missing something ;-) in this case tell me
14:54 est31 the fewer bytes we send, the larger the overhead gets
14:56 sapier hmm dtls doesn't tolerate dpacket loss too
14:57 est31 yes it does tolerate
14:57 ImQ009_ joined #minetest-dev
14:57 sapier it's just doing it's own retransmission handling for what I read.
14:57 est31 where did you read that?
14:58 sapier https://tools.ietf.org/html/rfc4347#section-4.2.4
14:58 est31 only the initial handshake doesn't like loss
14:59 est31 s/handshake/buildup/
15:00 sapier ok section 2. clarifies this
15:00 Zeno` sapier, any progress on the font and formspec bugs/issues?
15:00 sapier which ones? the real bugs or the feature changes that are intended part of the fix?
15:01 Zeno` Both I guess
15:02 sapier first part yes there's a bugfix I made vanessaE test, for what I remember it did fix a lot of issues. second one, well the only thing to do there is finetuning the default size. But there's no way to "fix" it for everyones (ab)usage of bugs
15:04 Krock joined #minetest-dev
15:05 Zeno` So https://github.com/minetest/minetest/commi​t/f7f7fec497f83da0d9f6ea2e83796720484033ff can be addressed somehow?
15:05 sapier what?
15:06 sapier you just disable the whole font scaling by second part of this? that's quite nonsense ;-P
15:06 Zeno` I had to #ifdef out the whole function (essentially)
15:06 Zeno` yeah and without doing that nobody could play the game
15:07 sapier what you disable is the part of this patch wich makes fonts scale same as formspec itself scales
15:07 sapier that's basicaly the core part of the font scaling change
15:07 Zeno` well what I disabled is broken :p
15:07 sapier no it's not broken it does exactly what it's intended to do
15:08 hmmmm joined #minetest-dev
15:08 sapier it's scaling the font
15:08 Zeno` yes, it is. And not scaling the formspec
15:08 sapier becaus formspec did already scale!
15:08 Zeno` and it made 99% of formspecs unusable
15:09 sapier by now only formspec did scale but fonts didn't
15:09 Zeno` seriously, look at the bug reports.
15:09 sapier the patch fixes that bug
15:09 sapier and yes I know this changes the behaviour
15:09 Zeno` change is ok, but when a formspec is *not* usable then the behaviour is broken
15:10 Zeno` every single formspec apart from mainmenu was broken
15:10 sapier any formspec looking fine on 800x600 is supposed to still work correct
15:10 sapier if not there's a bug somewhere
15:12 sapier let me look for the missing patch I sent vanesse
15:12 sapier for what I know that one fixed a major issue but isn't merged yet
15:17 Zeno` I tested the patch you sent to VanessaE
15:17 Zeno` It didn't work :(
15:17 sapier can you send me that patch? I don't find it right now ;-)
15:17 Zeno` I'll see if I still have it
15:18 sapier what exactly doesn't work? changing font size by "font_size" setting will not be supported any longer
15:18 sapier that setting is only usefull for adjusting size of your custom font to match formspec
15:19 Zeno` maybe there is something in the logs around about that date?
15:19 sapier I don't know when I did send it to her, and I'm quite sure it's been in private not here
15:19 Zeno` I got it from somewhere... looking
15:20 sapier well let's first try to make sure we're talking about same thing
15:20 sapier what exactly is what you call to be "wrong"?
15:23 Zeno` text not fitting, text overlapping, entire formspec unusable
15:23 sapier screenshots at 800x600 resolution please
15:23 Zeno` why is there no bug report any more? It was marked as blocker :/
15:23 Zeno` stupid github
15:26 est31_ joined #minetest-dev
15:27 est31_ (sorry reposting, wrong channel) In my opinion, encryption isn't this important for the password issue, here are two major issues: replay attacks on family members in the wlan, and replay attacks of users of other servers using the hashes from your own server. both can be solved without encryption.
15:27 sapier suggestions?
15:29 Zeno` I can't find the issue/bug-report anywhere :/
15:29 Zeno` this is very odd
15:29 leat joined #minetest-dev
15:29 est31_ sapier: was that directed to me?
15:31 exio4 joined #minetest-dev
15:32 sapier yes est31 if you have a good idea how to get this done with less effort I'd be glad to do it that way
15:33 Zeno` sapier, ok https://github.com/minetest/minetest/issues/1896
15:33 Zeno` but I still need to find all the screenshots
15:34 Zeno` I have a terrible feeling the screenshots are on the forum somewhere :(
15:34 sapier ahh that's the fix I was talking about, thanks :-) I'm gonna merge it immediatly prior it's lost again
15:35 Zeno` it doesn't fix all the issues though heheh
15:35 Zeno` looking for the screenshots
15:35 est31_ I have ideas, but transition is hard when you require that old clients are interoperable with new servers and other way round.
15:35 sapier I know it's just fixing the rounding errors
15:38 est31_ I'd replace the current "hash(pw) is the password" approach with a simple challenge-response protocol, where the server name gets baked into the hashed reply.
15:39 est31_ I guess forum is a better place for the details?
15:45 sfan5 also
15:45 sfan5 est31_: what is a "server name"?
15:46 sapier est31_ we don't have something as a server name especially as you could even run multiple worlds on same server with just different ports
15:46 est31_ the "name" entry in http://servers.minetest.net/list
15:47 sfan5 so if you decide to rename your server nobody can login anymore?
15:47 est31_ no its sent at login
15:47 est31_ not at setting the password
15:47 sfan5 how does that help?
15:48 sfan5 oh, nvm
15:48 sapier hmm interesting idea, but you could't join a server entering ip address any longer
15:49 sfan5 i think est31_ means that the server sends the server name
15:50 est31_ the server can send the name if you want to retain that feature
15:50 est31_ otherwise the client gets it from the server list
15:51 sfan5 hm
15:51 sfan5 hm
15:51 sfan5 you can circumvent disallow_empty_password in some way by sending a hash of an empty password
15:51 sfan5 instead of just no password at all (which is send for backward compat.)
15:52 est31_ that needs to be thought of
15:52 sfan5 that would be an interesting password
15:52 sfan5 because nobody could replicate it without modifying the src
15:52 est31_ :)
15:53 sapier and couldn't join with a non modified version too
15:53 sfan5 actually
15:53 sfan5 no
15:53 sfan5 that doesn't work
15:53 sfan5 the client sends a plaintext password
15:54 sapier are you sure? thought the hash was sent?
15:54 sfan5 for this reason you can't do a replay attack with password from auth.txt
15:54 sfan5 s/password/hash/
15:54 sfan5 sapier: yes
15:54 ImQ009 joined #minetest-dev
15:55 sfan5 m_password is std::string
15:55 sfan5 and it's put into the packet using snprintf
15:55 Zeno` can't do a "replay attack"? What's that mean?
15:55 sfan5 both of which would be a bad idea for raw hashes
15:55 Zeno` If I have auth.txt and the person uses the same password on another server I can easily log in as them
15:55 sfan5 Zeno`: use the hash from auth.txt to login to the same account on another server
15:55 sapier well we already know our login is about as secure as telnet login
15:55 Zeno` sfan5, you can
15:56 est31_ thats the second problem
15:56 sfan5 ok let me try this
15:56 sfan5 upQa9QdxCJzB551UjVZlO3CpDV4
15:57 sfan5 k, thats base64
15:57 est31_ people can still replicate it
15:58 sfan5 thats actually a hash
15:58 Zeno` you don't have to replicate it; you just change (in the source code) the hash that is sent to the server
15:58 est31_ yes and they only replicate the hash
15:58 est31_ Zeno yes you dont need to pre-image it
15:58 sfan5 pre-what
15:58 sfan5 ?
15:58 est31_ pre-image: thats the term
15:59 est31_ a (mathematical) function always maps a value to its image.
15:59 sfan5 so you want to collide sha1
15:59 sfan5 have fun
15:59 est31_ if you go the other way, you want to find a pre-image for the image.
15:59 sfan5 also: why are we using base64 over the wire
15:59 est31_ thats quite hard for sha1.
16:00 sfan5 it's not like TCP uses any kind of text encoding
16:00 est31_ I think the current solution was a hack
16:01 est31_ there is a certain list of allowed chars for passwords
16:01 sfan5 and?
16:01 est31_ and a maximum length
16:01 sapier sfan5 historical reasons ;-)
16:01 est31_ ^
16:01 sfan5 whats so bad about a list of allowed chars and a max length?
16:02 sfan5 nobody is going to type a 500 char password
16:02 sfan5 (copy pasting basically doesn't actually work anywhere)
16:02 sapier nothing but changing the encoding is a no go ;-)
16:02 est31_ "password" means the older version of the code, which stayed same on server side.
16:02 est31_ and the old version was "the client sends the password in plain text to the server"
16:03 est31_ so "password"= hash in this case
16:03 est31_ :)
16:03 sapier well I'd prefere to only change the encoding/login mechanism if it's done correct this time ;-)
16:03 sapier another interim encoding is crap
16:03 sfan5 ideally minetest would encode it as utf-8 instead of converting it to ascii
16:03 sfan5 anyway
16:04 sfan5 est31_: what kind of challenge-response protocol do you want to use?
16:04 sapier ideal :-) true but we're not living in an ideal world ;-)
16:04 sfan5 sapier: thats not an argument for not correcting it
16:04 sapier if you're breaking all exisiting versions it is ;-)
16:05 sfan5 umm
16:05 sfan5 you can't even use non-ascii chars is passwords
16:05 sapier if you can do it without breaking I'm fully with you
16:05 est31_ my idea would be that the client sends hash(hash(hash(pw||salt)||challenge)||servername) for login, while challenge is sent by the server
16:05 sfan5 >hash(hash(hash(
16:05 sfan5 my first thought: ಠ_ಠ
16:05 est31_ yea :P
16:06 est31_ its to prevent that challenge contains parts of the servername.
16:06 Zeno` anyway, the way to do it is to change line 1897 of main.cpp to password="upQa9QdxCJzB551UjVZlO3CpDV4";
16:06 est31_ there are other methods
16:06 Zeno` now, what server and username should I use?
16:06 sapier still I don't see how you get a servername for games without servername ;-)
16:06 est31_ but you would only save one "hash("
16:06 sapier e.g. local games
16:07 est31_ the server has to send it before.
16:07 sfan5 sapier: if minetest had allowed unicode passwords in the past it would be broken anyway because it is wide_to_narrow()'d before writing it to the packet
16:07 sfan5 Zeno`: username=cat ip=localhost port=30000
16:07 Zeno` :P
16:07 est31_ we can fall back to "localgame" or something like that
16:07 exio4 joined #minetest-dev
16:07 sapier wide .. narrow ... I'm getting headache on reading those words ;-)
16:08 n4x joined #minetest-dev
16:08 sapier well I sugges you write it down somewhere, keep in mind we need to have a way to keep old clients working
16:09 est31_ so ideally all pairs old client - new server and new client - old server...
16:09 sapier if that's not possible I suggest doing it right once and for all. Meaning not experiments but using a prooven challange response mechanism combined with encryption
16:09 est31_ I'll write a forum post
16:09 sfan5 est31_: how does the server verify that the hash is correct?
16:10 est31_ it stores hash(pw||salt) in the db
16:10 sfan5 sapier: if we plan to add encryption right with this it's not going to happen any soon
16:10 sfan5 lolwat
16:10 sfan5 est31_: you do realize that this doesn't solve a single problem
16:10 est31_ why
16:10 sfan5 someone could just modify the client to answer with hash(hash(hash_from_the_db​||challenge)||servername)
16:11 est31_ yeah, therefore the client choses the salt
16:11 est31_ and the client choses it randomly
16:11 est31_ (at creation)
16:11 est31_ so, the salt differs for each server, and they cant do anything about it
16:12 sfan5 um
16:12 sfan5 so the client needs to store the salt too?
16:12 shadowzone joined #minetest-dev
16:12 est31_ no
16:12 Selah joined #minetest-dev
16:12 est31_ hash_from_db is kinda secret
16:13 est31_ so evil servers wont know it
16:13 sfan5 not really
16:13 sfan5 hash_from_db is right in auth.txt
16:13 sfan5 that not what i would define as secret
16:13 est31_ secret from evil other servers
16:13 sapier https://github.com/minetest/minetest/pull/1985 I'm gonna merge this in a few minutes
16:13 sfan5 this would solve some of the problems
16:14 sfan5 but having the server store hash(a||b) and a is as secure as it is now
16:14 sfan5 sapier: do you have approval from a dev?
16:15 sfan5 (right now the server stores hash(user||pw) and user)
16:15 hmmmm horrible
16:15 sapier "Ignoring the major flaws with the system, these changes seem good in principle." reads like an agreement
16:15 hmmmm we should use a zero-knowledge authentication protocol such as SRP
16:15 est31_ the "kid wiresharks password of its brother from wlan" attack is only partially mitigated
16:15 exio4 joined #minetest-dev
16:15 est31_ it still allows active attacks
16:15 hmmmm what if a trusted minetest server gets compromised
16:16 sfan5 sapier: this is not written down anywhere, but agreements have always been done on irc
16:16 hmmmm in fact, without certificates, you don't even have the concept of server trust
16:16 est31_ that however can only be solved by encryption
16:16 sapier in this case anyone against merging a patch only affecting android by improving it's startup time by factor 10?
16:16 hmmmm yes
16:16 sfan5 lol
16:16 hmmmm sapier, you don't really need approval anymore
16:17 hmmmm we were talking about processes here https://forum.minetest.net/v​iewtopic.php?f=3&t=10849
16:17 sfan5 <est31_> the "kid wiresharks password of its brother from wlan" attack is only partially mitigated
16:17 sfan5 why only partially?
16:17 hmmmm because they can replay the hash you send
16:17 hmmmm the protocol is so amatuerish
16:17 sfan5 the server sends a different challange
16:18 hmmmm ?
16:18 sfan5 <est31_> my idea would be that the client sends hash(hash(hash(pw||salt)||challenge)||servername)
16:18 hmmmm the server should send a salt and the client should generate a salt too
16:18 hmmmm hash(user + hash(pw) + salt + client_token + server_token)
16:19 sfan5 having all of that decided by the client (pw, salt, challange) or static (servername) would be a bad idea
16:19 hmmmm client_token() can be a randomly generated string and transmitted along with the auth packet, server_token is the same format and could be sent in the first server->client packet
16:19 est31_ hmmm: not a good idea
16:19 hmmmm why
16:19 est31_ the server needs to know hash(pw)
16:19 hmmmm it'll store that
16:19 est31_ yes
16:20 hmmmm i realize there is a mitm attack on account creation
16:20 hmmmm this is unavoidable unless we do something like SRP
16:20 sfan5 you want the server to store hash(password)
16:20 sfan5 without salting?
16:20 hmmmm hash(password + salt) i mean
16:20 hmmmm i wrote hash(pw) + salt
16:20 hmmmm didn't mean that
16:21 sfan5 you mean hash(user + hash(pw + salt) + client_token + server_token)?
16:21 hmmmm yeah
16:21 est31_ you should still add servername
16:21 sfan5 why?
16:21 hmmmm wouldn't that function the same as salt
16:22 est31_ imagine client logging in to a malicious server that relays login to third server it targets
16:22 sfan5 who decides the salt?
16:22 sfan5 is it dynamic?
16:22 est31_ salt should be decided by client
16:23 est31_ yes it is dynamic
16:23 sapier https://github.com/minetest/minetest/pull/1578 anyone against merging this one? (after rebasing and removing the line shadow suggested)
16:24 hmmmm nah good stuff
16:24 Zeno` sapier, nope. I would have rebased it myself a few weeks ago but I was lazy ;)
16:24 hmmmm the problem I have with the client deciding the salt is that it effectively becomes another portion of the password
16:24 hmmmm does it not? :/
16:25 est31_ no the client doesn't need to store it
16:25 est31_ and the user doesnt need to remember
16:25 hmmmm true but
16:25 hmmmm why doesn't the server generate the salt
16:26 est31_ because otherwise that attack still works: client logging in to a malicious server that relays login to third server it targets
16:26 sfan5 sapier: can you remove the lines that store the wgettext output just to make 1 function call?
16:26 sfan5 hmmmm: the server could generate an empty salt
16:26 MinerDad joined #minetest-dev
16:26 hmmmm the client could too
16:26 sfan5 solution: client & server both generate part of salt
16:26 est31_ its never in the interest of the client
16:26 hmmmm erm wait a minute
16:26 sfan5 wait
16:26 sapier what exactly do you mean?
16:26 sfan5 that doesn't help
16:27 sfan5 with some of the problems
16:27 hmmmm the client needs to generate the salt otherwise it'd have to send the plain password hash over the wire
16:27 sapier for what I know we need to do this in order to prevent memory leaks
16:27 est31_ hmmm: thats another problem
16:27 est31_ but true also
16:27 sfan5 sapier: then you added new memory leaks
16:27 sfan5 hmmmm: why?
16:27 Calinou joined #minetest-dev
16:28 hmmmm right
16:28 sapier sfan5 what exactly are you talking about? ;-)
16:28 hmmmm that way you could aggravate rainbow table attacks
16:28 est31_ ^
16:28 hmmmm but you're still just as vulnerable if somebody mitms your connection on account creation
16:28 sfan5 sapier: you say https://github.com/minetest/minetest/pull/1578/f​iles#diff-18513665750ef5adf42b5ec29e14162eR1190 (and the next line) is needed to prevent mem leaks
16:28 sfan5 sapier: but you do it differently here: https://github.com/minetest/minetest/pull/1578/f​iles#diff-34f48ad91ac6c202ac60b0348ae90e30R2662
16:29 Zeno` I think MITM is the least concern
16:29 hmmmm guys, if we include libgmp we can implement SRP which is much better
16:29 est31_ agree to Zeno
16:29 Calinou does it work on Windows and OS X?
16:29 hmmmm right now, having to send basically the password over the wire at any time is bad stuff
16:29 hmmmm alternatively we can implement encryption
16:29 sfan5 Calinou: no, libgmp only works on stallmann-approved systems
16:29 sfan5 Calinou pls
16:29 hmmmm BS
16:30 sapier grrr thanks to the one adding the "showOverlayMessage" function especally as that name is quite non telling ... my names are bad I know but at least they tell what a function does
16:30 hmmmm it's distributed under LGPL v3
16:30 Calinou heh
16:30 Zeno` sapier, I did that I think
16:30 hmmmm soo guys
16:30 hmmmm what is it
16:30 hmmmm encrypted authentication, or passwordless protocol
16:30 sfan5 who decides the salt now?
16:31 Zeno` sapier, at least it's an actual function now :P
16:31 sapier Zeno a little bit more telling function names next time please ;-)
16:31 hmmmm or a slightly stronger password scheme
16:31 Zeno` sapier, in hindsight I agree
16:31 sapier zeno yes having a function is a good thing indeed ;-)
16:31 Calinou we could have a “remember password” setting, that'd incitate people to use stronger passwords
16:32 MinerDad joined #minetest-dev
16:32 sfan5 not really
16:32 Calinou (should be per-server, to not incitate people to use the same password on all servers)
16:32 sfan5 have you seen any person that uses stronger passwords just because their browser remembers them?
16:32 hmmmm or we could not use passwords
16:32 hmmmm certificates are better
16:32 est31_ sfan5 when I look into the mirror
16:33 hmmmm how often do people play minetest on other computers from the same account, seriously
16:33 Calinou are certificates portable?
16:33 Calinou people may play on one server using several PCs
16:33 hmmmm like... platforms?
16:33 est31_ yes
16:33 Calinou they maybe don't want to walk around with USB drives
16:33 est31_ thats the problem
16:33 hmmmm password auth can be an option
16:33 hmmmm maybe not the default
16:34 est31_ mozilla tied basically that with sync
16:34 est31_ then they realized people didnt like it
16:34 hmmmm the year is now two thousand and fifteen in the year of our lord
16:34 hmmmm and you're STILL using password-based auth
16:34 est31_ then they made everything based on the password
16:34 hmmmm whdftfuck
16:34 hmmmm come on guys
16:35 est31_ I know lots of people I respect (computer literate!) who use password based ssh auth.
16:35 Calinou Mumble uses certificates since a while now
16:35 sfan5 hmmmm: explaining users that they need to backup this file is way harder and bound to fail than telling them to remember this string+
16:35 sfan5 s/+//
16:35 Calinou it hasn't been a problem, because certificates are only useful for authentication, which is optional to use it (ie. you can still talk and hear others if you're not authenticated)
16:35 sfan5 especially since most people don't care to backup anything
16:36 est31_ you could try to add U2F
16:36 hmmmm well the whole reason why I bring this up is because that's effectively what you're doing by adding a password management feature and encouraging them to use stronger passwords
16:36 est31_ U2F rules
16:36 sfan5 certificates would be the perfect auth. solution
16:36 sapier well hmmmm eye scans as well as fingerprints have prooven to not work for security critical things
16:36 sfan5 but it doesn't "scale" well with normal people
16:36 Calinou I agree, I would be OK with certificates, but probably as an option for now
16:36 sfan5 (yes, I'm aware scale is the wrong verb)
16:36 Calinou good for admin accounts
16:36 hmmmm 2FA is nice
16:37 hmmmm but this is going too deep
16:37 sfan5 ^
16:37 hmmmm it's just a god damn video game
16:37 est31_ u2f can be also used as only factor
16:37 Calinou it's a video game, but an admin account could do a lot of things potentially
16:37 Calinou (however, properly configured servers should not let them edit files…)
16:37 est31_ thats why you should do  backups
16:37 Calinou but a bad server could let them do this
16:38 sfan5 can we please go back to discussing how we can solve the problem of auth. being horribly insecure and bad?
16:38 hmmmm the changes I perscribed would work pretty well
16:38 est31_ ok its SRP vs challenge-response
16:39 sfan5 est31_: it depends on what challange-response protocol?
16:39 hmmmm challenge-response would be perfect if the connection were secure
16:39 sfan5 <Zeno`> I think MITM is the least concern
16:39 hmmmm do we want to use OpenSSL?
16:39 est31_ I'd agree to the challenge-response-protocol hmmm suggested if "+" is implemented properly
16:39 Megaf Hi everyone, wouldn't it be cool using this? https://en.wikipedia.org/wiki/Gobby
16:39 hmmmm ???
16:40 hmmmm est31_:  concatenation isn't implemented properly?
16:40 sfan5 the stuff he have come up with until now is insecure if either the server or the client is malicious
16:41 est31_ ok sorry in this scenario concat even looks safe
16:41 hmmmm I mean like
16:41 hmmmm SHA512_Update(password)
16:41 est31_ if your client is malicious then you are owned anyway
16:41 hmmmm SHA512_Update(salt)
16:41 hmmmm SHA512_Final()
16:42 est31_ yea its safe
16:42 sfan5 how about hash(username + hash(password + client_salt + server_salt) + client_token + server_token)
16:42 sapier sfan5 you're right I really added memory leaks in that commit
16:42 sapier fixing it
16:42 hmmmm adding a server salt is worthless
16:42 sfan5 est31_: I'm talking about another client being malicious (right now e.g. sending a hardocded password hash)
16:42 sfan5 hmmmm: because?
16:42 hmmmm you'd need to transmit that over the wire before the client creates that primary hash in creating the new account
16:43 sfan5 hm
16:43 sfan5 the client using an empty salt is the client's fault and does not hurt anyone
16:43 sfan5 yep, server_salt is worthless
16:43 hmmmm the client's salt should probably be randomly generated
16:44 est31_ sfan5: ah ok for me its covered by "third party server"
16:44 sfan5 it only hurts the person with the broken client when their salt is not random
16:44 est31_ ^
16:44 hmmmm we'll implement a secure random function for the cases where /dev/random isn't available
16:44 est31_ server salt and client token are worthless in my opinion
16:44 hmmmm really.
16:44 est31_ and you need servername
16:44 hmmmm why
16:45 est31_ so that the client doesnt have to store the salt
16:45 sfan5 new proposal: hash(username + hash(password + client_salt) + client_token + server_token); server stores hash(password + client_salt); hash is something secure like sha2-*, or sha3-*
16:45 sfan5 est31_: why is the client_token worthless?
16:45 Hunterz joined #minetest-dev
16:46 hmmmm probably because it doesn't necessarily add any apparent enthropy to the hash
16:46 hmmmm erm, wrong word choice
16:46 est31_ hmmm: otherwise a bad server can make a relayed login to a targeted server
16:46 sfan5 well.. if the server generates an empty token there would be a problem
16:46 est31_ it only needs to pass on the salt
16:47 hmmmm oh yeah
16:47 hmmmm if this were a malicious server you already have the username salting that hash
16:47 hmmmm so let's say you create the account on the real server
16:48 est31_ oh havent thought of empty token
16:48 hmmmm the malicious server comes along and figures it's going to steal your plaintext hash
16:48 hmmmm erm
16:48 hmmmm so it creates a non-random servertoken
16:48 est31_ but the hash always incorporates the length
16:49 est31_ (when its finalized)
16:49 hmmmm but because the username is there it'll never be able to extract the hash
16:49 hmmmm or will it
16:49 sfan5 without username and client_token it would be hash(hash(password + client_salt)) anyway
16:49 hmmmm right
16:49 sapier https://github.com/minetest/minetest/pull/1578 merging the rebased version now
16:49 est31_ yes
16:50 hmmmm alright, so client token, server token, username, hash of the salted pw
16:50 est31_ servername please too
16:50 hmmmm and then if we add the server name, let's see
16:50 sfan5 why?
16:50 sfan5 sapier: don't you need to delete[] text instead of delete textK?
16:50 sfan5 s/K//
16:51 sfan5 est31_: the server name does not help with anything
16:51 sapier hmm compiler doesn't complain but you could be right about it
16:51 hmmmm est31_:  do you mean the server name in place of the client salt?
16:51 sfan5 hmmmm: i think est31_ menas additionally
16:51 sfan5 means*
16:51 hmmmm add it where though
16:51 est31_ yes additionally
16:51 sfan5 in the outer hash, probably
16:51 hmmmm add it to the salted pw hash or to the entire digest
16:51 est31_ the client salt is stored server side right?
16:51 hmmmm what will that help with
16:51 sfan5 est31_: yes
16:52 est31_ add it to the entire digest
16:52 hmmmm hrm
16:52 sfan5 hash(username + hash(password + client_salt) + client_token + server_token + server_name)
16:52 sfan5 what exactly does this solve?
16:52 est31_ imagine a malicious server acting as client for a targeted server
16:52 sapier wtf .. delete[] doesn't cause a compile error ?! :-)
16:52 est31_ it gets client_salt, server_token
16:52 est31_ relays it to the real client
16:53 Krock sfan5, it solves all minetest login problemswhen the server name/IP changes
16:53 hmmmm so the malicious server MITMs
16:53 est31_ it relays client_token to the real server
16:53 sapier other way round :-)
16:53 est31_ and the hash is also relaye
16:53 sfan5 est31_: wot
16:53 est31_ d
16:53 sfan5 est31_: when Zeno` said MITM was not a concern you said you agreed to him
16:53 hmmmm wait
16:53 sfan5 now you are talking about how mitm is problem
16:53 est31_ MITM without access to the wire
16:53 sfan5 it's basically the same
16:53 est31_ the client wants to connect to the malicious server not to the targeted one
16:53 hmmmm you can still have the same problem if you were to create the account on this compromised server
16:54 est31_ and uses same password ;)
16:54 sfan5 right
16:54 hmmmm also this can be bypassed by compromising the DNS
16:54 hmmmm this is totally screwed, just use srp
16:54 sfan5 this is completely insecure
16:55 Krock sapier, why do you delete text 3 times? https://github.com/sapier/minetest/commit/4408​2f8#diff-34f48ad91ac6c202ac60b0348ae90e30R2726
16:55 est31_ hmmmm that (DNS) was what zeno meant I guess
16:55 sfan5 est31_: 1) what prevent the malicious server from using a different server_name? 2) it doesn't matter anyway when the malicious server can get hash(password + client_salt)
16:55 sfan5 est31_: I'm pretty sure Zeno` meant real MITM
16:55 Krock oh nvm. it's a pointer
16:55 sfan5 not DNs hijacking
16:55 est31_ dns hijack is real MITM
16:55 sfan5 no
16:56 sfan5 dns hijacking is intransparent mitm
16:56 sfan5 on-the-wire mitm is transparent
16:56 hmmmm so i don't get it
16:56 est31_ 1) the user sees server_name in the GUI 2) it doesnt get it because client_salt is randomly chosen
16:56 hmmmm are you saying that minetest servers can't have different IPs?
16:56 sapier dynamic dns?
16:56 est31_ server_name is not its url
16:57 est31_ its e.g. "VanessaE creative server"
16:57 Krock you can change the server_name on the servers minetest.conf ..
16:57 sfan5 est31_: 2) oh, right 1) we can have 2 servers with the same name on the server list
16:58 sfan5 inb4 this is problem with the server lsit
16:58 sfan5 list*
16:58 est31_ 1) yes then there is a problem. then the only way to solve this is to require PKI or server side passwords for the list so that the names are unique
16:59 sfan5 challange-response only solves auth. it doesn't solve any kind of mitm
16:59 est31_ yes. only encryption does that
16:59 sfan5 incorrect
16:59 sfan5 only encryption with auth. does that
16:59 est31_ ?
16:59 hmmmm zero-knowledge verification solves mitm :)
17:00 sfan5 blindly encrypting stuff doesn't solve this
17:00 hmmmm and yea encryption is worthless without knowing who you're sending encrypted stuff to
17:00 hmmmm exchanging keys with rather
17:00 est31_ ^
17:00 hmmmm so who wants to pony up the $100 for a VeriSign certificate for each minetest server
17:01 Zeno` I meant MITM without access to the wire (for the record) ;)
17:01 hmmmm nobody?
17:01 hmmmm I see my case for SRP has been made
17:01 sfan5 who said we want to solve mitm?
17:01 hmmmm because it's horribly insecure if you don't solve mitm
17:01 * est31_ doesn't know SRP good enough to make suggestions
17:02 Zeno` sfan5, not me. I don't think it should be a major concern right now.
17:02 Zeno` because ANYTHING is better than what is present right now ;)
17:02 sfan5 hmmmm: this? http://en.wikipedia.org/wiki/S​ecure_Remote_Password_protocol
17:02 est31_ Zeno`, right
17:02 sfan5 Zeno`: correct
17:02 hmmmm sfan5, yea
17:03 sfan5 the challange-response protocol we "drafted" solves the passive replay case
17:04 est31_ challenge-response solves all replay, as the server_token changes
17:04 sapier Zeno implementing a incompatible broken mechanism we'd have to change again would be worse then present
17:04 est31_ incompatible??
17:04 sapier breaking old clients but not getting a more secure login
17:04 Calinou <+hmmmm> so who wants to pony up the $100 for a VeriSign certificate for each minetest server
17:05 est31_ ah
17:05 Calinou we can use our own certificates?
17:05 sfan5 sapier: it's not incompatible
17:05 est31_ Calinou, yes
17:05 Calinou which will be approved by the game
17:05 sapier I was answering to "ANYTHING is better" ... which ain't true ;-)
17:07 est31_ we can use SRP, but we shouldn't naively implement it
17:07 est31_ so for example, server_name needs to be included
17:08 Zeno` sapier, all I was suggesting is that MITM is probably the least concern to worry about
17:09 Zeno` heck, most https:// sites are open to MITM (not saying it's good)
17:09 est31_ MITM without access to the wire is easy as I've said
17:09 Calinou MITM is rarely used in practice
17:10 Calinou especially in a game
17:10 est31_ Zeno` ??
17:10 Zeno` est31_, exactly
17:11 Zeno` est31_, if I am one of the endpoints then MITM is trivial. If I have access to the wire it is trivial. Personally I don't think it should be a major concern
17:11 hmmmm http://www.propublica.org/d​ocuments/item/889134-games
17:11 Zeno` not for a game like minetest anyway :/
17:12 est31_ yes MITM with wire access shouldn't be a major concern
17:12 Zeno` What I am more concerned about is the "rogue server"
17:13 est31_ ^
17:13 sapier why do you guys ignore the most common attack scenario for professionals ?
17:13 Zeno` e.g. if I wanted to I could look at my server's auth.txt and probably login as most users on most other servers
17:13 est31_ ^
17:13 Zeno` sapier, because there is no reason for a professional to try and login as a minetest user?
17:14 est31_ thats something very heavy, while professionals can find a tiny 0day in irrlicht and we are pwned
17:14 sapier the most easy way to prevent yout passwords to be abused by an evil server is to use different passwords for each server
17:14 Zeno` sapier, I do. Most users do not
17:15 sapier anything we can do failes due to not beeing able to authenticate a server
17:15 shadowzone joined #minetest-dev
17:15 est31_ therefore the server_name
17:16 est31_ the user verifies this themselves
17:16 est31_ so we are abled
17:16 sapier and what should stop a evil server from claiming to have that servername?
17:17 sapier serverlist updates are not authenticated so that evil server could even be distibuted by serverlist
17:17 hmmmm stop with the half assed approach
17:17 Zeno` I've never really liked the evil tools... they seem to wear out too fast
17:17 hmmmm we either do it the right way or no way at all
17:17 hmmmm this means no challenge based response
17:17 sapier I'm completly with hmmmm either do it right or don't do it at all
17:17 hmmmm unless it's encrypted
17:18 hmmmm and don't bother with encryption unless you have verification
17:18 sapier so server certificates as well as a minetest cert
17:18 sapier minetest cert could ensure no server name is used twice thus provide at least a low level of integrity
17:19 est31_ minetest cert??
17:19 Zeno` stop with the DRM!
17:19 sapier it's not drm
17:19 hmmmm personally, though, improving security isn't a priority for me.  it's been laughably horrible the entire time and very few seem to care, it's never actually been exploited, and ffs it's just a game
17:19 Zeno` it basically is
17:19 sapier you can still specify another ca
17:19 est31_ just make a "server password" where the server authenticates to the list
17:19 hmmmm all my passwords are some variation of 'asdf'
17:20 hmmmm or abcd
17:20 hmmmm nobody takes minetest serious enough to use a real password
17:20 sapier funny thing hmmmm :-)
17:20 leat joined #minetest-dev
17:20 est31_ I've been taken over on Clip public server
17:20 sapier me too
17:20 Krock interesting idea, such a "minetest cert" but it requires more wok than it gives an use
17:20 sapier krock all of this is more of work then use
17:20 Calinou can a mod set up a password policy?
17:20 hmmmm right
17:20 Calinou or should this be done in the engine?
17:20 Calinou minimal length or such
17:20 est31_ password policies are worthless
17:21 Krock passwords should be dome serverside
17:21 est31_ dont start with things like those
17:21 Krock *done
17:21 sapier if you want to go without minetest cert you could make client accept a cert at first login and warn if it's changed
17:21 hmmmm I can shoot the shit about authentication, and if somebody agrees to add libgmp I could throw in my homegrown tiny, good implementation of srp
17:21 sapier not sure if users know how to check a cert for the first time
17:21 hmmmm but I'm not willing to put in more effort beyond that
17:22 est31_ I agree to srp when the "password" is hash(hash(pw|| salt)|| server_name)
17:22 Zeno` first a cert for mods and now a cert for servers?
17:22 Zeno` where will it end?
17:22 hmmmm Security is our top concern!
17:22 Zeno` I am very opposed to certs
17:22 hmmmm haha
17:23 Zeno` *sigh*
17:23 hmmmm I do have concern for remote code execution on clients though
17:24 Zeno` yes, so that should never happen
17:24 hmmmm right
17:24 hmmmm there are lots of people running javascript from websites every day
17:24 hmmmm why should this be any different
17:24 sapier zeno certificates are the only known mechanism to verify integrity ... but still they're flawed by design
17:24 est31_ and its non-free!!!
17:24 est31_ :)
17:25 est31_ js from websites is sandboxed
17:25 hmmmm so the lua would be sandboxed too
17:25 hmmmm client-side lua
17:25 est31_ yeah, so lets hope the sandbox is good
17:25 sapier hmmmm browsers used to sandbox that code ... yet current development with full hardware access and cloud storage does render that task quite useless ... what's left to protect if all sensible information is accessible from within sandbox
17:25 hmmmm the concern is that lua or luajit might be way more vulnerable than your typical js interpreter implementations
17:26 hmmmm hmm
17:26 est31_ ... because less money has been spent making it secure
17:26 est31_ the topic was auth
17:26 hmmmm you shouldn't be able to do anything aside from DoS with gpu access
17:27 sapier hmmm what about reading framebuffer content to get information not meant for you?
17:27 hmmmm i thought that was solved with WebGL
17:27 sapier well until someone finds a bug ;-)
17:27 est31_ WebGL is one of the best attempts to solve it I guess
17:28 est31_ idk whether its goot
17:28 hmmmm it's the best we got
17:28 T4im if you don't use it though, you are better off deactivating it ;)
17:29 hmmmm i planned on adding some lower level APIs like client.draw_triangle_strip()
17:29 sapier true but if best is still broken isn't it better not to use it? ;-)
17:29 hmmmm client.draw_hud(), client.draw_text(), client.blit_texture_to_screen()
17:29 hmmmm what else..
17:29 sapier well ... I know I'm not telling a majority capable opinion :)
17:29 Calinou drawing triangles/boxes on HUD could be useful
17:30 Krock client.disconnect()
17:30 est31_ "please log in to windows"
17:30 hmmmm yeah basically
17:30 hmmmm i'm gonna have to reimplement the entrity of cairo or WinGDI
17:31 hmmmm if minetest didn't have modding it would be like twice as small as it was right now, and everything would be very well polished
17:31 Krock everything would be totally boring
17:32 est31_ ^
17:32 twoelk joined #minetest-dev
17:32 Krock except you add 1000 different nodes and items like minetest-classic
17:32 Krock *voxelands
17:32 hmmmm yeah
17:32 hmmmm you know
17:33 hmmmm minetest seems sub-par to all the other MC-clones
17:33 hmmmm but in reality that's because most of the development effort is going toward extensibility
17:34 cib0 joined #minetest-dev
17:34 Calinou implementing extensibility is always rewarding in the long term
17:34 Calinou so do it, instead of polishing something that'll die quickly
17:34 crazyR joined #minetest-dev
17:34 hmmmm haha check this out https://github.com/minetest/minetest/issues/2037
17:35 hmmmm so it appears that people are putting spaces in their mod names
17:36 sapier :-)
17:36 Krock trololo
17:36 hmmmm that's not a bad idea or anything...... naaaaaaaaaaw
17:36 hmmmm should we disallow special characters in mod names or escape them?
17:36 sapier isn't a space just a normal character ? ;-)
17:37 est31_ just like 💩 is
17:38 Calinou disallow
17:38 hmmmm ironically you're able to use the latter
17:38 Calinou mod names are technical anyway
17:38 Calinou ideally in mod configure, description.txt should be used to show full name
17:38 Calinou eg. More Blocks [moreblocks] instead of just moreblocks
17:40 hmmmm anybody else?
17:42 Krock the idea is good but the [moreblocks] part must be added automatically
17:43 sapier any change there should be checked against dependency as well as mod enabling disabling code
17:44 Calinou Krock, yes, it would, like in subgames
17:45 est31_ spaces are bad, as you can have one or two or many, and there are bad fonts which make spaces very thin
17:55 MinerDad joined #minetest-dev
17:55 rubenwardy joined #minetest-dev
17:56 prozacgod joined #minetest-dev
18:05 est31_ so what do you think, should server_name be included?
18:08 DuDraig joined #minetest-dev
18:11 est31_ I still like it. It doesn't protect from server A claiming to be server B, but when the user wants to log in to server A, they never have to fear that server A in fact relays the login to server B.
18:13 sapier why not? server a could claim to be server b and still relay communication
18:13 sfan5 we can't add server_name because there is no standard definition of server_name
18:14 sfan5 this also breaks connecting to IPs or hostnames
18:14 sfan5 which is not something we need to discuss
18:14 sfan5 (we won't remove support for direct connections)
18:17 est31_ sapier that isn't met, you're right. That I think should be fixed elsewhere, like adding passwords or certs for servers. It is however better than storing the salt, which is vulnerable to typo changes, which can be fixed when the list is maintained by a human
18:18 sapier sfan5's issues are valid too how do you intend to fix them?
18:18 est31_ sfan5 no with server_name I don't mean ip or hostname or something like that, but the actual thing displayed in the GUI, like "VanessaE creative server"
18:18 sfan5 est31_: what if you want to connect to a server that is not on the server list?
18:19 sapier we don't show lan servers in serverlist
18:19 sapier as we don't have lan autodiscovery
18:19 sfan5 so basically we use the old vulnerable process for connecting to on IP or addr.
18:20 est31_ then you enter ip and port, and get to a dialog "Connect to 'VanessaE creative server'?" and only when you press yes the credentials are sent. We have to send server_name during connection buildup of course
18:20 sapier you don't get that dialog
18:20 sapier server doesn't tell it's name to client
18:20 est31_ it needs to be written
18:20 est31_ it needs to be made to tell
18:21 sapier it's a change in login mechanism, most likely incompatible
18:21 sfan5 est31_: what are you going to do if i connect to a server that is not on the list
18:21 sfan5 sapier: actually that change is backwards-compatible
18:21 sapier if you make server send an additional message ?
18:21 est31_ sapier isn't it already?
18:21 est31_ sfan5, see above.
18:22 sapier sfan5 only if we can add it to an existing message
18:22 sfan5 est31_: server_name is not a required setting
18:22 sfan5 sapier: TOCLIENT_INIT?
18:22 sapier could work
18:22 sapier and how is client supposed to behave if that field is missing?
18:23 sapier if it just ignores it it's worth nothing, if it failes you couldn't connect to old servers
18:23 sfan5 sapier: the server name would only be required by the challenge-response auth thing anyway, it could be added to the new packet
18:23 sapier hmm a warning could be a solution ... ugly
18:23 est31_ we can assume '' then and the server owner has to live with the problem
18:23 sapier I thought we did agree on doing it right or not at all?
18:24 sapier I'm against implementing another home brew broken mechanism
18:24 sfan5 est31_: the server_name being empty is a potential security problem for all clients, not the server owner
18:24 est31_ show me how a well-established mechanism handles distrusting the server
18:25 sfan5 est31_: requiring servers to have a name is stupid
18:25 est31_ sfan5, yes
18:25 sapier https with client and server certificate authentication
18:25 est31_ sfan5, yes
18:26 est31_ sapier, we had that: its hard to convince people to backup a file
18:26 sapier your server name is basically just a broken certificate
18:26 sfan5 sapier: 1) who pays for the server certs? 2) most people don't care enough to backup anything
18:26 est31_ the server name is human-readable
18:26 sapier it's worth about nothing as you can't trust it
18:26 sfan5 sapier: est31_'s idea is that the server name is retrieved from the server list
18:27 est31_ and the server authenticates to the list via some mechanism
18:27 sapier sfan5 if client stores a servers certificate it could at least be used to verify to connect to same server again
18:27 est31_ be it cert or password
18:27 sapier and our serverlist is more secure?
18:27 est31_ or nothing
18:27 sapier everyone can add a fake name
18:28 sfan5 sapier: correct
18:29 sfan5 est31_: the problem with the server_name mechanism is that there are servers not on the server list and that server names are not meant to be used for security purposes (not unique, easily spoofable)
18:29 sapier imho if we want to get better (not perfect) integrity the minimum we'd have to support is self signed certificates with a well tested certificate exchange mechanism
18:30 est31_ cert exchange isn't the problem here I think, as when you first-time login to a server you usually have nothing, and people start to get interested in you when you have something
18:32 sfan5 "a well tested certificate exchange mechanism"
18:32 sfan5 wat
18:32 sfan5 i think socket.write(ceritficate.serialize("x509")) is well-tested
18:32 MinerDad joined #minetest-dev
18:32 sapier nope
18:33 sfan5 >used by TLS >nope not well tested
18:33 sapier what I meant is you have to make sure certificates are not modified in transit ... meaning
18:33 sapier you need an encrypted connection prior exchanging certificates
18:33 sfan5 what are you trying to solve
18:33 sapier to make sure the one sending the certificate is the one you connected to
18:34 sfan5 you absolutely cannot solve mitm without some kind of signature that is verifyable before you connect
18:34 sapier nope
18:34 sapier it's a two level connection
18:34 sfan5 please tell me how
18:34 est31_ signature or other mechanisms also only create a name<->cert hash mapping
18:34 sapier first a encrypted connection is established between two hosts
18:34 sfan5 cut!
18:35 sfan5 you can mitm at this point
18:35 sfan5 game over
18:35 sfan5 try again?
18:35 sapier nope
18:35 sapier because right now no identity is verified
18:35 sfan5 yeah
18:35 sfan5 this means you can mitm
18:35 sapier no
18:35 sfan5 yes
18:35 sapier you can't because this is only the envelope
18:35 sfan5 why is mitm not possible?
18:36 sapier because this connection is between two hosts
18:36 sfan5 heard of active mitm?
18:36 sapier you'r not done yet ;-)
18:36 sfan5 ???
18:37 sapier uppon this connection certificates are exchanged end to end
18:37 sapier yoru mitm doesn't have the certificate
18:37 sapier so at this point it's gonna be detected
18:37 est31_ at the end we still need some sort of auth for the list
18:37 sfan5 uh
18:37 sfan5 I'm talking about MITM not someone redirects your traffic
18:38 sapier still a mitm doesn't have the remote private key
18:38 sfan5 correct
18:38 sfan5 what if the mitm generates his own cert and keys?
18:38 sapier so no mitm can decrypt that information
18:38 sfan5 incorrect
18:38 sapier doesn't help after initial cert exchange
18:38 sfan5 wat
18:38 sfan5 what if the mitm generates his own cert and keys?
18:38 sfan5 (before the cert exchange ofc)
18:39 sapier well we're talking about different things sfan5
18:39 sfan5 what are you talking about then?
18:39 sapier I'm only talking about a connection once client already knows correct certificate
18:40 sfan5 it's obvious that already knowing the cert would solve this
18:40 sfan5 sapier: why do you want to encrypt certificate exchange?
18:41 sapier to protect that information
18:41 sapier see ipsec
18:41 sfan5 why protect the certificates
18:41 sfan5 TLS doesn't protect them either
18:42 sapier are you sure about that? ;-)
18:42 sfan5 very sure
18:43 sapier even if it's true tls is usually used for webservers which is serving information to public
18:43 sapier so anyone could connect and get the cert
18:43 sfan5 <sapier> so anyone could connect and get the cert
18:43 sfan5 oh, is this not true for minetest servers?
18:43 sapier hmm ok ok I got it
18:44 sapier still how do you wanna proove integrity of communication if you send them unencrypted/unsigned
18:45 sapier at least signing of that data is required
18:45 sfan5 the certificated are unsigned
18:46 sfan5 if you do trust-after-first-sight the client just knows that those are the right ones
18:46 sfan5 <sfan5> the certificated are unsigned -> the certificates are signed by CAs
18:46 sfan5 sapier: https://cdn.mediacru.sh/8/89SfUIoQQUfz.png << here's a TLS handshake
18:46 sapier certificates are always signed, at worst self signed
18:47 sfan5 you know what i mean
18:47 sapier what I'm talking about is making sure pakets from server are not modified till received by client
18:47 sfan5 encryption does not help with that
18:47 sapier partial
18:48 sfan5 not even partial
18:48 sapier if you make sure keys to do decryption are only known to sender and receiver noone else can send valid messages
18:48 sfan5 correct
18:48 sapier you'd have to add some sort of checksum or signature to detect invalid messages of course
18:48 sfan5 but you need to exchange the keys over an untrusted communcation channel
18:49 sapier which is a already solved task ;-)
18:49 sfan5 yes
18:49 sfan5 diffie-hellmann can be mitm'd
18:49 sfan5 any encryption without authenticating the server<->client connection is pointless
18:49 sfan5 because it can simply be reversed by an active mitm
18:50 sapier see ipsec ike it's working quite fine
18:50 est31_ what should the certs be mapped to?
18:50 est31_ to the url? the "server_name"?
18:50 sfan5 sapier: IPSec works with certs too
18:50 sapier certs and diffie hellman
18:50 sfan5 i don't know if they encrypt the cert exchange
18:50 sfan5 if they do that is stupud
18:50 sapier using a two level connection mechanism
18:50 sfan5 stupid*
18:51 sapier of course ipsec is stupid because it's used almost everywhere ;-)
18:51 sapier ppl beeing way more experienced then both of us did design and validate that way of doing encryption sfan5 ;-)
18:51 sfan5 sapier: can you provide a link to some convincing document that says ipsec encrypts the exchange of certs
18:52 Calinou encryption without auth is better than nothing
18:52 sfan5 Calinou: correct
18:52 Calinou signing is mostly done to make lobbies happy (-:
18:52 sfan5 Calinou: incorrect
18:52 Calinou it's a business
18:52 sfan5 against sophisticated attackers encryption without auth is worthless
18:52 est31_ Calinou, yes its a business but its existence has a reason
18:52 sfan5 Calinou: we are not even talking about PKI with CAs
18:53 sfan5 Calinou: you were not even talking about PKI with CAs, just about authentication
18:53 sapier sfan5 not right now as I have to leave but I'd point you to ipsec rfc's guess you'll find it till I have time to send it to you
18:53 sapier left #minetest-dev
18:55 sfan5 pff
18:56 sfan5 i think I'm going to do that next time
18:56 sfan5 1) make a claim
18:56 sfan5 2) rtfm and prove the opposite or believe me
18:57 sfan5 also knowing that encryption is pointless without auth against active mitm does not require studying security
18:57 est31_ can you provide me with some background? a cert consists of more than just a keypair. what do you suggest to be the "name" that it maps to
18:58 sfan5 est31_: the hostname or ip
18:58 sfan5 or something else
18:58 sfan5 it would be easier to just have the server have a keypair
18:58 sfan5 and the client do trust-on-first-use
18:58 est31_ and then the client selects the server by clicking the hostname?
18:59 est31_ (or ip)
18:59 sfan5 uh no
18:59 est31_ so they select the server_name?
18:59 sfan5 no
19:00 sfan5 we can't add this
19:00 sfan5 it doesn't work with existing things
19:01 rubenwardy Why would you need certification and signing? You're not transacting bank details.
19:02 Calinou rubenwardy, you rarely transact bank details on GitHub or reddit either ;)
19:02 rubenwardy That's for keeping your code secure
19:02 rubenwardy and reddit can waste money
19:02 rubenwardy Also, passwords
19:03 Calinou passwords are considered less and less secure as time go on; people often choose stupid ones
19:13 est31_ Calinou, I agree, although "passwords are dead" is quite hyped
19:14 est31_ and people tend to prefer it the password way
19:14 est31_ other solutions would be eg to store a key on the computer
19:15 est31_ but most ppl dont like that
19:15 Calinou that's basically using self-signed certificates like Mumble does
19:15 Calinou it starts being a problem when you use several devices
19:15 Calinou especially mobile ones
19:15 est31_ ^
19:19 est31_ I think the project google does with U2F is quite cool as it gives people a solution which is connected to the physical world, giving a "key" experience.
19:19 Megaf Hi all
19:20 Megaf any word on my connected glass issue?
19:20 Megaf ^ Calinou
19:26 sfan5 maybe someone cares, here's mildly-secure-challenge-response-v1.txt: http://sprunge.us/CMdH
19:32 ImQ009 joined #minetest-dev
19:38 cib0 joined #minetest-dev
20:03 ImQ009 joined #minetest-dev
20:12 casimir joined #minetest-dev
20:21 roniz joined #minetest-dev
21:24 UnknownSentinel joined #minetest-dev
21:34 kaeza joined #minetest-dev
21:39 cib_ joined #minetest-dev
21:40 ImQ009 joined #minetest-dev
21:57 hmmmm ah shoot
21:57 hmmmm I almost forgot
21:57 hmmmm laying in bed last night i thought about alternative lighting algorithms.. basically it comes down to two:
21:58 hmmmm 1).  expand !! the size of param2 to 16 or possibly 24 bits
21:58 hmmmm when spreading light, always increase the light amount
21:58 hmmmm have the actual lighting value be log(param2) * some factor
21:59 hmmmm the benefit to this is that unspreading light is trivial, all you'd need to do is spread to each node as if you were lighting except subtract the light contribution amount from each param2
22:00 hmmmm the huge benefit to this is that you can have light spread farther than 15 nodes
22:00 hmmmm unspreadLight also becomes much faster because it's conceptually easier to calculate
22:01 hmmmm 2).  calculate light only while making meshes
22:02 hmmmm this removes the need for param2 entirely, and allows RGB light
22:02 hmmmm the disadvantage is that you can never have light spread greater than the size of a mapblock
22:02 hmmmm and, of course, when you're making the mapblock mesh you'd need to have all mapblock neighbors loaded as well
22:02 nore that's an important problem...
22:03 Wayward_One i like that idea
22:03 nore about option 1, if you make > 15 nodes radius, won't update_light be slow?
22:03 hmmmm update_light is always slow.
22:03 nore I mean, very slow
22:04 nore if you need to update (2*20)^3 nodes when placing a torch, it's a lot
22:04 hmmmm it probably shouldn't be too bad since the current implementation can be optimized
22:04 nore indeed
22:04 hmmmm it's the implementation that's slow, since unspreadLight needs to keep a set of light sources
22:04 hmmmm when I optimized lighting for map generation, I was able to remove that since spreading light doesn't require that
22:05 nore btw, one thing I wanted to do about lighting if ever it is reworked: change day/night into artificial/sunlight
22:05 nore that makes half as much work when updating
22:05 hmmmm yeah, not only that, but I personally find the entire concept of having separate day/night lightbanks to be useless
22:05 nore and you can get the raw sunlight value (useful to know whether a node is outside, etc)
22:06 hmmmm in reality you never use light other than full on during daytime and full off (or full on) during nighttime
22:07 nore what do you mean, full on/off?
22:08 hmmmm so that could be an intermediate #3). remove the concept of day/night banks and have a range of 8 bits for light which means you can spread light much more than currently, but nowhere nearly as much as with #1)
22:08 ancer joined #minetest-dev
22:08 hmmmm I'm sure there are mods that actually make use of having a range in each day and night lightbank
22:08 hmmmm but in general the way nodes work are:  either they're a light source and stay lit regardless of day or night
22:08 hmmmm or they're not a light source and their light is 0 at night
22:08 nore ah, yes
22:09 hmmmm (or whatever it was from the spread of a light source)
22:09 nore btw, why did you say that unspreadLight would be faster with 1?
22:09 hmmmm because it would be
22:10 hmmmm you wouldn't need to keep track of light sources this way
22:10 nore yep, but why?
22:10 hmmmm currently that's how it works
22:10 hmmmm the idea is to find all the light sources in the path of where the light you're unlighting spread to
22:10 hmmmm and then find where that spread
22:11 nore I mean: why wouldn't you need to find those lights with 1?
22:11 hmmmm here there's no bookkeeping, just plain subtraction of values from a predetermined path of light bounding
22:11 hmmmm ^
22:11 hmmmm s/bounding/bouncing
22:11 nore yep, but there can be overflows then
22:11 hmmmm the range of the param2 should be high enough so there can't be
22:11 hmmmm that is a problem that can't really be solved
22:12 nore btw, sqrt would be more realistic that log2
22:12 hmmmm *shrug* i don't know.  i haven't tried it, it's just an idea
22:12 hmmmm either way
22:13 hmmmm there is a real need for having a greater range of light
22:13 nore didn't try it either, but it seems to me that physics would say that
22:13 nore anyway, need to try
22:13 nore but it looks like a promising idea
22:13 hmmmm also another minor improvement: torches should be 3d so that you're able to see them lit when not near a wall
22:15 Calinou 3D torches is possible using meshnodes or nodeboxes
22:15 Calinou no particles or animation
22:15 Calinou (although animation on nodebox is possible)
22:16 hmmmm annendum to method #2:  we don't absolutely need to have the entire mapblock loaded, but simply their light contribution at the mapblock edge
22:16 hmmmm that may or may not be a plausible thing to track
22:19 hmmmm 16*6 bytes
22:19 hmmmm 16*6*3 for RGB lights
22:26 hmmmm how do other more 'graphically advanced' block games do it?
22:27 Ritchie joined #minetest-dev
22:29 Calinou hardware lighting?
22:29 UnknownSentinel Maybe you can look at terasology, it's the only other open source block game I know.
22:29 hmmmm dynamic lights are a no-go.  irrlicht says they're limited to 8 per scene
22:29 hmmmm i don' know if i am able to run terasology :)
22:30 UnknownSentinel haha :)
22:30 Calinou #terasology
22:30 exio4 I don't think any computer can run terasology with a playable FPS
22:30 Calinou ask there
22:30 Calinou I can, exio4 ;)
22:30 exio4 but you can run it easily
22:31 exio4 Calinou, which settings?
22:31 UnknownSentinel Terasology runs better than minecraft with shaders thougH :/
22:31 Wayward_One you also might consider manic digger
22:31 Calinou fairly low ones
22:31 exio4 the lowest-low settings were kind of decent here too
22:31 Wayward_One irc.esper.net, #manicdigger
22:31 exio4 20~ FPS with lowest stuff, but it was blob and what not
22:37 hmmmm can't run terasology
22:38 hmmmm http://fpaste.org/165113/42023828/
22:39 exio4 psh, that happens when you don't use a systemd-powered system like fedora 20!
22:40 Wayward_One Manic Digger runs pretty well on my laptop, much better than Terasology
22:40 hmmmm i thought java ran on anything!
22:42 hmmmm in any case check this terasology screenshot out: http://blog.movingblocks.net/wp-content/uploa​ds/Bildschirmfoto-2011-06-07-um-21.16.04.png
22:42 hmmmm is this a really old terasology version?
22:42 hmmmm regardless, it demonstrates that we won't find our answer here
22:47 hmmmm this is awesome
22:47 hmmmm i need an Oracle Account to download a freaking JDK
22:50 kahrl really? doesn't seem to be the case when I go to http://www.oracle.com/technetwork/java/jav​ase/downloads/jdk8-downloads-2133151.html
22:51 hmmmm i need a very specific version
22:51 hmmmm hehe i got it from a non-oracle website
22:57 hmmmm we won't find the answer from manic digger either:  http://mdgallery.strangebutfunny.net/uplo​ads/b245b97ef29f503c5503be6676cb6c13.png    http://mdgallery.strangebutfunny.net/uplo​ads/be6488917a62dc602e988c0cdd7e2a79.png
22:57 hmmmm it seems like state-of-the-art block games cannot into alternative light source algorithms
23:04 Wayward_One joined #minetest-dev
23:32 hmmmm holy crap
23:33 hmmmm terasology is even slower than anybody could imagine
23:33 hmmmm they compress their equivalents of MapBlocks in memory
23:33 hmmmm a MapBlock is split up into separate arrays for content, sunlight, light, etc.
23:34 hmmmm sunlight is only white, while 'light' is RGB
23:52 Wayward_One joined #minetest-dev
23:52 cib0 joined #minetest-dev

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