Time Nick Message 04:28 mtvisitor is it possible to change the minetest product development meeting from sunday to friday ? this is just my personal suggestion. 04:29 mtvisitor product quality and data pravicy is important. 04:30 mtvisitor it is also ideal status that we did not lose any data. 05:57 sfan5 #15087 ready for review but more importantly further testing 05:57 ShadowBot https://github.com/minetest/minetest/issues/15087 -- [no squash] Fix network window size logic by sfan5 08:17 MTDiscord Was there an issue opened already for error kick messages not wrapping? 11:50 MTDiscord merging #14557 in 1h 11:50 ShadowBot https://github.com/minetest/minetest/issues/14557 -- Add static glTF support by JosiahWI 11:53 Desour nice, so it's precisely 5d 12:28 MTDiscord (In reply to greenxenith) Not that I am aware of 12:50 MTDiscord done 🎉 13:53 [MatrxMT] Industry standard, niiiice! 13:53 MTDiscord yoo it's merged 13:54 MTDiscord i mean, its non animated, so obj is also industry standard. once animated is in, yeah - mt will support an industry standard animated format 13:59 sfan5 merging #15096, #15099, #15101, #15033 in 10m 13:59 ShadowBot https://github.com/minetest/minetest/issues/15096 -- Use std::string_view in logging code by sfan5 13:59 ShadowBot https://github.com/minetest/minetest/issues/15099 -- Reduce include count in headers by SmallJoker 13:59 ShadowBot https://github.com/minetest/minetest/issues/15101 -- Allow to disable transparency sorting entirely by Desour 13:59 ShadowBot https://github.com/minetest/minetest/issues/15033 -- Show full texture string in generateImage(): Failed to generate errors by Emojigit 14:12 MTDiscord marked #14685 as ready for review; it is at a manageable ~500 loc now that the static PR is merged. 14:12 ShadowBot https://github.com/minetest/minetest/issues/14685 -- Add animated glTF support by appgurueu 14:21 MTDiscord Hmm, changes to camera.cpp? Is this fixing a Minetest client bug? 🤔 14:22 MTDiscord Ah, it's a rename. 14:22 MTDiscord should probably make the PR [nosquash] 14:23 MTDiscord this one is https://github.com/minetest/minetest/pull/14685/commits/ca5311a313c28839be0fa00d889f6bf2676cf500 14:23 MTDiscord Good idea. You have some commits like "minify" that you could squash manually locally. 14:24 MTDiscord yeah i will rewrite history before merge 14:24 MTDiscord marked it "manual merge" 14:24 MTDiscord Manual merge is a thing? xD 14:24 MTDiscord tbh i'm not quite sure it is the correct term here 14:25 MTDiscord because i will just merge via rebase, but before that i will squash commits as is sensible 14:25 MTDiscord but if i just wrote nosquash others might assume that the commits are to be merged as-is 14:25 MTDiscord if i wasn't lazy i would eagerly rewrite history 14:26 MTDiscord Oh yes, this PR also contains a b3d fix haha. The no-inverse-matrix issue. 14:27 MTDiscord arguably that i will squash, since it was caused by changes made for animated gltf 14:37 Desour you could also use autosquash (see `git commit --fixup ` and `git rebase --autosquash `) 15:09 red-001 I thought github already supported autosquash in the UI? 15:11 Desour would be new to me. but I haven't tried merging a PR that has fixup commits left 15:12 red-001 I was probably just thinking of standard squashing 16:16 sfan5 Desour: have you considered PR'ing the tracy integration 16:17 sfan5 it looks very cool and useful 16:19 Desour I haven't considered, but could do 16:20 Desour is using FetchContent (only if the tracy compile flag is enabled of course) in cmake fine? 16:22 rubenwardy Distros generally don't like that but it's fine as it's a dev tool 17:26 red-001 cause it doesn't go through their own distro specific package repo? 17:26 Krock hmm interesting. The glTF PR alone managed to add 0.5 MB of code to the binary (gcc, without LTO) 17:27 red-001 not too surprising, it was a hefty PR 17:27 Desour red-001: AFAIK they don't like it because they'd need an internet connection to build the packages 17:28 Desour and they usually build packages in containers 17:29 Desour Krock: 0.5 MB of how much? 17:29 red-001 wonder if the server could convert all meshes to glTF once animation support is there. Trying to make sure one format parser written in C/C++ is secure is bad enough, much less maintaining all those old ones 17:30 red-001 <+Desour> K.r.o.c.k: 0.5 MB of how much?: 17:30 red-001 windows MSVC build outputs are 11 MB, I presume GCC on linux would be somewhere around that or a bit smaller 17:31 Desour it depends on your build options though 17:31 Krock Desour: previously 12.8 MiB, now 13.3 MiB. 17:31 Desour for example, my minetest binary is currently about 257 MiB big 17:32 Desour Krock: oh, so much 17:32 Krock I assume that's Rel with debug info? 17:32 Desour yes, and with tracy linked 17:32 Krock mine's a standard release build 17:39 red-001 I mostly switched over the network encryption PR to use HACL*, I did look for a dTLS 1.3 library but it genuinely seems like the wolfSSL is the *only* implementation that exists 17:41 red-001 made some progress on getting a formal description of the protocol in proverif, not sure if that would be considered good enough for showing the idea is sound 17:50 red-001 I would be happy to switch again to NACL or libsodium if needed 17:50 red-001 even if the formal verification is nice 17:50 Krock does cURL expose anything that we could make use of? 17:54 red-001 not reliably I don't think 17:54 red-001 sometimes it comes with openssl, but only sometimes 17:54 rubenwardy Are you basing your decisions off some standard / preexisting way of doing game encryption 17:54 rubenwardy Or just throwing together crypto 17:55 Krock for latter the crypro bros might have some ideas 17:56 Krock dTLS and QUIC seem to be viable options. except that achieving backwards compat would be somewhat difficult 17:59 red-001 it could be more standard admittedly, I tried to follow what TLS 1.3 does when it comes to design decisions, just with a lot less features. The choice of using AES-128-GCM with a 96-bit tag was based on the minimal specs for authentication encryption per NIST. 17:59 red-001 the ECDHE should be very similar to the TLS one 18:01 red-001 I did some questionable things with SRP to make it work, but I rolled back those changes and it should be more standard 18:01 Desour I don't have doubts that red-001's protocol is secure (and therefore I don't request a formal verification). but I have worries that we don't want to use a custom protocol. it's less about the crypto stuff and more about having a standardized protocol 18:02 Desour (just my opinion) 18:02 Desour standard dtls, and quic, for example, will not have issues working in other tools, like wireshark 18:03 Desour and we don't have to keep protocol doc and implementation around 18:04 red-001 Would you be okay with tabling that for whenever the protocol in general is replaced? Like I said there is no dtl1.3 implementation with a compatible license yet 18:08 Desour no dtls1.3 lib with a compatible license? I think I missed that 18:09 Desour gnutls seems to be LGPLv2.1+ 18:11 red-001 https://gitlab.com/gnutls/gnutls/-/issues/1019 18:11 red-001 !title 18:11 ShadowBot Add support for DTLS 1.3 (#1019) · Issues · gnutls / GnuTLS · GitLab 18:11 red-001 seems to just support dTLS 1.2 18:15 Desour oh, I see now. sorry! 18:19 red-001 I mean dTLS 1.2 is fine I suppose, I presume most of those protocol bugs have been worked around or fixed by now. Just need to configure a secure cipher suite since the default might be insecure 18:20 red-001 but it would really work better with a whole new protocol, as in from the very first packet to the very last packet, having everything sent via dTLS. 18:21 red-001 would probably want to use self-signed certificates and do the actual validation in a MT specific way 18:25 Desour I had suggested in the PR to use ecdh to get a key and use that one as fake pre shared key. but we could instead use a fixed fake psk, and leave the ecdh to dtls. that way, and if we knew the server and client are speaking dtls, every packet could be dtls (but the first ones would of course not be properly encrypted) 18:26 red-001 it's not a bad idea, I see your point about making it easier to use with wireshark, that's certainly a concern 18:28 red-001 I'm not sure just switching to DTLS is a good solution to that however. The issue with decrypting packets with a Lua script mostly comes down to A) having to load a library to do it, which doesn't seem too difficult and B) the seq_num being just the lower 16-bits of a 48-bit counter 18:29 red-001 dTLS would mean I guess including another sequence counter, could just include the extra 32-bits or even just 16-bits and not really have to worry about that anymore 18:31 red-001 surely no-one would send more than maybe 2^32 packets and if they do, then not much more 18:35 red-001 as for that SRP concern I had, it seems that at least gnuTLS supports an application getting the master key but only for tls 1.2 and lower 18:38 red-001 ah TLS 1.3 supports key exporters so can use those there 18:38 red-001 https://datatracker.ietf.org/doc/html/rfc5705 18:40 red-001 Desour, I will take a look at implementing this all with dTLS and gnuTLS in another branch, looks like there is a TLS extension for what I wanted 18:41 red-001 and at least gnuTLS implements it https://www.gnutls.org/reference/gnutls-gnutls.html#gnutls-prf-rfc5705 18:50 Desour I'm looking forward to it! ^^ (also, sorry for my half-informed criticism of your work btw., I have been more annoying than necessary. and it's awesome someone is working on this) 18:53 red-001 no worries, always good to get another perspective, that said I'm not sure what the general sentiment will be around pulling in all of gnuTLS, it's a larger library and all 18:53 red-001 I still suspect it might be better to pair that with a general network rewrite 18:54 Desour can't we use the library from the package manager? 18:54 Desour (same for the crypto lib. I saw your PR added 90k lines) 18:57 Desour vcpkg and brew have gnutls. and in linux it's also common, afaik 19:01 sfan5 thanks to Krock for actually testing the performance of my PR 19:02 Krock sfan5: tbh I didn't expect much of a difference and was somewhat surprised to see such difference between the builds 19:02 Krock the older binary was slightly outdated, thus recompiled with a clean master to have an apples-to-apples comparison. well done. 19:05 red-001 <+Desour> can't we use the library from the package manager? 19:05 red-001 Probably can, could have cut down on the amount of HACL* code pulled in too, but wasn't sure that was worth it. Editing a third party library and all. 19:05 red-001 OpenSSL could be included from a package manager too, but still need to ship it for the Windows and Android builds 19:37 sfan5 merging #15076, #15075, #15106 in 10m 19:37 ShadowBot https://github.com/minetest/minetest/issues/15076 -- [no squash] Ability to handle vertex and index VBOs separately by sfan5 19:37 ShadowBot https://github.com/minetest/minetest/issues/15075 -- Windows/vcpkg instructions: enable i18n by default by Zughy 19:37 ShadowBot https://github.com/minetest/minetest/issues/15106 -- Simplify `TOSERVER_INIT` and `TOCLIENT_HELLO` by red-001 23:05 MTDiscord I pushed a new commit to #15062, hopefully this time explaining the behavior more clearly 23:05 ShadowBot https://github.com/minetest/minetest/issues/15062 -- Document negative saturation by nauta-turbidus