| Time |
Nick |
Message |
| 00:58 |
|
Megaf joined #minetest-dev |
| 01:58 |
|
Fritigern joined #minetest-dev |
| 03:01 |
ShadowNinja |
est31: No, I got carried away with fixing NetworkPacket. :-P |
| 03:02 |
ShadowNinja |
Doesn't really matter though, since the client is apparently hardcoded to proto v24 right now. |
| 03:05 |
est31 |
It matters a bit ShadowNinja as I'm right editing v25, especially the early stages |
| 03:05 |
est31 |
to get srp support |
| 03:05 |
est31 |
but your change is small, it can be rebased fast |
| 03:05 |
ShadowNinja |
^ |
| 03:13 |
|
Hunterz joined #minetest-dev |
| 03:20 |
|
Zeno` joined #minetest-dev |
| 03:21 |
|
jin_xi joined #minetest-dev |
| 03:30 |
|
Miner_48er joined #minetest-dev |
| 03:37 |
|
cheapie joined #minetest-dev |
| 04:50 |
|
cib0 joined #minetest-dev |
| 05:11 |
|
est31 joined #minetest-dev |
| 06:23 |
|
Hunterz1 joined #minetest-dev |
| 06:24 |
|
Zeno` joined #minetest-dev |
| 06:24 |
Zeno` |
I just realised something |
| 06:24 |
Zeno` |
that fake server... |
| 06:25 |
Zeno` |
*if* the person was indeed the person using social engineering a few weeks ago to get escalated privs on at least 2 servers I know of, then that person now has a lot of people's passwords |
| 06:26 |
Zeno` |
ugh, sorry... meant that to be pm |
| 06:39 |
|
Krock joined #minetest-dev |
| 06:46 |
|
AnotherBrick joined #minetest-dev |
| 07:53 |
|
Taoki[mobile] joined #minetest-dev |
| 07:57 |
|
blaze joined #minetest-dev |
| 08:03 |
|
Hijiri joined #minetest-dev |
| 08:03 |
|
blaze joined #minetest-dev |
| 08:03 |
|
blaze joined #minetest-dev |
| 08:12 |
|
johnnyjoy joined #minetest-dev |
| 08:19 |
|
Calinou joined #minetest-dev |
| 08:37 |
|
kilbith joined #minetest-dev |
| 08:37 |
|
cib0 joined #minetest-dev |
| 09:16 |
|
kilbith joined #minetest-dev |
| 09:22 |
|
Taoki[laptop] joined #minetest-dev |
| 09:46 |
|
OldCoder joined #minetest-dev |
| 09:52 |
|
chchjesus joined #minetest-dev |
| 09:56 |
|
AnotherBrick joined #minetest-dev |
| 10:33 |
|
MinetestForFun joined #minetest-dev |
| 10:50 |
|
cib0 joined #minetest-dev |
| 10:52 |
|
nrzkt joined #minetest-dev |
| 10:53 |
nrzkt |
~tell est31 the new _init packet must only present the server. We don't need the player name here. It's a pure initialization. Playername should be sent in the next packet, or the auth packet if auth isn't next. _init packet is only for the server and client presentation, no need to know about player here, it's only the protocol init |
| 10:53 |
ShadowBot |
nrzkt: O.K. |
| 10:56 |
|
kilbith joined #minetest-dev |
| 11:00 |
|
MinetestForFun joined #minetest-dev |
| 11:00 |
kilbith |
sfan5, i'd like to integrate an [Exit to OS] button on the mainmenu for the fullscreen option in 2555 -- problem is there's no Lua callback for exit to OS (only in C++), would you be willing to add it ? |
| 11:17 |
|
Amaz joined #minetest-dev |
| 11:22 |
|
err404 joined #minetest-dev |
| 11:38 |
|
roniz_ joined #minetest-dev |
| 12:05 |
|
Taoki[laptop] joined #minetest-dev |
| 12:13 |
|
Hunterz joined #minetest-dev |
| 12:15 |
|
err404 joined #minetest-dev |
| 12:20 |
|
selat joined #minetest-dev |
| 13:22 |
|
cib0 joined #minetest-dev |
| 13:57 |
|
Anchakor_ joined #minetest-dev |
| 14:01 |
|
Hunterz joined #minetest-dev |
| 14:10 |
|
kilbith joined #minetest-dev |
| 14:31 |
|
Player_2 joined #minetest-dev |
| 14:57 |
|
VanessaE joined #minetest-dev |
| 15:11 |
|
rubenwardy joined #minetest-dev |
| 15:25 |
|
cib joined #minetest-dev |
| 15:27 |
|
MinetestForFun joined #minetest-dev |
| 15:35 |
|
hmmmm joined #minetest-dev |
| 16:05 |
|
jin_xi joined #minetest-dev |
| 16:50 |
|
cib0 joined #minetest-dev |
| 16:57 |
|
Hijiri joined #minetest-dev |
| 17:05 |
|
selat joined #minetest-dev |
| 17:18 |
|
srifqi joined #minetest-dev |
| 17:18 |
srifqi |
~tell est31 Please check #2561 |
| 17:18 |
ShadowBot |
srifqi: O.K. |
| 17:48 |
|
srifqi joined #minetest-dev |
| 17:57 |
|
Hijiri joined #minetest-dev |
| 18:02 |
|
srifqi joined #minetest-dev |
| 18:41 |
|
est31 joined #minetest-dev |
| 18:45 |
|
ShadowBot joined #minetest-dev |
| 19:06 |
est31 |
man, hard to reach nrzkt |
| 19:06 |
est31 |
I want to discuss with him about the init packets |
| 19:06 |
est31 |
but he is offline :/ |
| 19:09 |
est31 |
perhaps I'll do a PR and then we can discuss it there... |
| 19:10 |
est31 |
because now I am convinced of the opposite |
| 19:10 |
kilbith |
you have his e-mail address... |
| 19:10 |
est31 |
the player name should be in the init packet, not in an extra packet |
| 19:11 |
est31 |
good idea |
| 19:12 |
est31 |
ah he is on the mailinglist, very fine |
| 19:29 |
hmmmm |
it's hard to keep track of changes and proposed changes to the protocol |
| 19:29 |
hmmmm |
i propose maintaining a document for both layers of the protocol |
| 19:30 |
hmmmm |
whenever you change the protocol, you update the docs for it which should be in the doc directory |
| 19:30 |
|
cib0 joined #minetest-dev |
| 19:30 |
hmmmm |
whenever you propose a change, you change the doc and show the diff of it |
| 19:32 |
est31 |
this is how clientiface looks like after my changes: http://pastie.org/10087048 |
| 19:32 |
est31 |
ow sorry thats the old one |
| 19:32 |
est31 |
new one here: http://pastie.org/10087049 |
| 19:33 |
est31 |
here without line length limitations: http://pastebin.com/kjG5n44y |
| 19:33 |
|
MinetestForFun joined #minetest-dev |
| 19:35 |
|
err404 joined #minetest-dev |
| 19:35 |
est31 |
but that image isn't very informative, as with the current protocol v25, only the "Authentication, depending on ..." part is another one |
| 19:36 |
est31 |
That is too complicated to be added to the ascii art |
| 19:37 |
est31 |
then there is networkprotocl.h |
| 19:37 |
est31 |
its also a good doc |
| 19:39 |
est31 |
mail sent |
| 19:40 |
hmmmm |
that second post, the new one, is that your proposed one or is that how the protocol currently is at this moment in time? |
| 19:40 |
est31 |
its how the protocol is right now basically without the "Authentication, depending on ..." part |
| 19:41 |
est31 |
that part is in the current protocol done by the opcode TOSERVER_AUTH |
| 19:41 |
hmmmm |
ahh ok |
| 19:41 |
hmmmm |
so TOCLIENT_HELLO already exists |
| 19:41 |
hmmmm |
is there a list of fields for each packet? |
| 19:41 |
est31 |
yes |
| 19:41 |
Krock |
I don't get it. Why #2618 cause an instant error after the 2nd connect? |
| 19:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/2618 -- 30s timeout when connecting to server by SmallJoker |
| 19:41 |
est31 |
all in networkprotocol.h |
| 19:43 |
hmmmm |
erm |
| 19:43 |
hmmmm |
was that file added recently because i can't find it |
| 19:44 |
hmmmm |
oh hrmm interesting |
| 19:44 |
est31 |
networkprotocol.h is in src/network |
| 19:44 |
est31 |
previously it was named clientserver.h I think |
| 19:44 |
hmmmm |
yeah i see, my project file must just be out of date |
| 19:46 |
hmmmm |
so what *is* sent in TOCLIENT_HELLO? nothing?? |
| 19:47 |
est31 |
u16 command, u8 deployed version I think |
| 19:47 |
est31 |
https://github.com/minetest/minetest/blob/master/src/network/clientpackethandler.cpp#L47 |
| 19:48 |
est31 |
yes only that currently |
| 19:48 |
hmmmm |
yea.. it's not documented at all |
| 19:48 |
hmmmm |
i don't know, it's odd but i'm withholding judgement |
| 19:48 |
hmmmm |
there could be a lot more information in the earlier stages |
| 19:49 |
est31 |
yes, I'll add authentication information to the packet |
| 19:50 |
est31 |
from nrzkt's mail on the list: "The first step is implemented server side, i cutted TOCLIENT_INIT_LEGACY in two parts, TOCLIENT_HELO which send only the server version and some supported things, like compression modes (server presentation to client) and TOCLIENT_AUTH_ACCEPT to answer the client that the authentication was accepted." |
| 19:50 |
hmmmm |
and what did this accomplish exactly |
| 19:50 |
hmmmm |
i don't like making changes for the sake of making changes |
| 19:51 |
est31 |
the playerpos for example should only be sent when the authentication was successful |
| 19:52 |
est31 |
so its ok with the current protocol to send it in the second message, because after the client has sent the initial TOSERVER_INIT_LEGACY, we already can determine whether auth succeeded or failed |
| 19:52 |
est31 |
but srp will have multiple messages sent back and forth |
| 19:53 |
est31 |
and at the start, the client needs to know whether it is opening a new account on the server, or logging in as existing account. Current protocol is same for both (send the password), but srp differs |
| 19:53 |
hmmmm |
whathftgifucvok |
| 19:53 |
hmmmm |
TOSERVER_INIT_LEGACY had the password and the player's name? |
| 19:53 |
est31 |
yes |
| 19:54 |
hmmmm |
the very first packet sent is the player name and password? |
| 19:54 |
hmmmm |
eth |
| 19:54 |
hmmmm |
this is terrifying |
| 19:54 |
est31 |
https://github.com/minetest/minetest/blob/master/src/network/networkprotocol.h#L615 |
| 20:08 |
est31 |
hmmmm, which NetBSD/FreeBSD versions do we support? |
| 20:08 |
hmmmm |
as many as possible |
| 20:08 |
est31 |
https://gmplib.org/gmp6.0.html sais T"his release will not work on NetBSD 5.x, FreeBSD 7.x, 8.x or 9 series before 9.3." |
| 20:08 |
hmmmm |
ooh.. |
| 20:08 |
est31 |
Workaround: Use an older GMP release, or install GNU m4 from /usr/ports and tell GMP to use it. |
| 20:08 |
hmmmm |
yeah not good |
| 20:08 |
hmmmm |
I was going to say it's fine to drop support for FreeBSD <= 7.0 |
| 20:09 |
hmmmm |
we already depend on features new to freebsd 7.0 |
| 20:09 |
hmmmm |
what's so amazing about libgmp 6.0 ? |
| 20:10 |
est31 |
we can use older releases too |
| 20:10 |
est31 |
I just want one without known security vulnerabilities, and one which works |
| 20:11 |
est31 |
(6.0 is newest) |
| 20:11 |
hmmmm |
well let's see what is actually changed and improved |
| 20:11 |
hmmmm |
"faster mixed arithmetic between mpq_class and double" - like, what? we don't use floating point numbers here |
| 20:12 |
hmmmm |
looks like AVX2 support |
| 20:12 |
hmmmm |
i don't know. is it worth not supporting just about every variant of freebsd just for some avx2 |
| 20:13 |
est31 |
then 5.1.3 |
| 20:13 |
hmmmm |
if somebody wants to use the super-optmized version of gmp that has poor bsd support, they can use their own installation of the library |
| 20:13 |
hmmmm |
but it should fall back to a version that everybody has |
| 20:13 |
est31 |
yup |
| 20:13 |
est31 |
"The BSD MP compatibility functions have been removed." |
| 20:13 |
hmmmm |
erm, a version that supports as much as possible |
| 20:14 |
est31 |
what does that mean?? |
| 20:14 |
est31 |
https://gmplib.org/gmp5.1.html |
| 20:15 |
hmmmm |
i have no idea |
| 20:15 |
hmmmm |
it's probably not important |
| 20:16 |
est31 |
the freebsd ports page claims to have 5.1.3 |
| 20:16 |
hmmmm |
yeah let's go with that one then |
| 20:16 |
est31 |
yea |
| 20:19 |
est31 |
I'll add it like lua, under a folder src/gmp |
| 20:20 |
hmmmm |
yeah |
| 20:20 |
|
Hijiri joined #minetest-dev |
| 20:21 |
hmmmm |
i wonder, what is the significance of "k" in srp? how dies it make the session key computation more secure than it would otherwise be |
| 20:22 |
est31 |
wiki sais "k is a parameter derived by both sides; for example, k = H(N, g). This creates an asymmetry between the client and server sides of the protocol, meaning a man-in-the-middle attacker only gets 1 verification attempt per impersonation, rather than 2." |
| 20:22 |
hmmmm |
oh durr |
| 20:22 |
|
Fritigern joined #minetest-dev |
| 20:22 |
hmmmm |
i didn't realize wikipedia said that |
| 20:23 |
est31 |
I have some issues with the wikipedia page though |
| 20:23 |
Calinou |
\o/ a new dependency |
| 20:23 |
est31 |
e.g. "x is discarded because it is equivalent to the plaintext password p." |
| 20:23 |
est31 |
that is wrong AFAIK |
| 20:23 |
hmmmm |
how so |
| 20:23 |
hmmmm |
it is the cryptographic equivalent |
| 20:24 |
hmmmm |
just salted and hashed along with the username |
| 20:24 |
est31 |
a brute forcer can calculate g^x just like that |
| 20:24 |
est31 |
so when they know v, they can already brute force the password |
| 20:24 |
est31 |
so x isn't less or more password equivalent than v. |
| 20:25 |
hmmmm |
well they definitely know s since that's public |
| 20:25 |
hmmmm |
they also know the username |
| 20:25 |
est31 |
g is also public |
| 20:25 |
hmmmm |
sure |
| 20:26 |
hmmmm |
but they don't exactly know what x is because it's been modulo N |
| 20:26 |
hmmmm |
they don't send g^x, they send (g^x)%N |
| 20:26 |
hmmmm |
x on the other hand is not modulo N in any computations directly |
| 20:26 |
hmmmm |
is not computed modulo N i meant to say |
| 20:27 |
Calinou |
we should have password brute-force protection in Minetest btw |
| 20:27 |
Calinou |
allow only one password attempt per 10 seconds |
| 20:27 |
Calinou |
or 5 |
| 20:27 |
hmmmm |
that's mod material, calinou |
| 20:27 |
Calinou |
why shouldn't it be in core? |
| 20:27 |
hmmmm |
why should it? |
| 20:27 |
hmmmm |
the core is the core, that's a module like fail2ban |
| 20:30 |
est31 |
hmmmm, doesn't x only appear in forms of g^x? |
| 20:30 |
hmmmm |
are you sure? |
| 20:31 |
hmmmm |
i thought it was always modulo N |
| 20:31 |
est31 |
yes always mod N |
| 20:35 |
hmmmm |
oh speaking of which, there's a redundancy on that wiki page's example code |
| 20:35 |
hmmmm |
in computing S_c, they could replace pow(g, x, N) with v |
| 20:39 |
est31 |
yea |
| 20:40 |
hmmmm |
so you wanted to support multiple versions of auth, correct? |
| 20:40 |
est31 |
yes. |
| 20:41 |
hmmmm |
how do you intend to do this? |
| 20:42 |
est31 |
the client sends the server their username, the server looks up the password field in the db or whereever, and then finds out which mechanisms it can send as answer |
| 20:42 |
est31 |
then the client choses one of those mechanisms |
| 20:42 |
est31 |
Initially, there are three |
| 20:42 |
est31 |
SRP_LEGACY, SPP, and SRP_FIRST |
| 20:42 |
hmmmm |
what's SPP? |
| 20:42 |
est31 |
lol |
| 20:42 |
est31 |
SRP* |
| 20:42 |
hmmmm |
oh what are those |
| 20:43 |
est31 |
so SRP_LEGACY is SRP based on the legacy hash instead of the bare password |
| 20:44 |
est31 |
SRP is the usual SRP based on a verifier that has been sent to the server during SRP_FIRST |
| 20:44 |
est31 |
also, the SRP_LEGACY protocol should contain a mechanism where the user can send a verifier that should be used in future |
| 20:44 |
hmmmm |
what is SRP_FIRST, then? |
| 20:45 |
hmmmm |
if the account doesn't exist? |
| 20:45 |
est31 |
yup |
| 20:45 |
hmmmm |
shouldn't you just make that a separate packet exchange to create a new account? |
| 20:45 |
est31 |
as in? |
| 20:46 |
hmmmm |
well, how does SRP_FIRST work? |
| 20:47 |
est31 |
very simple, one packet, where the client sends the verifier, thats it |
| 20:47 |
hmmmm |
the way blizzard games did it was that they sent a separate account creation packet |
| 20:47 |
hmmmm |
oh |
| 20:47 |
hmmmm |
that's the same here except the client creates s and sends the verifier |
| 20:48 |
est31 |
the salt is composed from the serverSalt and the clientSalt |
| 20:48 |
est31 |
both sent in the init packets, one by server one by client |
| 20:48 |
hmmmm |
in traditional SRP, the s sent to the client is the one simply stored along with the account from creation time |
| 20:48 |
hmmmm |
if you want to have two separate salts I guess that's fine |
| 20:48 |
hmmmm |
but i'm not sure how that would make things more secure |
| 20:50 |
hmmmm |
in fact I'm not so sure why we don't just create a random salt exclusively on the server |
| 20:50 |
hmmmm |
how does the client providing its own salt help |
| 20:50 |
est31 |
if the server choses the salt, then it may use the salt of another server, and so find out the v there |
| 20:53 |
est31 |
It might be that there is no benefit in the server chosing a part of the salt. |
| 20:54 |
est31 |
I've mostly done this for consistency |
| 20:55 |
hmmmm |
maybe the client should send its own salt in every init packet instead of on account creation |
| 20:55 |
hmmmm |
so that the server can't compromise anything by having a poor RNG |
| 20:56 |
est31 |
yea thats exactly what I'm planning |
| 20:57 |
est31 |
Thats my next problem with the wiki page: " the value could be chosen by either side " |
| 20:57 |
est31 |
No! |
| 21:03 |
est31 |
ha lol |
| 21:03 |
est31 |
either i'm getting it wrong, or we are using the cmake find_library not according to doc |
| 21:04 |
est31 |
we are doing find_library(LUA_LIBRARY luajit NAMES luajit-5.1) |
| 21:04 |
est31 |
but the doc http://www.cmake.org/cmake/help/v3.0/command/find_library.html |
| 21:04 |
est31 |
there it sais: find_library ( <VAR> |
| 21:04 |
est31 |
(so far so good) |
| 21:04 |
est31 |
name | NAMES name1 [name2 ...] [NAMES_PER_DIR] |
| 21:05 |
est31 |
so either name or NAMES and then the list of names |
| 21:05 |
est31 |
not both |
| 21:06 |
|
sockbat joined #minetest-dev |
| 21:13 |
est31 |
hmmmm, gmp has autotools based build process what to do? can I simply call the command, or should I port the whole build system? |
| 21:14 |
hmmmm |
i say call the command |
| 21:18 |
|
Hijiri joined #minetest-dev |
| 21:30 |
est31 |
man, the list of gmp files makes my console buffer overflow |
| 21:35 |
|
decimalguy joined #minetest-dev |
| 21:40 |
est31 |
compiling gmp takes some time |
| 21:45 |
est31 |
lol "GMP has been carefully tested by its authors, but compilers are all too often released with serious bugs. GMP tends to explore interesting corners in compilers and has hit bugs on quite a few occasions." |
| 21:54 |
|
err404 joined #minetest-dev |
| 22:01 |
|
Anchakor_ joined #minetest-dev |
| 22:04 |
|
err404 joined #minetest-dev |
| 22:08 |
|
Hijiri joined #minetest-dev |
| 22:28 |
est31 |
ShadowNinja, are your remarks for #2586 resolved now? |
| 22:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/2586 -- Fix some bugs in mainmenu tab_singleplayer and tab_server by fz72 |
| 22:48 |
|
err404 joined #minetest-dev |
| 22:57 |
est31 |
man my 💩 works |
| 22:57 |
est31 |
or at least compiles |
| 23:25 |
|
err404 joined #minetest-dev |
| 23:29 |
|
Hijiri joined #minetest-dev |
| 23:55 |
|
paramat joined #minetest-dev |
