Zalamander
I would be happy to see client-side password hashing implemented.
I understand that responsibility of using unique passwords falls on the user, and maybe a truly malicious instance would be able to remove the hashing (although I think that it would be possible to check if non-hashed passwords leave the client). However, the reality is that many people still re-use their password for many websites and do not use 2FA when not required. Password hashing would reduce the level of trust required of the instance makers.
On a similar vein, it would be nice to anonymize the ip addresses that are printed to the docker logs if possible, similar to the nginx logs. I think that this would be easier to undo for a malicious instance, but at least they would need to have a bit more technical knowledge to get to this information.
I tried to reply from my instance (https://mander.xyz/post/655), but at the moment the federation is not working again. This is what I wrote:
During the day the federation will work during a few hours/minutes, and then it stops working again. For example, if I try to navigate to a lemmy community from my instance at this moment, I get the following dns lookup error:
lemmy_1 | 2021-12-12T12:11:34.411206Z ERROR lemmy_websocket::handlers: Error during message handling error sending request for url (https://lemmy.ml/.well-known/webfinger?resource=acct:[email protected]): error trying to connect: dns error: failed to lookup address information: Try again
Between my and other lemmy instances (forum.purplerabbit.xyz, sopuli.xyz, dissonanz.xyz) federation appears to work fine continuously. I have also tested whether the federation between lemmy and other instances is also not working during the same period time, but they federate just fine. It appears to be a problem specific to my instance.
I have looked a bit into it. In case anyone is curious, I believe that the authorities found the e-mail in question ([email protected]) here:
https://paris-luttes.info/occupation-d-un-local-du-petit-14575?lang=fr
And/or here:
https://radar.squat.net/fr/event/paris/local-du-h/2021-02-24/ag-publique
Thank you!
Thanks! I installed 0.10.2 successfully.
EDIT: /instances does not show up anymore. It seems to also not be working for lemmy.ml
Cool, thanks. I meant the file that is linked in the tutorial on how to update:
https://raw.githubusercontent.com/LemmyNet/lemmy/main/docker/prod/docker-compose.yml
I will wait a bit longer for 0.10.2 then.
Aha, thanks. This might explain the gateway errors I experienced when trying to build using the 10.0.0 image.
I also notice that the docker-compose file still points to the lemmy-ui 0.9.9 - should I build using that version, or should I upgrade my UI image to the 10.0.1?
Last thing - if I pull the released lemmy and lemmy-ui tags (10.1.1) from github now and build my images from those, should those work fine? Or are these untested development versions?
Alright, thanks! I will update to v0.10.0 now and restart iframely.
Thank you!
Interesting perspective!
For me the dislike is not so much about the socialization, but rather the demand for immediate attention that the call requests. I always happen to get calls during work hours in the middle of experiments. I just let it ring and text back later, but I always make sure to take a bit longer than if they had just texted, hehe.
This protects the database from a breach, but someone can set up an instance and collect the passwords from the logs:
As far as I can tell with my very limited experience, back-end encryption is the standard. One trusts the host not to steal their passwords from the logs, so protecting the data in the case of a breach is good enough. I think that it would make sense for the standard in the Fediverse to be different. Passwords should be encrypted by the client by default, and then re-hashed back-end.
It is also possible that what I am saying does not make sense in practical grounds - this is just something that surprised me while looking through the logs. I was under the wrong impression that plain text passwords were never accessible before looking into this topic.