Time  Nick            Message
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)
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:28 paramat         thats cool
02:34 paramat         hmmmmm https://forum.minetest.net/viewtopic.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:54 paramat         next i'll be using a periodic function for grad above ground to create multiple levels
03:14 Zeno`           https://github.com/minetest/minetest/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
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: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
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: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: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: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
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: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: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: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: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
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 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 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 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:05 Zeno`           So https://github.com/minetest/minetest/commit/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 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: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 est31_          sapier: was that directed to me?
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: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 sapier          wide .. narrow ... I'm getting headache on reading those words ;-)
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 est31_          no
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 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/viewtopic.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 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: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/files#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/files#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 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: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/44082f8#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/Secure_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/documents/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 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 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 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 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 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
18:05 est31_          so what do you think, should server_name be included?
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 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: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
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 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: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/uploads/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/javase/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/uploads/b245b97ef29f503c5503be6676cb6c13.png    http://mdgallery.strangebutfunny.net/uploads/be6488917a62dc602e988c0cdd7e2a79.png
22:57 hmmmm           it seems like state-of-the-art block games cannot into alternative light source algorithms
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