| Time |
Nick |
Message |
| 01:39 |
|
Miner_48er joined #minetest-dev |
| 01:40 |
|
Aaron101- joined #minetest-dev |
| 01:43 |
|
gregorycu joined #minetest-dev |
| 01:43 |
gregorycu |
Is there anything I can do to assist with the release? |
| 01:43 |
|
Kargaroc joined #minetest-dev |
| 01:44 |
gregorycu |
(Possible resend) Is there anything I can do to assist with the release? |
| 01:48 |
|
Sokomine joined #minetest-dev |
| 01:48 |
|
Ritchie joined #minetest-dev |
| 01:48 |
|
pitriss joined #minetest-dev |
| 01:54 |
|
gregorycu_ joined #minetest-dev |
| 01:54 |
|
shadowzone joined #minetest-dev |
| 01:57 |
|
gregorycu joined #minetest-dev |
| 01:58 |
gregorycu |
T4im: So I was thinking |
| 01:58 |
gregorycu |
How about we actually make a proper deregister function |
| 02:03 |
T4im |
sounds good :) |
| 02:07 |
|
shadowzone joined #minetest-dev |
| 02:16 |
|
electrodude512 joined #minetest-dev |
| 02:36 |
gregorycu |
It's pretty bad that get_craft_recipe returns nullifying recepies |
| 02:36 |
gregorycu |
est31: My good man, are you around? |
| 02:41 |
|
Player_2 joined #minetest-dev |
| 02:48 |
gregorycu |
bool sneak_node_found = (min_distance_f < 100000.0*BS*0.9); |
| 02:48 |
gregorycu |
Sweed Jesus |
| 02:48 |
gregorycu |
Sweet |
| 02:49 |
acerspyro |
#foreveralone |
| 02:50 |
gregorycu |
BS is 10 |
| 02:50 |
gregorycu |
I don't even... |
| 02:53 |
gregorycu |
I found another sneaking-related bug. Hooray. |
| 02:54 |
|
electrodude512 joined #minetest-dev |
| 03:01 |
kahrl |
what's the bug? |
| 03:01 |
kahrl |
gregorycu: ^ |
| 03:02 |
gregorycu |
I think this may be a manifestation of an existing bug |
| 03:02 |
gregorycu |
When you sneak on a slab, or a non-full node, sneaking behaves strangely |
| 03:02 |
kahrl |
yeah, that's a known bug |
| 03:02 |
kahrl |
the sneak code has to my knowledge never been adapted to work with nodeboxes |
| 03:03 |
gregorycu |
It has caused #1551 |
| 03:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/1551 -- disable_jump group doesnt work on nodeboxes |
| 03:04 |
gregorycu |
Maybe I can make sneaking work a little better |
| 03:06 |
kahrl |
the whole local player physics need some rework, imho |
| 03:06 |
kahrl |
but if you can fix just the sneaking that would already be great too |
| 03:06 |
gregorycu |
It stores a node the player is sneaking on |
| 03:07 |
gregorycu |
It should probably store a sneaking height too |
| 03:07 |
gregorycu |
But yeah, I don't want to do a massive rework :( |
| 03:07 |
gregorycu |
I'll try and fix this bug without changing too much |
| 03:07 |
acerspyro |
gregorycu: Noone does |
| 03:07 |
acerspyro |
This is doomed. :3 |
| 03:38 |
|
electrodude512 joined #minetest-dev |
| 04:03 |
|
electrodude512 joined #minetest-dev |
| 04:05 |
|
FR^3 joined #minetest-dev |
| 04:08 |
|
gregorycu joined #minetest-dev |
| 04:09 |
|
FR^3 joined #minetest-dev |
| 04:11 |
|
VanessaE joined #minetest-dev |
| 04:12 |
|
gregorycu_ joined #minetest-dev |
| 04:14 |
|
gregorycu_ joined #minetest-dev |
| 04:19 |
|
FR^3 joined #minetest-dev |
| 04:21 |
|
gregorycu___ joined #minetest-dev |
| 04:29 |
|
FR^3 joined #minetest-dev |
| 04:41 |
|
gregorycu joined #minetest-dev |
| 04:42 |
|
gregorycu_ joined #minetest-dev |
| 04:45 |
|
gregorycu__ joined #minetest-dev |
| 04:45 |
|
electrodude512 joined #minetest-dev |
| 05:18 |
|
gregorycu joined #minetest-dev |
| 05:30 |
gregorycu |
Sneaking is a bit of a basketcase |
| 06:06 |
|
Kalabasa joined #minetest-dev |
| 06:15 |
|
thaostra joined #minetest-dev |
| 06:27 |
|
blaze joined #minetest-dev |
| 06:37 |
hmmmm |
alright |
| 06:37 |
hmmmm |
I think this will be the first release to use minidumps |
| 06:37 |
hmmmm |
THING IS... |
| 06:38 |
hmmmm |
you need symbols created alongside the executable built |
| 06:38 |
hmmmm |
so for consistency I'm putting up Windows Server 2008 R2 x64 and x86 VMs that everybody will use to build the windows targets |
| 06:39 |
hmmmm |
I'll have to figure out some way of distributing access to the build machine |
| 06:39 |
hmmmm |
the Official(tm) build machine |
| 06:40 |
hmmmm |
this also helps streamline the build process so there will always be the correct resources available when doing a release |
| 07:01 |
|
Megaf_ joined #minetest-dev |
| 07:08 |
hmmmm |
what's up with https://github.com/minetest/minetest/pull/2095 ? |
| 07:28 |
|
SopaXT joined #minetest-dev |
| 07:43 |
|
nore joined #minetest-dev |
| 07:43 |
|
nrzkt joined #minetest-dev |
| 07:53 |
|
ImQ009 joined #minetest-dev |
| 08:14 |
|
leat joined #minetest-dev |
| 08:16 |
|
Hunterz joined #minetest-dev |
| 08:29 |
|
kilbith joined #minetest-dev |
| 08:45 |
|
loggingbot_ joined #minetest-dev |
| 08:45 |
|
Topic for #minetest-dev is now **FEATURE FREEZE FOR 0.4.12** **TENATIVE RELEASE DATE: 2015-01-30** Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 08:47 |
|
SopaXorzTaker joined #minetest-dev |
| 08:47 |
|
ImQ009 joined #minetest-dev |
| 08:48 |
|
everamzah joined #minetest-dev |
| 08:50 |
|
hmmmm joined #minetest-dev |
| 08:59 |
|
Calinou joined #minetest-dev |
| 09:05 |
|
psedlak joined #minetest-dev |
| 09:05 |
|
Wayward_One joined #minetest-dev |
| 09:06 |
|
VanessaE joined #minetest-dev |
| 09:08 |
|
Krock joined #minetest-dev |
| 09:08 |
|
Player_2 joined #minetest-dev |
| 09:10 |
|
jin_xi joined #minetest-dev |
| 09:31 |
|
casimir joined #minetest-dev |
| 09:31 |
|
gregorycu joined #minetest-dev |
| 10:07 |
|
FR^2 joined #minetest-dev |
| 10:10 |
|
DFeniks_ joined #minetest-dev |
| 10:20 |
|
PilzAdam joined #minetest-dev |
| 10:49 |
|
SopaXorzTaker joined #minetest-dev |
| 11:33 |
gregorycu |
It seems the player takes damage, even while dead |
| 11:33 |
gregorycu |
Is that a design decision? |
| 12:00 |
|
roniz joined #minetest-dev |
| 12:08 |
|
MinetestForFun joined #minetest-dev |
| 12:18 |
|
Kalabasa joined #minetest-dev |
| 12:39 |
Krock |
gregorycu, how is that bad? someone can be dead but it's still possible to destroy the body |
| 12:40 |
gregorycu |
I'm looking at #81 |
| 12:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/81 -- dying on lava causes repeated death, if respawn location isnt quickly updated |
| 12:40 |
gregorycu |
I want to try and kill some really old bugs |
| 12:41 |
gregorycu |
Anyway, the damage is client side, so every second the client sends "I got damaged" |
| 12:41 |
gregorycu |
Even while dead |
| 12:41 |
gregorycu |
The problem is, if there is any message queuing on the server or client, the server respawns the player, and then processes the "I got damaged" messages from when the player was dead |
| 12:41 |
gregorycu |
And kills the player again |
| 12:42 |
Krock |
oh. I know that problem |
| 12:42 |
Krock |
also teleport has it |
| 12:42 |
gregorycu |
So, I'm just trying to determine what behaviours I am not allowed to change, basically |
| 12:43 |
Krock |
the soulation for this is to attach an invisible entity to the player, so it can't move anymore and then teleport |
| 12:45 |
|
gregorycu_ joined #minetest-dev |
| 12:45 |
gregorycu |
How does that solve the damage problem? |
| 12:45 |
gregorycu_ |
lol |
| 12:45 |
gregorycu_ |
I just got my own message |
| 12:46 |
Krock |
lol |
| 12:47 |
gregorycu_ |
Fucked if I know how that happened, anyway |
| 12:59 |
|
Krock joined #minetest-dev |
| 13:03 |
gregorycu |
Well, by disabling after-death damage, I have fixed this... |
| 13:04 |
gregorycu |
Not saying this is the answer, just saying this is a possible solution |
| 13:05 |
nore |
sfan5, what about game#415, game#413, game#418 ? |
| 13:05 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/415 -- Optimize Sam II + textures by kilbith2 |
| 13:05 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/413 -- Make books writable by ShadowNinja |
| 13:05 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/418 -- Add reverse recipes for hoes while keeping def.recipe compatibility by MT-Modder |
| 13:06 |
gregorycu |
What are reverse recipes? |
| 13:06 |
sfan5 |
nore: #415 removes the alternate vessel textures |
| 13:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/415 -- Add multiple nodeboxes for "wallmounted" drawtype |
| 13:07 |
kilbith |
sfan5: really needed ? |
| 13:07 |
sfan5 |
kilbith: yes |
| 13:07 |
|
Amaz joined #minetest-dev |
| 13:08 |
sfan5 |
nore: 413 is probably ok, 418 is ok |
| 13:08 |
kilbith |
for ? |
| 13:09 |
kilbith |
sfan5: why ? |
| 13:09 |
sfan5 |
if someone wants to use those alternate textures |
| 13:10 |
kilbith |
haha, so why not propose alternative textures for the whole game then ? |
| 13:12 |
kilbith |
sfan5 ^ |
| 13:12 |
sfan5 |
because thats what texture packs are for |
| 13:12 |
kilbith |
?? |
| 13:12 |
sfan5 |
?? |
| 13:12 |
gregorycu |
?? |
| 13:13 |
gregorycu |
Goodnight all |
| 13:14 |
kilbith |
this is ridiculous, you want to propose alternative for the vessels, but the principle stops at it |
| 13:14 |
kilbith |
for somewhat reason |
| 13:14 |
sfan5 |
it does not make sense to have seperate texture pack somewhere where nobody will find it for 3 textures |
| 13:14 |
sfan5 |
just leave the files alone |
| 13:15 |
kilbith |
eh, the vessels textures are findable in all TP |
| 13:16 |
kilbith |
i just don't understand why especially those 3 textures needs an alternative |
| 13:16 |
kilbith |
that nobody uses anyways |
| 13:16 |
sfan5 |
[citation needed] |
| 13:16 |
kilbith |
the new ones received a positive unanimity |
| 13:16 |
|
SopaXorzTaker joined #minetest-dev |
| 13:17 |
kilbith |
i don't need to bring a citation, i just wander on the server, unlike you |
| 13:17 |
kilbith |
servers* |
| 13:20 |
sfan5 |
who said it's a public server that uses these? |
| 13:21 |
kilbith |
it was an example |
| 13:21 |
kilbith |
this logic is obscure to me |
| 13:22 |
kilbith |
it seems more an 'historical conservatism' |
| 13:31 |
nrzkt |
bon bah moi de mon côté je crois bien que j'ai fait le maximum en terme d'opti sur l'interaction avec ma couche |
| 13:31 |
nrzkt |
le PR est prêt |
| 13:31 |
nrzkt |
après faut passer au cassage de couche et de protocoles |
| 13:32 |
kilbith |
tu t'es gourré d'onglet je crois |
| 13:32 |
Krock |
Please switch to english or talk in ##minetest-fr |
| 13:32 |
kilbith |
Krock, just a confusion |
| 13:32 |
nrzkt |
oops sorry :p |
| 13:32 |
nrzkt |
Don't be evil Krock ^^ |
| 13:32 |
kilbith |
and it's #minetest-fr |
| 13:34 |
Krock |
sfan5, would you be so nice and update the topic, so it's a realistic release date? |
| 13:34 |
Krock |
btw, it's TENTATIVE, not TENATIVE |
| 13:35 |
|
mrtux joined #minetest-dev |
| 14:45 |
|
kaeza joined #minetest-dev |
| 14:52 |
|
Wayward_One joined #minetest-dev |
| 15:21 |
|
cheapie joined #minetest-dev |
| 15:22 |
|
MinetestForFun joined #minetest-dev |
| 15:23 |
|
Megal joined #minetest-dev |
| 15:25 |
|
oleastre joined #minetest-dev |
| 15:28 |
|
younishd joined #minetest-dev |
| 15:31 |
|
Krock joined #minetest-dev |
| 15:50 |
|
kaeza joined #minetest-dev |
| 16:11 |
|
SopaXorzTaker joined #minetest-dev |
| 16:24 |
|
Calinou joined #minetest-dev |
| 16:34 |
|
MinetestForFun joined #minetest-dev |
| 16:39 |
nrzkt |
#2243 must be merged before release. Big security fix |
| 16:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/2243 -- Security Fix: Empty the password after sending it to server by nerzhul |
| 16:39 |
|
Krock2 joined #minetest-dev |
| 16:40 |
kilbith |
^ blocker |
| 16:40 |
nrzkt |
please add blocker tag or merge it :) |
| 16:42 |
sfan5 |
huh, what? |
| 16:43 |
nrzkt |
open your browser and look at the issue. |
| 16:43 |
sfan5 |
i did |
| 16:43 |
sfan5 |
are you saying that it's bad to have the password in memory? |
| 16:43 |
|
MinetestForFun joined #minetest-dev |
| 16:44 |
crazyR |
is it sent plain text or hashed? |
| 16:44 |
sfan5 |
hashed |
| 16:44 |
nrzkt |
i say password stay in memory whereas it's only used in this packet and stay in memory |
| 16:44 |
nrzkt |
and the hash is sufficient to create a working connection to server. |
| 16:44 |
crazyR |
if its hashed then it makes no diffrence |
| 16:45 |
crazyR |
if it can be obtained from memory then it can be ready from file |
| 16:45 |
nrzkt |
because i create a custom minetest and paste the hash, not hashing it and sending it to server and it accept. |
| 16:45 |
sfan5 |
this issue doesn't fit it though |
| 16:45 |
crazyR |
or do you mean client side? |
| 16:45 |
sfan5 |
fix that* |
| 16:45 |
nrzkt |
client side, not server side |
| 16:45 |
sfan5 |
crazyR: how? |
| 16:47 |
|
rubenwardy joined #minetest-dev |
| 16:47 |
sfan5 |
nrzkt: about every application keeps passwords and user data in memory |
| 16:47 |
crazyR |
sfan5: what i was saying before i realised nrzkt meant client side is that if "something" could read the password from meomory then it could read it from the auth file. but seen as its hashed in memory that would make no diffrence.. |
| 16:47 |
sfan5 |
why would minetest not? |
| 16:48 |
nrzkt |
it's not because some stupid developer do it you must do it |
| 16:48 |
sfan5 |
protecting the user is not a valid argument; if someone has access to the machine minetest runs on it's game over, there is nothing left to protect |
| 16:48 |
nrzkt |
your argument is stupid |
| 16:48 |
sfan5 |
someone wanting the password could also just swap the minetest executable with one that logs passwords |
| 16:49 |
sfan5 |
<nrzkt> your argument is stupid |
| 16:49 |
crazyR |
sfan thast exactly what i was saying |
| 16:49 |
sfan5 |
it might be |
| 16:49 |
sfan5 |
but you did not even provide an argument |
| 16:49 |
sfan5 |
you just said "you must do it" |
| 16:49 |
nrzkt |
if i load a random binary in memory by bypassing your browser sandbox and read the password in memory, i can obtain every minetest in the world. |
| 16:49 |
crazyR |
but... i agree with nrzkt if all apps do it that doesnt me we should do it if we have a way to stop prevent it |
| 16:49 |
nrzkt |
every minetest password and connect to server. |
| 16:50 |
sfan5 |
how does this fix it? |
| 16:50 |
nrzkt |
the fix is very little, increasing security. |
| 16:50 |
sfan5 |
if you got code running you can use one of the hundred other ways of getting the password |
| 16:50 |
nrzkt |
it replace the string in memory, then no password in memory. If you havent looked at my PR please look at it. |
| 16:50 |
crazyR |
nrzkt if its client side how could it read every password in the world? |
| 16:50 |
sfan5 |
i have looked at the PR |
| 16:51 |
nrzkt |
i mean, if i craft a special webpage, tell many minetest users to go it, then they connect, using an exploit i access to user memory on the machine and get the password |
| 16:51 |
sfan5 |
yes |
| 16:51 |
sfan5 |
how does your issue prevent that? |
| 16:51 |
sfan5 |
you could also use other ways to get the password |
| 16:51 |
nrzkt |
it clear the password after it was used. |
| 16:51 |
crazyR |
ahh i see |
| 16:51 |
nrzkt |
it's the only code path where it's used. |
| 16:51 |
sfan5 |
s/issue/PR/ |
| 16:52 |
nrzkt |
take glasses instead of directory please |
| 16:52 |
sfan5 |
what? |
| 16:53 |
sfan5 |
your pull fixes 1 of many ways to get to the password |
| 16:53 |
sfan5 |
it doesn't improve security significantly |
| 16:53 |
crazyR |
but fixing 1 is better than fixing non |
| 16:53 |
sfan5 |
correct |
| 16:53 |
sfan5 |
but no other application does this? |
| 16:53 |
sfan5 |
s/?// |
| 16:54 |
nrzkt |
we don't care about other applications |
| 16:54 |
est31 |
other applications do this too |
| 16:54 |
nrzkt |
we are talking about minetest. |
| 16:54 |
sfan5 |
..because it's not worth removing the password from memory |
| 16:54 |
nrzkt |
and other applications are right coded. |
| 16:54 |
sfan5 |
est31: link please? |
| 16:54 |
est31 |
and yes eg lua code stores the password to |
| 16:54 |
est31 |
o |
| 16:54 |
est31 |
sfan5: ok wait please |
| 16:55 |
nrzkt |
don't look at other, look at your code men. It's not because we have many doors opened we let all opened instead of closing one. |
| 16:56 |
nrzkt |
and please think about user, not invalid arguments like many devs do. |
| 16:56 |
nrzkt |
don't be ubisoft |
| 16:57 |
crazyR |
i think if it closes a potential security issue - no matter how small and insignificant and the fix does not affect game play or stability. then is should be merged. might not be significant now but its possible future changes could make it significant then |
| 16:57 |
sfan5 |
nrzkt: why should we bother with it when no other program does this? |
| 16:58 |
nrzkt |
i think you only work on shit problem which doesn't care about security. |
| 16:58 |
nrzkt |
shit programs* |
| 16:58 |
crazyR |
sfan5: all my nabours leave there front door unlocked... should i do it? |
| 16:58 |
sfan5 |
nrzkt: being rude does not get your PR merged faster |
| 16:58 |
nrzkt |
ofc |
| 16:59 |
sfan5 |
crazyR: that analogy does not fit, it's more like having their keys in their house when you're already in |
| 16:59 |
nrzkt |
but i tell what i think, so rude i am, but the problem was here, i found it and you prefer lost time to dialog instead of fixing the problem. |
| 16:59 |
crazyR |
why does it not fit. you siad that all other apps do it so we should |
| 16:59 |
crazyR |
its the asame thing as me leaving my door unlocked because my nabout does |
| 17:00 |
sfan5 |
crazyR: no, it's not |
| 17:00 |
crazyR |
lmao |
| 17:00 |
sfan5 |
leaving the front door unlocked would be having the clear text password stored somewhere where everyone can access it |
| 17:00 |
sfan5 |
crazyR: also i said that every other program does _not_ do it |
| 17:01 |
crazyR |
same diffrence they dont do it so we dont do it.. il reverse it for you so its easier to understand: my nabout does not lock his door. so i should not lock my door? better? |
| 17:02 |
nrzkt |
the fix the other ways too sfan5 instead of searching the beast. Everybody will be happy |
| 17:02 |
nrzkt |
then* |
| 17:02 |
sfan5 |
nrzkt: there are infinite other ways |
| 17:02 |
sfan5 |
nrzkt: such as replacing the executable, how do we fix that? |
| 17:02 |
nrzkt |
no. |
| 17:02 |
nrzkt |
they are finite, it's a program. |
| 17:02 |
crazyR |
yes but fixing one way is better than not fixing any way |
| 17:03 |
nrzkt |
i don't patch a replaced executable because i don't patch it. |
| 17:03 |
Krock |
So, I've got a really annoying bug. Whenever I play on my server (via local network), then it takes 5 - 30 minutes and the wireless network collapses |
| 17:03 |
sfan5 |
crazyR: i already said that the unlocked door analogy is not good |
| 17:03 |
|
hmmmm joined #minetest-dev |
| 17:03 |
nrzkt |
you're not good. |
| 17:03 |
Krock |
this didn't happen some months ago and I hope this can be fionxed soon, so I can play on my own server again |
| 17:04 |
sfan5 |
again: insulting me does not get your PR merged faster |
| 17:04 |
Krock |
*fixed |
| 17:04 |
nrzkt |
#2243 must be merged because it fix ONE security issue, not all, YES, but one is better than ZERO |
| 17:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/2243 -- Security Fix: Empty the password after sending it to server by nerzhul |
| 17:04 |
sfan5 |
Krock: do the packets go to your router? |
| 17:04 |
crazyR |
sfan if you are going to use the reason "other apps dont do it so we wont" then is the same and is well suited |
| 17:04 |
sfan5 |
Krock: (before going to the mt server) |
| 17:04 |
Krock |
sfan5, yup, there's no other way |
| 17:04 |
sfan5 |
Krock: well.. if you were playing on 127.0.0.1 they wouldn't exit your machine |
| 17:04 |
sfan5 |
Krock: in that case your router probably has problems with udp |
| 17:05 |
Krock |
sfan5, as already said. It worked fine some months ago. I've build weeks on that server, mostly with over 10 people online |
| 17:05 |
sfan5 |
Krock: was your router updated in that time? |
| 17:06 |
Krock |
there was no update |
| 17:06 |
sfan5 |
no idea then |
| 17:06 |
sfan5 |
crazyR: other applications don't do this for a reason, doing that does not prevent other people from getting your password; it's not worth to do this |
| 17:10 |
crazyR |
lol sfan5 its this sort of attitude that caused heartbleed and others. granted this is in no way even a fraction a severe... yet. but the fact that all it takes is a website designed to make use of this means that an attacker wouldnt even need to have access to the pc itself. |
| 17:10 |
sfan5 |
lolwat |
| 17:11 |
sfan5 |
heartbleed was caused by an oversight |
| 17:11 |
sfan5 |
now by a developer not accepting pointless fixes |
| 17:11 |
sfan5 |
not* |
| 17:11 |
sfan5 |
crazyR: also it's not "simply a website" to access some memory in a different process |
| 17:11 |
Krock |
nrzkt, how about setting it to "null" or some foobar text? |
| 17:11 |
sfan5 |
you don't simply bypass aslr, dep and browser sandboxes |
| 17:13 |
crazyR |
nrzkt just clearly siad that he can obtain the password from memory using a website, yes? so by not merging this fix you are turning this into a oversight. and ok i understadn a website couldnt do it that easy. so how about an amazing new toolbar extention for a browser that is advertised targeted towards minetest platyers. |
| 17:14 |
sfan5 |
crazyR: don't say anything before you understood how exploitation works |
| 17:15 |
sfan5 |
crazyR: a browser toolbar can't just read the memory of a different process either |
| 17:15 |
nrzkt |
on windows it's easiest than UNIX, yes |
| 17:16 |
sfan5 |
nrzkt: please tell me which browser allows toolbars to read other processes memory |
| 17:16 |
nrzkt |
IE ? |
| 17:17 |
sfan5 |
who uses IE? |
| 17:17 |
nrzkt |
because their sandbox suxes |
| 17:17 |
nrzkt |
windows users |
| 17:17 |
crazyR |
lmao |
| 17:17 |
Krock |
programs which read other's memory is a type of a spy-virus or whatever. antivirus does not like those |
| 17:17 |
nrzkt |
and maybe some minetest users |
| 17:17 |
est31 |
Its not just about reading other processes' memory, its also about reading the memory of already closed processes. |
| 17:17 |
est31 |
thats far more easier |
| 17:17 |
crazyR |
who uses ie? seriously |
| 17:17 |
hmmmm |
i don't see malware scanning process memory for minetest passwords... i'm sorry |
| 17:17 |
est31 |
just make the process allocate everything it gets and then search for minetest structures |
| 17:18 |
hmmmm |
minetest is not that important it's a god damn game |
| 17:18 |
hmmmm |
and that patch doesn't even accomplish what it supposedly does |
| 17:18 |
sfan5 |
est31: how do you read memory from exited processes? |
| 17:18 |
nrzkt |
no, but somes can set a common password between minetest and websites, and hash could be cracked, because it's open source, using rainbow tables. |
| 17:18 |
Krock |
I could understand this problem if we had global usernames and passwords but currently we shouldn't make trouble for nothing |
| 17:19 |
est31 |
sfan5: by allocating it without writing to it |
| 17:19 |
hmmmm |
nobody uses a common password |
| 17:19 |
est31 |
when they close, its freed |
| 17:19 |
hmmmm |
all my minetest server passwords are "asdf" |
| 17:19 |
est31 |
so you just need to convince the OS that you need the memory |
| 17:19 |
crazyR |
hmmmm actually most "average" users do use a common pasword |
| 17:19 |
hmmmm |
it's a game and it just doesn't matter. the password is necessary but nobody cares |
| 17:19 |
sfan5 |
est31: doesn't the kernel zero newly allocated memory |
| 17:19 |
sfan5 |
? |
| 17:19 |
hmmmm |
because it's JUST A GAME |
| 17:20 |
est31 |
not that I knew |
| 17:20 |
hmmmm |
in any case |
| 17:20 |
nrzkt |
just a game doesn't mean, do stupid code |
| 17:20 |
nrzkt |
it's not EA or ubisoft :p |
| 17:20 |
hmmmm |
provide me a patch that actually clears the password memory and I'll accept it |
| 17:20 |
nrzkt |
we need a custom allocator, then ^^ |
| 17:20 |
sfan5 |
est31: https://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx "Memory allocated by this function is automatically initialized to zero" |
| 17:20 |
nrzkt |
because std::string sucks a little for that |
| 17:21 |
sfan5 |
est31: same for all other functions |
| 17:21 |
est31 |
reading this http://stackoverflow.com/questions/6004816/kernel-zeroes-memory |
| 17:21 |
Calinou |
<+sfan5> who uses IE? |
| 17:21 |
est31 |
you seem to be right |
| 17:21 |
Calinou |
25-40 % of the Internet |
| 17:21 |
Calinou |
that is gigantic |
| 17:21 |
hmmmm |
the kernel zeroing memory hides a lot of bugs |
| 17:21 |
sfan5 |
est31: thats for linux though |
| 17:21 |
Calinou |
if you like sarcasm about IE, then you might enjoy sarcasm about Firefox… |
| 17:22 |
hmmmm |
the majority of drivers i suspect never set Irp->IoStatus->Information = 0; before completing an irp |
| 17:22 |
hmmmm |
but they're OK because the kernel zeros out all the data structures |
| 17:22 |
sfan5 |
you read driver source code, hmmmm? |
| 17:22 |
hmmmm |
I write drivers for my day job |
| 17:23 |
sfan5 |
i see |
| 17:25 |
hmmmm |
lol there was this one bug |
| 17:25 |
kahrl |
fwiw, I tend to agree that the password should be cleared (not so much because someone could read the process memory, if that happens you're already fucked, but because I've seen several backtraces with hashed passwords included) |
| 17:25 |
kahrl |
but # 2243 is not the right way to do it |
| 17:26 |
nrzkt |
ofc, std::string sucks ... i looked at this |
| 17:26 |
hmmmm |
some guy was writing back a result to UserMemory in a DO_BUFFERED ioctl |
| 17:26 |
nrzkt |
a custom allocator is needed |
| 17:26 |
hmmmm |
and he never set the information |
| 17:26 |
hmmmm |
so the KernelBuffer result was never written back and no bug was ever found |
| 17:26 |
hmmmm |
but the driver kept overwriting random processses' memory |
| 17:26 |
sfan5 |
ow |
| 17:27 |
hmmmm |
i think allocated memory should be set to something like 0xCC instead |
| 17:54 |
celeron55 |
i actually have a custom allocator wrapper in buildat on linux that absolutely always clears memory with patterns: https://github.com/celeron55/buildat/blob/master/src/boot/linux/cmem.c |
| 17:55 |
celeron55 |
i became a bit worried and fed up with memory problems especially as that thing uses a lua sandbox that runs code coming from the server 8) |
| 17:57 |
celeron55 |
also, the kernel does clear memory that it hands to a different process than it previously belonged to; otherwise it would be an absolute security hazard (but apparently it clears to 0, which causes a lot of bugs like hmmmm said) |
| 17:57 |
celeron55 |
that also enables quite silly tricks that became quite useful |
| 17:57 |
celeron55 |
the buildat thing, i mean |
| 17:59 |
est31 |
buildat is a remake of minetest? |
| 17:59 |
celeron55 |
not really |
| 18:00 |
est31 |
do you use it together with minetest then? |
| 18:01 |
celeron55 |
you could use it for implementing a remake of minetest if you wanted to |
| 18:01 |
celeron55 |
as-is it's quite barebones and nobody (including me) is using it for anything |
| 18:01 |
est31 |
why did you start it? |
| 18:01 |
celeron55 |
i wanted to see where it would go |
| 18:01 |
celeron55 |
turns out doing a thing like that is a lot of work for no reward whatsoever |
| 18:02 |
celeron55 |
(except the learning, but at that point there wasn't that much to learn anymore) |
| 18:04 |
* est31 |
does git clone ... |
| 18:05 |
celeron55 |
it would probably need a bit of redesign to be actually worth using; at least stripping out the bloated threading system that i did to see where that would go |
| 18:06 |
celeron55 |
if someone finds messing around with it fun as-is, i might continue working on it |
| 18:06 |
est31 |
client side lua, tcp, lots of cool things |
| 18:07 |
est31 |
serverside c++ thats compiled on the runtime, does the thing have a compiler as dependency? |
| 18:07 |
celeron55 |
yes it does |
| 18:08 |
celeron55 |
it's ridiculous but works |
| 18:09 |
celeron55 |
it's definitely not for outdated computers in any way whatsoever |
| 18:09 |
est31 |
because of the compiler, or is there something else too? |
| 18:09 |
est31 |
clientside too? |
| 18:09 |
celeron55 |
urho3d requires opengl 2, the with-compiler windows binary package is something like 100MB |
| 18:09 |
|
SopaXorzTaker joined #minetest-dev |
| 18:09 |
|
prozacgod joined #minetest-dev |
| 18:09 |
hmmmm |
celeron55: the custom allocator isn't guaranteed to work though |
| 18:10 |
est31 |
oh |
| 18:10 |
hmmmm |
there's an optimization to omit allocations altogether for small strings |
| 18:10 |
hmmmm |
there is no way to securely zero a std::string.. it's just not the right container to use |
| 18:11 |
celeron55 |
est31: the client-only build doesn't need the compiler though |
| 18:11 |
est31 |
yea guessed so |
| 18:11 |
hmmmm |
celeron55, the system idle process has a task that zeros recently freed pages |
| 18:12 |
celeron55 |
est31: 100MB is not large compared to modern game engines or games though |
| 18:12 |
celeron55 |
MT is just such a minimalist project in the end |
| 18:13 |
est31 |
yes of course. I know of somebody who uses MT on a 2005 PC |
| 18:13 |
VanessaE |
celeron55: bundle dreambuilder with MT and you're half-way there ;) |
| 18:13 |
Calinou |
dreamtest |
| 18:13 |
est31 |
db has ~70 MB (including git history) |
| 18:14 |
VanessaE |
est31: 94MB with history, 52MB without |
| 18:15 |
est31 |
maybe, my copy has alot of symlinks to repos I write mods for. |
| 18:15 |
VanessaE |
really though, size of an engine isn't a particularly good indicator of its quality |
| 18:16 |
est31 |
I guess the compiler doesn't have to be loaded into mem. |
| 18:16 |
celeron55 |
but i mean, if there's somebody in here who doesn't find stupidly huge programs a problem and likes the ridiculous flexibility aspect of minetest interesting or entertaining, buildat is for you |
| 18:16 |
est31 |
only if its compiling |
| 18:19 |
celeron55 |
the compiling works so that there's simply a stripped-down mingw in a subdirectory that is called |
| 18:19 |
celeron55 |
or on linux it just uses the system one |
| 18:20 |
est31 |
lol compiling errors in stdout... something to grow accustomed to... |
| 18:21 |
celeron55 |
i think i do need to somehow get buildat into a stable state, probably by stripping it down more to get rid of the badly designed interfaces |
| 18:21 |
celeron55 |
currently i'm afraid of pushing it to users too much as it will have to change in order to be good |
| 18:22 |
celeron55 |
someone else, go finish it; i'm too busy with other things |
| 18:26 |
|
Amaz joined #minetest-dev |
| 18:28 |
est31 |
Is there support for a moving player yet, or is that for things the mods have to do? |
| 18:28 |
celeron55 |
ehm |
| 18:28 |
est31 |
s/for/to be implemented/ |
| 18:28 |
celeron55 |
no you're not getting the flexibility of buildat at all 8) |
| 18:28 |
celeron55 |
implementing a player is up to mods |
| 18:28 |
celeron55 |
that's where it starts |
| 18:29 |
est31 |
ah |
| 18:29 |
celeron55 |
without mods (which are actually called modules in buildat), what you basically have is a somewhat implicitly networked urho3d engine with automatic C++ compilation |
| 18:30 |
est31 |
so the core engine is quite complete, just with some ugly interfaces, there is no default_game yet? |
| 18:30 |
celeron55 |
there will never be a default game |
| 18:31 |
est31 |
default_game++ |
| 18:31 |
celeron55 |
but there are some examples |
| 18:31 |
est31 |
ah I see in the games folder |
| 18:31 |
VanessaE |
[01-19 03:46] <hmmmm> give me one good reason why we don't dump this for urho3d right now |
| 18:31 |
hmmmm |
i said that when i was POed |
| 18:32 |
VanessaE |
heh |
| 18:34 |
celeron55 |
est31: i mean, if i had no previous game projects that i really want to finish, i would have continued on buildat and made a game using it |
| 18:34 |
celeron55 |
est31: but the thing is, i do, and they cannot be ported to buildat and it would make zero sense whatsoever anyway |
| 18:34 |
est31 |
can minetest be finished? |
| 18:34 |
celeron55 |
no |
| 18:34 |
celeron55 |
it's not one of them |
| 18:36 |
celeron55 |
or you could say that minetest is finished for my part |
| 18:36 |
Calinou |
free software projects are never finished |
| 18:50 |
sofar |
^^ this |
| 18:51 |
est31 |
what are the interfaces that are so ugly? |
| 18:51 |
celeron55 |
ugly doesn't describe them properly |
| 18:52 |
celeron55 |
i mean |
| 18:52 |
celeron55 |
there's stuff like trying to decide what things are in the core and what are not |
| 18:53 |
celeron55 |
and trying to figure out best practices of creating proper interfaces between modules so that they are actually useful |
| 18:53 |
celeron55 |
and trying to figure out how urho3d scenes should be managed |
| 18:53 |
celeron55 |
stuff like that |
| 18:54 |
celeron55 |
it's not a thing like "that line of code is ugly" |
| 18:54 |
est31 |
ok |
| 18:56 |
est31 |
are the server modules sandboxed too? |
| 18:56 |
celeron55 |
not in the slightest |
| 18:56 |
celeron55 |
in the future there might possibly be a layer on top of them running sandboxed lua similarly to the client |
| 18:57 |
celeron55 |
but that's far in the future at this pace |
| 18:57 |
celeron55 |
like, 1000 years i'd say |
| 18:57 |
celeron55 |
many people have asked for server-side lua though |
| 18:58 |
celeron55 |
but they also have asked it to be at a level similar to minetest, which is nothing like what the example games and built-in modules are providing |
| 18:59 |
celeron55 |
and it's not what they should be providing |
| 18:59 |
celeron55 |
that's up to higher ones that don't exist |
| 19:01 |
est31 |
mods can provide lua sandboxes too |
| 19:01 |
est31 |
or js sandboxes |
| 19:02 |
est31 |
or whatever |
| 19:03 |
celeron55 |
yes, but they will miss the opportunity of urho3d directly providing a lua interface (which as to be carefully whitelisted though with a quite complex wrapper) |
| 19:04 |
celeron55 |
which is done on the client |
| 19:04 |
est31 |
the whitelisting is for the sandbox? |
| 19:04 |
celeron55 |
umm? |
| 19:05 |
est31 |
urho3d is also used server side... interesting |
| 19:06 |
celeron55 |
yes, it's used in that way because it has built-in features that allow syncing a scene from the server to the client |
| 19:06 |
celeron55 |
which allows quite MT-like programming (except that it's in C++) |
| 19:07 |
celeron55 |
(also it's possible to add things to the same scene on the client that don't show up to others) |
| 19:09 |
est31 |
does it include stuff like SAOs, or is that up to the mods? |
| 19:09 |
est31 |
or far in the future |
| 19:10 |
celeron55 |
yeah that's in there |
| 19:11 |
celeron55 |
also it already supports VAE's, but that's making other things quite complicated and that's one thing to think about too |
| 19:11 |
celeron55 |
it's implemented in a module though, not in core |
| 19:11 |
celeron55 |
(mostly) |
| 19:11 |
celeron55 |
VAEs* |
| 19:12 |
est31 |
what does V stand for |
| 19:12 |
celeron55 |
VAE isn't a buildat term though, it's "voxel area entity" which is a minetest thing (that doesn't exist in minetest) |
| 19:12 |
Calinou |
voxel area entities |
| 19:12 |
celeron55 |
objects that basically are a freeform chunk of voxels |
| 19:13 |
celeron55 |
with physics |
| 19:13 |
est31 |
so like a ship |
| 19:13 |
celeron55 |
those are there, but then on the other hand map saving isn't there |
| 19:13 |
celeron55 |
which they make less enjoyable |
| 19:13 |
est31 |
their map saving? |
| 19:13 |
est31 |
or saving at all |
| 19:13 |
celeron55 |
saving at all |
| 19:14 |
celeron55 |
in the current voxel world implementation every voxel is part of a VAE; some of them are just at static positions to make up the main landmass |
| 19:14 |
est31 |
ok |
| 19:14 |
celeron55 |
let me look up the actual buildat term for these... |
| 19:14 |
est31 |
so VAEs can be as huge as they want |
| 19:15 |
celeron55 |
in buildat they are called "dynamic voxel nodes" |
| 19:15 |
celeron55 |
or "voxel nodes" |
| 19:15 |
celeron55 |
static voxel node would be those that don't move |
| 19:16 |
celeron55 |
est31: well large ones aren't efficient to edit |
| 19:16 |
celeron55 |
but they can be quite large |
| 19:17 |
celeron55 |
i mean, it's not some kind of magical thing that ends world poverty, but it's a lot more impressive than minetest if you ask me |
| 19:18 |
celeron55 |
it just... needs a whole lot of work by capable programmers |
| 19:18 |
celeron55 |
and that's the thing that is hard to come by |
| 19:19 |
est31 |
yea |
| 19:19 |
|
shadowzone joined #minetest-dev |
| 19:19 |
est31 |
dunno whether I'm capable, guess not |
| 19:19 |
celeron55 |
if you can understand the existing code, it's likely enough |
| 19:20 |
est31 |
and: dunno how much time I can invest |
| 19:20 |
celeron55 |
yeah that's the actual problem |
| 19:20 |
celeron55 |
for me too |
| 19:21 |
celeron55 |
i'm not really willing to put time into something that i am not sure won't teach me a lot of things or which won't deliver something useful to a lot of users |
| 19:21 |
celeron55 |
at this point buildat is still quite a "well it might end up being interesting" project |
| 19:22 |
est31 |
just like me |
| 19:22 |
est31 |
with minetest, I have something that actually works |
| 19:22 |
est31 |
and has users |
| 19:23 |
hmmmm |
VAEs already exist in mods as clumps of SAOs that move together at once |
| 19:23 |
hmmmm |
I hate it |
| 19:23 |
celeron55 |
i don't really expect anyone to start using buildat before i have made something using it |
| 19:23 |
hmmmm |
in any case, where do we store VAEs? in the database? |
| 19:23 |
celeron55 |
if i end up doing so, then i do expect that people will want to see what they can do with it too |
| 19:24 |
celeron55 |
but that hasn't happened |
| 19:24 |
est31 |
I could try working on buildat_game... but when the API gonna change... |
| 19:24 |
celeron55 |
hmmmm: i'm sticking with my proposition of just allocating an unused edge of the world for them |
| 19:24 |
celeron55 |
hmmmm: and you will be sticking with hating that |
| 19:25 |
hmmmm |
I never understood the point of the "position hash" |
| 19:25 |
hmmmm |
you're using a lot of unused bits for pretty much no reason at all |
| 19:25 |
celeron55 |
wtf are you now referring to |
| 19:25 |
hmmmm |
if we fix that we can reserve a special bit in the key that says "this is a VAE" |
| 19:26 |
hmmmm |
celeron55: before you jump to "WTF are you talking about", try waiting for the rest of the statement (or think harder) |
| 19:26 |
hmmmm |
you'd come off as less abrasive that way |
| 19:27 |
celeron55 |
? |
| 19:27 |
celeron55 |
so where is the rest of the statement |
| 19:27 |
hmmmm |
the position hash used as the primary key in the map database |
| 19:28 |
celeron55 |
lol what |
| 19:28 |
hmmmm |
this makes your proposition of "allocating an unused edge" way more managable |
| 19:28 |
hmmmm |
it would be easy to extract them this way |
| 19:28 |
celeron55 |
databases have columns, you don't need some kind of special bits |
| 19:28 |
hmmmm |
true, but what about leveldb |
| 19:28 |
hmmmm |
or other things that are really just dumb key-value stores |
| 19:28 |
celeron55 |
and you shouldn't be using special bits (or hashes like i did when i didn't know sqlite3 supports multiple indices) as databases can't index them properly |
| 19:29 |
celeron55 |
hmmmm: they have strings as keys |
| 19:29 |
hmmmm |
so do you suppose using a separate database file or something? |
| 19:29 |
* hmmmm |
scratches head |
| 19:29 |
hmmmm |
erm... s/suppose/propose/ |
| 19:30 |
celeron55 |
you don't have to have a position as the key for everything in leveldb |
| 19:30 |
celeron55 |
you can just have "vae142" or something |
| 19:30 |
celeron55 |
that's how leveldb is intended to be used |
| 19:30 |
hmmmm |
oh, that's more flexible. |
| 19:31 |
celeron55 |
in sql you should really have a separate table for VAEs |
| 19:31 |
celeron55 |
if one is going for the same kind of structure as that would make in leveldb |
| 19:31 |
hmmmm |
no, I think we should use a separate database file completely |
| 19:31 |
hmmmm |
that way you can easily move them from world to world |
| 19:32 |
est31 |
databases also have tables |
| 19:32 |
celeron55 |
not going to work; people are going to want to add them, not replace them |
| 19:32 |
hmmmm |
?? |
| 19:32 |
hmmmm |
not sure I understand |
| 19:32 |
celeron55 |
and they will have incompatible positions in the world with the main world voxels and whatnot |
| 19:32 |
hmmmm |
oh no |
| 19:32 |
hmmmm |
they'll be stored on the map by reference |
| 19:33 |
celeron55 |
the main gameplay with VAEs that i am thinking is that each of them is unique and built from the ground up in-place |
| 19:33 |
celeron55 |
you're thinking of some kind of model database |
| 19:33 |
celeron55 |
where things can be just picked from |
| 19:34 |
hmmmm |
I thought about how I want to do this and I think the most sane way is to load/store the VAEs in a separate DB, somebody can build a structure on the map using regular mapnodes, then when somebody hits the "turn into VAE" button it'd store it as a model |
| 19:34 |
hmmmm |
and then create a SAO of it |
| 19:34 |
|
rubenwardy joined #minetest-dev |
| 19:34 |
hmmmm |
the downside is you won't be able to build it or whatever while your boat is moving or whatever but it's much more managable this way |
| 19:35 |
celeron55 |
i think you should be able to build on it, and run mesecons on it and whatnot, eventually |
| 19:35 |
celeron55 |
but at first not being able to do that would be fine |
| 19:35 |
hmmmm |
well no it's not fine |
| 19:35 |
hmmmm |
because that would demand a fundamentally different model of how it functions |
| 19:35 |
hmmmm |
so you'd need a rewrite |
| 19:35 |
celeron55 |
not in how i've planned it |
| 19:36 |
celeron55 |
maybe you planned something that isn't suitable for that 8) |
| 19:36 |
hmmmm |
how did you plan it? |
| 19:36 |
hmmmm |
you already did this with buildat no? |
| 19:36 |
celeron55 |
buildat != minetest |
| 19:36 |
celeron55 |
and i don't see what's so fundamental about thtis |
| 19:36 |
celeron55 |
this* |
| 19:37 |
hmmmm |
I don't know I can just see lots of problems |
| 19:37 |
hmmmm |
like how are you going to get pointed_at if it's technically part of the map |
| 19:37 |
hmmmm |
maybe I haven't thought hard enough about all this |
| 19:38 |
celeron55 |
i see a lot of problems too; in minetest for example APIs are kind of not designed for them |
| 19:38 |
hmmmm |
well it's a large feature, I'm sure there would be currently unknown obstacles with any approach |
| 19:38 |
celeron55 |
but then again, mapping them in the same voxel 3D space to a different location solves it |
| 19:39 |
hmmmm |
and then |
| 19:39 |
hmmmm |
what about the problem of uniqueness |
| 19:39 |
hmmmm |
nevermind, that's easily solved |
| 19:40 |
hmmmm |
so we just tack on a boolean "is_vae_target" to set_node/get_node/swap_node? |
| 19:40 |
celeron55 |
if you don't want to simply map them to the same 3D world, then please not that solution |
| 19:41 |
celeron55 |
more like including vae=number in positions |
| 19:41 |
celeron55 |
this is not a good reason to make APIs look ugly |
| 19:41 |
hmmmm |
if we add another field to positions then we can throw realms in just as well |
| 19:42 |
celeron55 |
well if somebody is willing to implement all that, i guess so |
| 19:43 |
hmmmm |
i would if i had free time |
| 19:43 |
hmmmm |
I realize a lot of my ideas are stupid but I haven't given this much serious thought |
| 19:43 |
VanessaE |
if you were to "throw realms in", how would you implement them? additional map databases? |
| 19:44 |
hmmmm |
if we did it the celeron way(tm) then it'd be an additional column in the composite key mapping to the block data |
| 19:45 |
hmmmm |
there's really not a better way of doing this |
| 19:45 |
hmmmm |
it's something that's stupid and simple |
| 19:45 |
hmmmm |
and works |
| 19:45 |
celeron55 |
i do wish i would have been long-sighted enough to having thrown that stuff into APIs and databases much earlier... but back then even the basic idea of 0.4 was a stretch 8) |
| 19:45 |
VanessaE |
Occam's Razor. |
| 19:46 |
hmmmm |
and I nearly forgot about that pull request that splits up the block positions into x y and z |
| 19:47 |
hmmmm |
it's a lot of work, i'm sure, but the API bit doesn't seem to be overly difficult |
| 19:47 |
hmmmm |
we'd have to modify push_v3f and read_v3f to read the realm/vae/whatever ID and rename it |
| 19:48 |
celeron55 |
the extended position is going to be an issue because people do a lot of u = {x=v.x, y=v.y, z=v.z} style stuff |
| 19:48 |
hmmmm |
yeah so? |
| 19:48 |
celeron55 |
but i guess it's fairly easy to fix in mods |
| 19:48 |
hmmmm |
what's wrong with assuming if the realm ID is blank or 0 you're referring to the primary map |
| 19:49 |
celeron55 |
yeah but if the VAE has a node that wants to place a node next to itself, boom |
| 19:49 |
est31 |
you could make core code smart |
| 19:49 |
celeron55 |
sounds like even more obscure errors |
| 19:50 |
est31 |
if core gets a position where the vae number is not set it checks whether the call has been made by code belonging to some node |
| 19:50 |
est31 |
and checks the realm of that node |
| 19:50 |
celeron55 |
you can't really generally know the answer to that check |
| 19:50 |
celeron55 |
there are a lot of callbacks and whatnot |
| 19:54 |
est31 |
there should be a mechanism that ensures you cannot start a server with vae support with mods that don't have vae support |
| 19:56 |
|
decimalguy joined #minetest-dev |
| 19:58 |
est31 |
or you get a warning |
| 19:59 |
hmmmm |
maybe we can have each mod expose variables like |
| 19:59 |
hmmmm |
is_vae_aware = true |
| 20:00 |
hmmmm |
celeron55: I see what you mean now, like for example a grow_something ABM that runs on it |
| 20:00 |
hmmmm |
that wasn't written for voxel area entities |
| 20:00 |
hmmmm |
wait guys wait |
| 20:00 |
hmmmm |
I can only work on one huge thing at a time |
| 20:01 |
hmmmm |
what's more important, this or client-side modding? |
| 20:01 |
hmmmm |
and I can hardly even work on little things because I have real life too |
| 20:04 |
Tesseract |
hmmmm: I'd say client-side mods. Make sure it plays well with my security patch though. |
| 20:04 |
est31 |
security patch? |
| 20:05 |
hmmmm |
well |
| 20:05 |
VanessaE |
I'd say client-side modding as well, of the two |
| 20:05 |
|
Topic for #minetest-dev is now FEATURE FREEZE FOR 0.4.12 IN EFFECT. Release date: soonâ„¢ | Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 20:05 |
hmmmm |
security on client-side modding is going to be a bit different from server side |
| 20:05 |
hmmmm |
obviously it needs to be super-sandboxed |
| 20:06 |
Tesseract |
est31: #1606 |
| 20:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/1606 -- Add mod security by ShadowNinja |
| 20:06 |
est31 |
chrome does own locked down processes with IPC |
| 20:06 |
Tesseract |
hmmmm: That ^ with minor changes to isPathAllowed(or whatever I named it) should be secure for the client too. |
| 20:07 |
Tesseract |
I'd look over all the whitelisted functions first though of course. |
| 20:13 |
est31 |
even if you moved clientlua into its own process, that would only save from luajit exploits |
| 20:25 |
|
nore joined #minetest-dev |
| 20:29 |
est31 |
hmmmm: initial client side modding, what should it be abled to do? |
| 20:29 |
est31 |
just formspecs or things like world manipulation too |
| 20:29 |
VanessaE |
flip a door open, move a MOB, that sorta thing. |
| 20:30 |
est31 |
craft guides can be client side... |
| 20:31 |
celeron55 |
put client-side entities into the world to show custom stuff |
| 20:31 |
celeron55 |
(without showing it to other players) |
| 20:32 |
celeron55 |
i mean, irrlicht scene nodes |
| 20:32 |
est31 |
ok nice |
| 20:32 |
celeron55 |
the thing here is, as these features get wider and wider, the attack surface gets huge |
| 20:33 |
celeron55 |
you need to be programming this like a cryptography library |
| 20:33 |
est31 |
just leave the APIs the server can access |
| 20:33 |
est31 |
thats enough for the start |
| 20:33 |
|
prozacgod joined #minetest-dev |
| 20:33 |
est31 |
so when a server already can manipulate the nodes, let clientside lua modiffy that too |
| 20:34 |
|
prozacgod joined #minetest-dev |
| 20:34 |
celeron55 |
hmm |
| 20:35 |
celeron55 |
should the access be unified so that client-side lua actually does use the same interface what the server sees through network |
| 20:35 |
|
shadowzone_ joined #minetest-dev |
| 20:35 |
celeron55 |
that would indeed minimize the addition of attack surface, but it might be a weird system |
| 20:35 |
est31 |
mostly yes, at least my opinion |
| 20:36 |
celeron55 |
hmmmm: if you're going to do this, give a few thoughts to this too; it might even give us a better server-side api simultaneously if it turns out to be a good idea |
| 20:36 |
est31 |
but you would need shared stuff by the "actual client", and the clientlua, like the structures that keep the nodes |
| 20:37 |
est31 |
unless you want to duplicate it |
| 20:37 |
celeron55 |
i'm not too sure that it would be a good idea |
| 20:37 |
|
acerspyro joined #minetest-dev |
| 20:37 |
celeron55 |
anyway, everything is worth looking at before doing any complicated work |
| 20:39 |
|
prozacgod joined #minetest-dev |
| 20:41 |
|
prozacgod joined #minetest-dev |
| 20:44 |
est31 |
Tesseract: why is the PR not merged yet? |
| 20:47 |
Tesseract |
est31: Because I haven't gotten approval from two other devs yet. |
| 20:47 |
est31 |
ok |
| 20:48 |
Tesseract |
And it can't go in now unless we make a release branch. |
| 20:48 |
Tesseract |
My sqlite3-pos-split branch actually includes a number of fixes to local map saving. |
| 20:48 |
est31 |
yea freeze |
| 20:50 |
Tesseract |
If anyone wants to test either of those things (sqlite3-pos-split or security) that would be great. |
| 20:50 |
est31 |
gonna try to get out of the sandbox :) |
| 20:51 |
est31 |
and start dreambuilder with it. |
| 20:53 |
Tesseract |
est31: datastorage (used by unified_inventory if available) might break. Change the os.execute("mkdir"...) hack to core.mkdir(...) if so. I have a patch that makes it compatible with both methods but it isn't pushed yet. |
| 20:54 |
Tesseract |
WE has a similar issue, but only if you use one of the "/save*" commands. |
| 20:54 |
est31 |
is the sandbox also enabled for the mainmenu lua? |
| 20:54 |
nrzkt |
why release date is unilateral from 1 dev , |
| 20:54 |
nrzkt |
? |
| 20:57 |
Tesseract |
est31: IIRC it isn't. It wouldn't really hurt if it was though. |
| 20:58 |
est31 |
just asking, I've made a mod for the mainmenu, and that accesses the fs. |
| 20:58 |
est31 |
-> https://forum.minetest.net/viewtopic.php?f=14&t=11116 |
| 20:59 |
nrzkt |
it's not normal. |
| 20:59 |
nrzkt |
mods mustn't have access to real FS |
| 20:59 |
nrzkt |
and they mustn't send real commands into the server |
| 21:13 |
Tesseract |
LOL, I remember someone proposed adding strgettext as wide_to_narrow(wstrgettext(str)) -- that's wide_to_narrow(std::wstring(narrow_to_wide(gettext(str)).c_str())). -- char* -> wstring -> wchar* -> wstring -> string. |
| 21:14 |
shadowzone_ |
did it get merged or even work? |
| 21:14 |
* Tesseract |
will now increase translation speed 10x ;-) |
| 21:23 |
|
nore joined #minetest-dev |
| 21:23 |
|
ImQ009 joined #minetest-dev |
| 21:39 |
|
shadowzone joined #minetest-dev |
| 21:46 |
|
MichaelRpdx joined #minetest-dev |
| 22:25 |
|
MinetestForFun joined #minetest-dev |
| 22:27 |
|
harrison joined #minetest-dev |
| 22:59 |
|
shadowzone joined #minetest-dev |
| 23:06 |
|
decimalguy left #minetest-dev |
| 23:53 |
|
shadowzone joined #minetest-dev |
| 23:58 |
|
shadowzone joined #minetest-dev |
