Time |
Nick |
Message |
00:29 |
|
SFENCE joined #minetest-dev |
00:52 |
|
Lupercus joined #minetest-dev |
01:07 |
|
SFENCE joined #minetest-dev |
01:32 |
|
SFENCE joined #minetest-dev |
01:50 |
|
SFENCE joined #minetest-dev |
01:55 |
|
v-rob joined #minetest-dev |
02:08 |
|
SFENCE joined #minetest-dev |
02:10 |
|
v-rob joined #minetest-dev |
02:19 |
|
v-rob joined #minetest-dev |
02:32 |
|
SFENCE joined #minetest-dev |
02:33 |
|
SFENCE joined #minetest-dev |
03:10 |
|
SpaceManiac joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
04:18 |
|
SFENCE joined #minetest-dev |
04:21 |
|
cranez joined #minetest-dev |
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. |
04:37 |
|
SFENCE joined #minetest-dev |
04:39 |
|
SFENCE joined #minetest-dev |
04:54 |
|
v-rob joined #minetest-dev |
05:10 |
|
SFENCE joined #minetest-dev |
05:52 |
|
luk3yx joined #minetest-dev |
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 |
<greenxenith> Was there an issue opened already for error kick messages not wrapping? |
10:26 |
|
Desour joined #minetest-dev |
11:50 |
MTDiscord |
<luatic> 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:10 |
|
Lupercus joined #minetest-dev |
12:28 |
MTDiscord |
<wsor4035> (In reply to greenxenith) Not that I am aware of |
12:50 |
MTDiscord |
<luatic> done 🎉 |
13:13 |
|
Desour joined #minetest-dev |
13:42 |
|
SFENCE joined #minetest-dev |
13:53 |
[MatrxMT] |
<Zughy> Industry standard, niiiice! |
13:53 |
|
SFENCE joined #minetest-dev |
13:53 |
MTDiscord |
<rollerozxa> yoo it's merged |
13:54 |
MTDiscord |
<wsor4035> 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:57 |
|
SFENCE joined #minetest-dev |
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:05 |
|
SFENCE joined #minetest-dev |
14:09 |
|
SFENCE joined #minetest-dev |
14:12 |
MTDiscord |
<luatic> 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:15 |
|
SFENCE joined #minetest-dev |
14:21 |
|
SFENCE joined #minetest-dev |
14:21 |
MTDiscord |
<josiah_wi> Hmm, changes to camera.cpp? Is this fixing a Minetest client bug? 🤔 |
14:22 |
MTDiscord |
<josiah_wi> Ah, it's a rename. |
14:22 |
MTDiscord |
<luatic> should probably make the PR [nosquash] |
14:23 |
MTDiscord |
<luatic> this one is https://github.com/minetest/minetest/pull/14685/commits/ca5311a313c28839be0fa00d889f6bf2676cf500 |
14:23 |
MTDiscord |
<josiah_wi> Good idea. You have some commits like "minify" that you could squash manually locally. |
14:24 |
MTDiscord |
<luatic> yeah i will rewrite history before merge |
14:24 |
MTDiscord |
<luatic> marked it "manual merge" |
14:24 |
|
SFENCE joined #minetest-dev |
14:24 |
MTDiscord |
<josiah_wi> Manual merge is a thing? xD |
14:24 |
MTDiscord |
<luatic> tbh i'm not quite sure it is the correct term here |
14:25 |
MTDiscord |
<luatic> because i will just merge via rebase, but before that i will squash commits as is sensible |
14:25 |
MTDiscord |
<luatic> but if i just wrote nosquash others might assume that the commits are to be merged as-is |
14:25 |
MTDiscord |
<luatic> if i wasn't lazy i would eagerly rewrite history |
14:26 |
MTDiscord |
<josiah_wi> Oh yes, this PR also contains a b3d fix haha. The no-inverse-matrix issue. |
14:27 |
MTDiscord |
<luatic> arguably that i will squash, since it was caused by changes made for animated gltf |
14:36 |
|
SFENCE joined #minetest-dev |
14:37 |
Desour |
you could also use autosquash (see `git commit --fixup <commit>` and `git rebase --autosquash <branch>`) |
14:44 |
|
SFENCE joined #minetest-dev |
14:46 |
|
SFENCE joined #minetest-dev |
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 |
15:35 |
|
SFENCE joined #minetest-dev |
15:35 |
|
Desour joined #minetest-dev |
15:35 |
|
luk3yx joined #minetest-dev |
15:35 |
|
MTDiscord joined #minetest-dev |
15:35 |
|
SpaceManiac joined #minetest-dev |
15:35 |
|
Eragon joined #minetest-dev |
15:35 |
|
panwolfram joined #minetest-dev |
15:35 |
|
nekobit joined #minetest-dev |
15:35 |
|
red-001 joined #minetest-dev |
15:35 |
|
Warr1024 joined #minetest-dev |
15:35 |
|
ivanbu joined #minetest-dev |
15:35 |
|
vampirefrog joined #minetest-dev |
15:35 |
|
Pexin joined #minetest-dev |
15:35 |
|
Evergreen3 joined #minetest-dev |
15:35 |
|
fgaz_ joined #minetest-dev |
15:35 |
|
Niklp joined #minetest-dev |
15:35 |
|
Juri joined #minetest-dev |
15:35 |
|
thelounge6564 joined #minetest-dev |
15:35 |
|
jonadab joined #minetest-dev |
15:35 |
|
BuckarooBanzai joined #minetest-dev |
15:35 |
|
[MatrxMT] joined #minetest-dev |
15:35 |
|
izzyb joined #minetest-dev |
15:35 |
|
book` joined #minetest-dev |
15:35 |
|
ROllerozxa joined #minetest-dev |
15:35 |
|
nore joined #minetest-dev |
15:35 |
|
TheCoffeMaker joined #minetest-dev |
15:35 |
|
ShadowBot joined #minetest-dev |
15:35 |
|
hlqkj joined #minetest-dev |
15:35 |
|
sofar joined #minetest-dev |
15:35 |
|
Thomas-S joined #minetest-dev |
15:35 |
|
basxto joined #minetest-dev |
15:35 |
|
Noisytoot joined #minetest-dev |
15:35 |
|
pgimeno joined #minetest-dev |
15:35 |
|
sugarbeet joined #minetest-dev |
15:35 |
|
swift110-mobile joined #minetest-dev |
15:35 |
|
clavi joined #minetest-dev |
15:35 |
|
Mantar joined #minetest-dev |
15:35 |
|
[0] joined #minetest-dev |
15:35 |
|
figboot joined #minetest-dev |
15:35 |
|
hifi joined #minetest-dev |
15:35 |
|
sfan5 joined #minetest-dev |
15:35 |
|
calculon joined #minetest-dev |
15:35 |
|
dv^_^ joined #minetest-dev |
15:35 |
|
MisterE1230 joined #minetest-dev |
15:35 |
|
rubenwardy joined #minetest-dev |
15:35 |
|
Krock joined #minetest-dev |
15:35 |
|
Soni joined #minetest-dev |
15:35 |
|
dzho joined #minetest-dev |
15:35 |
|
citrons joined #minetest-dev |
15:35 |
|
wsor4035 joined #minetest-dev |
15:35 |
|
razzlom joined #minetest-dev |
15:35 |
|
nrz joined #minetest-dev |
15:48 |
|
v-rob joined #minetest-dev |
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 |
16:25 |
|
SFENCE joined #minetest-dev |
16:28 |
|
SFENCE joined #minetest-dev |
16:34 |
|
SFENCE joined #minetest-dev |
16:45 |
|
SpaceManiac joined #minetest-dev |
16:46 |
|
SFENCE joined #minetest-dev |
16:46 |
|
fluxionary joined #minetest-dev |
16:55 |
|
SFENCE joined #minetest-dev |
17:05 |
|
SFENCE joined #minetest-dev |
17:11 |
|
SFENCE joined #minetest-dev |
17:17 |
|
SFENCE joined #minetest-dev |
17:19 |
|
SFENCE joined #minetest-dev |
17:21 |
|
v-rob joined #minetest-dev |
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:34 |
|
SFENCE joined #minetest-dev |
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:42 |
|
SFENCE joined #minetest-dev |
17:46 |
|
SFENCE joined #minetest-dev |
17:50 |
|
SpaceManiac joined #minetest-dev |
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:51 |
|
SFENCE joined #minetest-dev |
17:53 |
|
SFENCE joined #minetest-dev |
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:55 |
|
SFENCE joined #minetest-dev |
17:56 |
Krock |
dTLS and QUIC seem to be viable options. except that achieving backwards compat would be somewhat difficult |
17:58 |
|
SFENCE joined #minetest-dev |
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:08 |
|
SFENCE joined #minetest-dev |
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:19 |
|
SFENCE joined #minetest-dev |
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 |
|
SFENCE joined #minetest-dev |
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:29 |
|
Sharpman joined #minetest-dev |
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:37 |
|
SFENCE joined #minetest-dev |
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:00 |
|
v-rob joined #minetest-dev |
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:11 |
|
Sokomine joined #minetest-dev |
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 |
20:03 |
|
Sharpman joined #minetest-dev |
20:18 |
|
MTDiscord1 joined #minetest-dev |
20:20 |
|
Evergreen joined #minetest-dev |
20:20 |
|
Warr1024 joined #minetest-dev |
20:21 |
|
red-001_ joined #minetest-dev |
20:35 |
|
Desour joined #minetest-dev |
20:46 |
|
Desour_ joined #minetest-dev |
20:46 |
|
Desour joined #minetest-dev |
20:51 |
|
Sharpman joined #minetest-dev |
22:36 |
|
panwolfram joined #minetest-dev |
23:05 |
|
Eragon joined #minetest-dev |
23:05 |
MTDiscord |
<herowl> 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 |