Time Nick Message 00:03 TBC_x est31: I'm refactoring ClientInterface but I need to know when are the SRP packets supposed to be handled 00:04 TBC_x I want to move all the handshake stuff out of RemoteClient 00:04 est31 well, they are at init time. 00:04 TBC_x only at Init? 00:04 est31 and afterwards too 00:05 est31 there are three occasions we can have authentication packets floating around 00:05 est31 1. for init, the usual login 00:05 est31 2. to authenticate for sudo mode 00:05 est31 3. to change the password once inside sudo mode 00:05 est31 3. is only one auth mech for now 00:06 est31 but 2. and 1. are multiple mechs. 00:06 TBC_x I want to move at least the init stuff out 00:06 est31 to where 00:06 TBC_x to Server 00:06 TBC_x atm 00:07 est31 which handshake do you mean? 00:07 TBC_x the init handshake, including client state 00:07 est31 the whole client state? 00:08 est31 whats left in clientiface if you take that away? 00:08 TBC_x the client and its blocks 00:09 TBC_x I don't like accessing the client directly 00:09 TBC_x so I want to hide as much as possible behind the client interface 00:09 est31 so why do you remove stuff from it then? 00:10 TBC_x well... only the stuff that is required for init 00:10 est31 the states are much more than just init. 00:10 TBC_x I'm trying to remove all getClient() methods 00:10 est31 so why are the states obstructing you with that? 00:12 est31 also, why do you think is a file with 3428 lines a better place in your mind? 00:13 TBC_x my goal is to hide RemoteClients behind ClientInterface 00:13 TBC_x and I was not sure whether the srp is needed for the entire session 00:14 TBC_x if it was not, I could move auth out of RemoteClients 00:15 est31 we need it not just for init. 00:16 est31 also, auth data is in the clientiface, no? 00:16 est31 err sorry 00:16 est31 its in remoteclients. 00:16 est31 an abstraction layer which handles all auth would be very good though. 00:16 TBC_x yes 00:17 est31 so if you design it, you should keep in mind, that srp is needed at all those three occasions 00:17 TBC_x current problem is that emergethread may access client when packet handlers have reference to it but not lock 00:17 TBC_x therefore data race 00:18 est31 what's it the business of emergethrea 00:18 est31 d 00:18 TBC_x setBlocksNotSent 00:18 est31 why can't it just have a queue, of outstanding mapblocks to be delivered? 00:19 TBC_x probably someone's optimization? 00:19 TBC_x this is my clientiface.h right now http://sprunge.us/aTAP 00:20 TBC_x I removed all getClient() methods 00:20 est31 perhaps a diff would be better 00:20 TBC_x ok 00:21 TBC_x http://sprunge.us/ODRP 00:21 est31 grr #2885 uses getClient extensively 00:21 ShadowBot https://github.com/minetest/minetest/issues/2885 -- Utf8 based chat by est31 00:22 TBC_x I wrapped some scattered member variables into logical structures 00:22 TBC_x but I need to break HandshakeInfo struct 00:24 est31 eh, why so much Handshake*Info structs 00:24 est31 new struct for just two variables? 00:25 TBC_x this is not final 00:26 est31 also, c++ has constructors 00:26 TBC_x I know 00:26 est31 we dont need createEmpty 00:27 est31 bad descision that rust has no constructors. 00:27 TBC_x rust has default trait 00:28 TBC_x that works like default constructor 00:28 TBC_x i was definitely doing premature optimizations around createEmpty() 00:29 est31 VersionInfo is even good I think 00:29 TBC_x yes 00:29 est31 it should be perhaps used at more places 00:30 est31 perhaps even defined by version.h 00:30 est31 finally something version.h can be used for 00:30 est31 right now it only lives for version.cpp 00:35 TBC_x now tell me, what in HandshakeInfo should not be moved out of RemoteClient? 00:35 TBC_x I wanted to move all of that out 00:37 TBC_x replaced createEmpty with constructors 00:37 est31 I don't think we need separate handshakeinfo and clientnetinfo 00:37 est31 or even separate from clientinfo 00:38 TBC_x I want to minimize packet handlers touching RemoteClient 00:39 TBC_x when some of the stuff is used only once, It could be allocated somewhere else 00:39 est31 we can put that all into clientinfo 00:40 est31 the problem is, right now I know of no criterion why these things live in separate structs 00:40 est31 you should be abled to give a clear criterion why something should be in one struct, something else in another 00:41 est31 otherwise you perhaps should merge them. 00:41 est31 because you cant define a clear line 00:41 est31 "its needed by packet handlers" thats a clear line 00:41 est31 vs "its hidden behind some clientiface logic" 00:42 TBC_x When I was first separating the clientinfo and friends I was thinking that a initialization handler could do its thing and then initialize RemoteClient with those structs 00:42 TBC_x I mean, initialize RemoteClient when the init phase finishes 00:43 hmmmm [07:48 PM] why an assert now? 00:43 hmmmm i dunn, we have to do something 00:43 TBC_x so the final step would pass the initialized data to RemoteClient constructor 00:43 hmmmm didn't realize it was a pointer at first so yeah i agree it needs to be checked, but i don't think it should persist in a release build 00:44 est31 My comment was more along "compare it with NULL not with 0" 00:44 est31 not "make an assert" 00:45 TBC_x I wanted all the members in HandshakeInfo move away from RemoteClient 00:45 est31 the problem is I think that channel is somehow settable by the client 00:45 est31 or the other peer 00:45 est31 to be neutral 00:45 est31 TBC_x, nothing wrong with that 00:45 hmmmm the channel is selectable by an 8 bit ID number 00:45 hmmmm in the highest protocol layer 00:46 est31 but why did you split it up this far TBC_x? One struct to separate with is enough, no? 00:47 est31 otherwise you just keep around hundreds of pointers an have to remember each of the Info and NetInfo objects and what they contain 00:47 est31 and its unmaintainable too, imagine if something new comes around 00:47 est31 which doesnt fit into the "design" it has been built after 00:47 TBC_x This is not final design 00:47 est31 then all has to be destroyed 00:47 hmmmm yea there's no way the channel pointer can be manipulated by the client into being NULL 00:47 est31 so better to not overengineer something 00:48 TBC_x and I value your input 00:48 est31 hmmmm, there is no way? 00:48 hmmmm nope 00:48 est31 there is a comparison connection != 0 just before the method is called 00:48 est31 so that can be removed, you say? 00:49 hmmmm it could be 00:49 est31 ok. 00:49 est31 then its ok 00:49 hmmmm see the main problem is that these checks are mostly pedantic 00:49 hmmmm they're really not necessary and it would only make sense to explicitly check them if they were intended to be part of a public interface for use by multiple things outside of connection.cpp 00:50 hmmmm and what's more is that they're completely inconsistent 00:50 TBC_x est31, also http://sprunge.us/XNQB 00:50 est31 we don't use channels that much, agreed 00:50 hmmmm there's so much sanity checking on specific functions, even checking the value of a variable right after an if statement returns if it's equal to something 00:50 hmmmm generally connection.cpp is a mess 00:51 TBC_x I think this way it is more readable 00:51 est31 TBC_x, what's the point in adding the ? thing here 00:51 hmmmm i would not recommend adding a sanity_check() whatever if there's some convoluted logic involved with that code where such a condition could conceivably arise 00:51 est31 should that be added to every boolean expression 00:51 hmmmm TBC_x, that is incredibly repetitive 00:51 est31 for (int i = 0; (i < 10) ? true : false; i++) 00:51 hmmmm i don't think it's more readable anyway 00:52 hmmmm yeah really :p 00:52 TBC_x at least to assignments 00:53 est31 ok, then my concerns with the connection.cpp change are gone, +1 00:53 est31 now about the lua error handler commit 00:53 TBC_x more informative messages are good 00:54 est31 have you seen my comment about that you pass the function name pointer through two methods, even if there is no error? 00:54 hmmmm it's meant to give us a better clue about what's happening with those two crashes with no stacktraces 00:54 hmmmm est, yeah 00:55 hmmmm so what? 00:55 est31 first its a repurpose, so the methods should be at least renamed, second its needless jumps and complexity. 00:56 est31 if you want to understand the code, you'll have to travel first to the macro then to the first method, then the second, then only you see the if about the return value 00:56 hmmmm alright, point made 01:03 est31 otherwise +1 to the error msg commit as well. 01:06 est31 ~tell nrzkt can you make test android builds, and perhaps try to find out whether #2973 is because of device, or because of build setup? If its build setup we dont have to patch around. if its device based, we will have to disable iconv usage, this should be cleared now, before the release. 01:06 ShadowBot est31: O.K. 01:07 est31 ~tell nrzkt best to upload them somewhere, so that wayward1 and H-H-H can test it on their devices (they both report the bug, both from self built apks) 01:07 ShadowBot est31: O.K. 01:13 hmmmm est31, did you see the thing about nerzhul's performance optimization 01:14 est31 yes, its for after the release 01:14 est31 imo 01:14 hmmmm good 01:14 hmmmm agreed 01:14 est31 this is why we freeze 02:12 est31 twoelk|2, http://irc.minetest.ru/minetest-dev/2015-08-04#i_4350608 02:12 est31 its how srp has been designed 02:12 est31 it works together with the old password scheme, but new passwords are set as srp verifiers 02:13 est31 so if you log in to a new server the first time, or you change your password with a new client, you will get a srp key in the db, and no hash that would be compatible with old versions 02:13 est31 however, you can ask an admin to set your password 02:16 est31 /setpassword still sets old style hashes, even if all parties are connected with new clients 02:18 twoelk|2 it seems one tries to connect with an old valid password and the server rejects. wether the server is new I cannot say but the password is usually old 02:20 twoelk|2 http://irc.minetest.ru/minetest/2015-08-05#i_4352539 02:20 est31 The server has to be new (0.4.12-dev) in order to support srp. 02:22 est31 If you have a reproducible bug, it would be interesting. 02:22 est31 I mean, it would be an issue 02:22 twoelk|2 https://forum.minetest.net/viewtopic.php?p=186041#p186041 and simmilar 02:23 est31 I'm more with ABJ's theory here. 02:23 twoelk|2 http://irc.minetest.ru/minetest/2015-08-05#i_4352315 and here 02:25 twoelk|2 so many password problems is just a bit unusuall 02:25 est31 hrmm, yes 02:25 est31 AAAAAAAAAAAAAAAAAAAAAA <---- thats too much A's 02:25 est31 A's are bad, this is supposed to be the sale 02:25 est31 salt* 02:26 twoelk|2 I think there was similar talk on inchra but I don't think they have logs 02:26 est31 the only place srp changed during the last weeks was a leak fix 02:27 est31 and that other thing, with the default passwords 02:37 est31 damn, since when do we have this salt bug 02:52 est31 I see now how the salt bug happens 03:03 est31 hmmmm, can you review https://github.com/est31/minetest/commit/e91af8036c7c9a957628e5977f04e20fa3fc25fa 03:04 est31 analogous to https://github.com/est31/csrp-gmp/commit/44c909e6b4059ee644031c6b8bb95717d2a6ef12 03:04 est31 its that AAAAA issue 03:05 est31 twoelk, I have made a bugfix patch for srp now, but it was only an unrelated bug I've found, I haven't found the case for aerth's reported problem yet 03:12 VanessaE btw is anyone else getting crashes in the client when the server shuts down? 03:13 est31 lets test it 03:13 est31 whats your test port again? 03:13 VanessaE 30007 I think 03:38 hmmmm est31: yes looks good I suppose 03:39 est31 I tested it, and it works, so I gonna push it 03:39 hmmmm i assume init_random() initializes using the system random generator or at least uses the system random generator as a seed? 03:39 est31 yes 03:40 est31 the system random generator is even used as only source, if available 03:40 hmmmm erm, doesn't this mean that the SRP implementation up until now was insecure? 03:40 est31 there is nothing wrong or slow about /dev/urandom 03:40 est31 only under certain conditions 03:40 est31 the random generator was already initialized for the actual login 03:41 hmmmm mmmmmm 03:41 est31 just if you logged in for a server for the first time, and this was your first contact with a srp server during the execution period of your client, then yes, you have a vulnerable database hash 03:41 hmmmm as for the irc mod - no idea there 03:41 est31 well, its unsalted 03:41 hmmmm i'd have to look into it better to have a well formed opinion 03:43 est31 and that bad db hash stays with you, as long as you dont change your password 03:43 est31 the only vulnerability here is that the server can build rainbow tables, if the server is evil 03:54 hmmmm https://github.com/kwolekr/minetest/commit/2c508f76541065fa017610edfa4edd0739b1ff39 03:54 hmmmm PTAL 04:02 est31 looks good 04:02 hmmmm did you make sure that everything matches up 04:03 hmmmm i looked at it too, but with such repetitive code it's easy to make a typo mistake 04:03 est31 I'll read through it again 04:09 est31 ok 04:09 est31 +1 04:11 hmmmm done 04:11 hmmmm that takes care of all the known security exploits for this dev version i think 04:12 hmmmm now just to take care of the remaining race conditions/crashes 04:29 hmmmm est31: https://github.com/minetest/minetest/pull/3013 04:32 est31 nice 04:32 est31 there is no reason to get this in before the release though, we dont even use it yet 04:32 hmmmm well this doesn't change any functionality 04:32 hmmmm it's just a good thing to have 04:32 hmmmm i actually did this a while ago, never made a pull request for it though 05:19 VanessaE hmmmm, est31: I'm headed off to bed now. bd0b469d is staged for the 6am reboot. safe to use that? 05:19 est31 VanessaE, I hope so :) 05:19 VanessaE "hope" heh 05:20 VanessaE well I guess if it ain't, I'll know in about 8 hours, and know who to yell at ;) 05:21 VanessaE nightg 05:22 hmmmm wait 05:22 hmmmm update to bd0b469 05:23 est31 ? 05:23 est31 thats the one she cited, no? 05:23 hmmmm oh 05:33 hmmmm est: do you know if the android graphical glitches ever got fixed? 06:27 hmmmm pushing in 30 minutes: https://github.com/kwolekr/minetest/commit/8560ece02e36b1e0ee7b86db2a38b8becbb639e4 06:40 celeron55 lol, why is the warning in german too 06:40 celeron55 just to make sure sapier will notice it? 8) 06:40 hmmmm yeah basically 06:41 hmmmm but erm, for whatever reason, germans love minetest 06:41 hmmmm i'd have to estimate that half of our developers are/were german. 06:43 celeron55 nice work though 06:43 hmmmm tbc found it with Thread Sanitizer 06:43 celeron55 that could have ended up being not fixed for forever 06:43 hmmmm Thread Sanitizer is my new favorite thing ever :) 07:10 Miner_59 Hi, just want to remember to merge #2241 07:10 ShadowBot https://github.com/minetest/minetest/issues/2241 -- Fix for disable_jump group doesn't work on nodeboxes by gregorycu 07:11 hmmmm oh i'm sorry 07:12 hmmmm that other day when PRs were flying around I thought est31 merged yours 07:12 hmmmm I'll do that 07:12 hmmmm oh this is a different PR 07:12 Miner_59 cool thanks, but gregorycu wrote this PR not I 07:12 Miner_59 my PR is already merged :-) 07:13 hmmmm did your own bouncy jump fix get merged 07:13 hmmmm okay good 07:13 Miner_59 the bug is that minetest checks the block under the nodebox, so disable_jump dont work 07:14 Miner_59 nodebox=not a full block high nodebox 07:14 Miner_59 although damage_per_second seems to be affected 07:17 Miner_59 oh I saw its merged thanks! 07:30 est31 hmmmm, what about #1551 ? 07:30 ShadowBot https://github.com/minetest/minetest/issues/1551 -- disable_jump group doesn't work on nodeboxes 07:30 est31 isnt it fixed by #2241 ? 07:30 ShadowBot https://github.com/minetest/minetest/issues/2241 -- Fix for disable_jump group doesn't work on nodeboxes by gregorycu 07:31 hmmmm I think so 07:31 hmmmm I just didn't close that issue because I wasn't aware of it 07:31 hmmmm closing 1551 07:31 est31 ok 07:31 est31 np 07:33 est31 didn't know btw that you can't allocate dynamically sized arrays on the stack until c(+?+?)11 07:34 est31 I guess that makes writing a compiler harder, because you dont know until execution how much space on the stack a function will take. 07:35 est31 well, a bit harder 07:36 hmmmm well i'm not really sure about C++ 07:36 hmmmm but so-called "VLA"s came into C with C99 07:36 rubenwardy aren't arrays just pointers, so you can malloc the size you mean? 07:36 est31 not stack arrays 07:36 rubenwardy ok, nvm 07:36 est31 they are pointers too, but to the stack 07:37 hmmmm i'm pretty sure VLAs are usually implemented as officially sanctioned, inline-safe versions of _alloca() 07:37 est31 and on the stack, there is no malloc 07:37 est31 you declare it, you allocate it 07:37 est31 out of scope, it gets deleted 07:37 hmmmm Stack? What is this 'stack' thing you speak of? :) 07:38 hmmmm that's called a variable with the "auto" storage specifier. 07:39 hmmmm C/C++ has absolutely no notion of "heap" and "stack" btw 07:39 hmmmm that's all implementation dependent 07:39 est31 good to know 07:42 hmmmm est: 3014 looks good to me. 07:46 est31 ouch alloca isnt inline safe 07:47 est31 thats a pretty bad system call 07:47 est31 "it might work, but only if your compiler is in the mood" 07:56 rubenwardy lol, sizeof(u16) 07:56 est31 hrmm, on one hand 3014 is a feature, which shouldn't be merged during freeze, on the other hand it would actually benefit server owners with the irc commands mod who have srp problems. 07:57 rubenwardy #3014 07:57 ShadowBot https://github.com/minetest/minetest/issues/3014 -- Add LuaSecureRandom by est31 07:57 est31 also, nothing much can break, if its merged, you can just not use it. 07:58 rubenwardy Are floats always 4 bytes on all devices? https://github.com/kwolekr/minetest/commit/2c508f76541065fa017610edfa4edd0739b1ff39#diff-ca07aa642678d1d0c23dd61b842741f7L264 07:59 est31 yes 07:59 est31 I mean no 08:00 est31 but we serialize them always as 4 bytes 08:00 est31 thats precisely why its bad to have sizeof(float) for serialisation considerations 08:04 est31 perhaps I merge it after lotsa tests 08:04 est31 finally something I can use mtt for! 08:05 est31 the main argument here would be that its a completely new feature which is totally isolated, and therefore can't break anything existing. 08:08 rubenwardy #2094 08:08 ShadowBot https://github.com/minetest/minetest/issues/2094 -- Fix offset being ignored by inventory bar HUD by rubenwardy 09:53 paramat sfan5 any comments on game#607 ? including the extra stuff i propose in comments, i think spores need a clearer name 09:53 ShadowBot https://github.com/minetest/minetest_game/issues/607 -- Biomes: Improve biome system and v6 mushroom spawning WIP by paramat 14:30 RealBadAngel https://imgrush.com/BgJ5_VrYDNgh.png 14:30 RealBadAngel i just made swimming pool on Skyblock server :) 14:32 sfan5 are those lots of tiny skyblock islands? 14:48 VanessaE sfan5: yep, they are 14:48 sfan5 sounds interesting 14:48 VanessaE nice-looking pool, RealBadAngel 14:48 RealBadAngel come see it 14:49 RealBadAngel theres teleporter next to your house 14:50 VanessaE impressive. where the hell did you get so much obsidian? 14:58 RealBadAngel recipes allow to get that as much as you want 14:58 RealBadAngel craft one shard + stone to get obsidian 14:58 RealBadAngel obsidian to 9 shards 14:58 RealBadAngel and you have shitload of it 15:16 VanessaE ok, official request for minetest-game et al. PLEASE go back to the old, darker junglewood color 15:16 VanessaE RealBadAngel: oh right, forgot about that recipe in skyblock 15:17 Amaz Yes, please can we have the old dark color junglewood back? 15:18 VanessaE this lighter color just plain suicks 15:18 VanessaE sucks* 15:20 kilbith the chocolate-y junglewood even worse 15:21 kilbith (ie. the old one) 15:21 VanessaE no, what's really worse is the old OLD wood texture (still used in "minimal" I think :) ) 15:21 kilbith for you maybe 15:22 VanessaE similarly, for YOU the "chocolate" junglewood is worse :) 15:24 kilbith no, for the _game maintainers that decided that 15:27 VanessaE ... 15:27 VanessaE [08-06 11:20] the chocolate-y junglewood even worse <--- pretty sure that's your opinion 15:28 kilbith ofc, but if it has been replaced it was for the same reason 15:28 kilbith well, stupid bikeshedding anyways 15:33 VanessaE actually the color of the texture affects general usefulness (think contrast relative to regular and pine woods), and directly affects at least one mod also (building_blocks creates "hardwood" from jungle wood + regular, and it's dark like junglewood used to be) 15:34 kilbith i agree that junglewood color should be more distinctive though 15:34 Amaz Was there actually a pull for that texture change? Or was it just discussed here? 15:43 VanessaE I think there was bug damned if I remember which 15:44 VanessaE er wtf?> 15:44 VanessaE that came out way wrong 15:44 VanessaE I think there was pull request, but damned if I remember which 15:44 VanessaE that's better :P 18:52 VanessaE has anyone fixed the problem with jungle tree and pine trunks replacing other nodes when they grow from a sapling? 18:53 VanessaE (the server I'm playing on has this problem, but I don't remember if that's since been fixed) 19:50 paramat VanessaE yes, it was mgv6 pine trunk replacing nodes, i have added a check for air or ignore 19:50 RealBadAngel accacia too 19:51 VanessaE paramat: jungle trees do it too. 19:51 RealBadAngel also default trees sometime do not replace saplings 19:52 RealBadAngel tree grows on top of a sapling 19:52 paramat v6 jungletree trunk and roots check for air or ignore 19:52 VanessaE paramat: either the jungle trees check is failing or stormchaser's server is doing something weird then 19:52 paramat i'm preparing a PR to not force-place the acacia root 19:53 RealBadAngel i saw accacia failing on singleplayer world 21:49 OldCoder /opt/minebest/src/core/server/minetest/src/server.cpp:505: 21:49 OldCoder void Server::step(float): A fatal error occurred: error in error handlin 21:49 OldCoder Um? 21:49 OldCoder WTH is error in error handling?