Hello !

When someone connects to my instances communities, but from another instance, how do I know it’s no spoofing involved?

Cheers

  • Loulou@lemmy.mindoki.comOP
    link
    fedilink
    arrow-up
    1
    ·
    11 months ago

    Hello RoundSparrow, and again thank you for your help when I was in trouble setting up my little instance!

    It runs well now :-)

    Just as a backdrop I’m curious about how Lemmy works (I’m building a sharing protocol & implementation, decentralised, takedown safe, rugged, … It feels like how Lemmy is built on top of its protocol) and I love Lemmy and how it “federates” 💗 so I want to know more about it all.

    When you say packages get forwarded to whatever instance wanted (if I understand correctly) you don’t “unpack” (e.g check if it’s a valid request) which seems logic, the end instances does do the security check right? I mean if the end instance doesn’t check, you checking won’t help them out.

    But then again, if I understand you correctly, the trust is split in two; the poster from A posting on B, then B sending all its posts to C, D, E, …

    Which would mean it’s enough to trust B to trust A. If you trust B enough :-)

    Guess I’m off to learn Rust and try to compile all this :-)

    Thanks again, and sorry for the ramblings. It’s late here and I have not very much time.

    • RoundSparrow@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      11 months ago

      I personally would need to dig into testing and code again to give answers with confidence. What I’m trying to say more than anything is… don’t assume. The level of mistakes in Lemmy’s more technical back-end code are pretty high from my experience, especially when it comes to multiple servers involved (comment deletes not being sent to all servers was a situation I tracked down). What I do know is that there is very little written out there about people actually tearing it apart and showing what works… a lot of stuff gets logged in server logs as errors that almost nobody can explain. Either it’s mistakes in apub JSON or other non-lemmy servers, or older versions of Lemmy, etc.

      When you say packages get forwarded to whatever instance wanted (if I understand correctly) you don’t “unpack” (e.g check if it’s a valid request)

      the pack metaphor isn’t that great. But it is signed, and the receiving server checks a signature. But I really have not seen anyone discuss how those signatures are exchanged in the first place, and I’ve seen people say they re-installed their entire instance - which I assume generates a new set of signing keys for the same domain name… and I know Lemmy starts with 1 in index for post, comment, person - and would end up generating the same numbers for different content.

      I haven’t seen much eye towards auditing any of this works, and if it even is a good design. Even 2 months ago there were some aggressive timeouts that were causing delivery to fail. And when something fails, the person who comments or posts doesn’t get notified…

      There is some deep stuff in lemmy., every community has a private key/public key pair, as does each person - but I’m not even sure that is used at all and was an ambition. I rarely see the topic actually come up and I’ve been listening for this kind of deeper technical topics… and created !lemmyfederation@lemmy.ml to try and better organize it.

      Thanks again, and sorry for the ramblings.

      I’m pretty much rambling myself… my repeat point is: don’t assume. I would not describe Lemmy as battle-hardened against attacks or spoofing that someone can find to bypass the current logic.

      • Loulou@lemmy.mindoki.comOP
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        Thanks again, I’m at a new job, it’s summertime, but soon I think I’ll dig into the whole compiling Lemmy thing checking out how it all works :-)

        I’m a huge complexity & somehow network nerd so at least I’m going to see some interesting stuff and Rust seems to be quite abordable for an old-timer.