1y ago

Ente - Open sourcing our server

ente.io

Open sourcing our server

cross-posted from: https://lemmy.ml/post/12624334

Ente - Open sourcing our server

Free and Open Source Software @beehaw.org

ioslife @lemmy.ml

1y ago

Ente - Open sourcing our server

ente.io /blog/open-sourcing-our-server/

Le Alternative @feddit.it

skariko @feddit.it

1y ago

ente diventa interamente open source (anche il server)

ente.io /blog/open-sourcing-our-server/

56 comments

AGPL-3.0
Nice
- I'm trying to learn about licensing. Why do you like AGPL-3.0 compared to others?
  
  The AGPL applies copyleft to web services. If you're learning about licensing, it might be worth googling copyleft. Fascinating concept, and, in my opinion, something to subscribe to.
  
  If you haven't already, check out https://choosealicense.com/licenses/ . This gives a broad overview of the common open source licenses. And if you're just starting out, one of the first things you'll want to learn is that the licenses fall into either a permissive or copyleft category. You'll want to make sure you understand the difference between those broad categories.
  Shortly, permissive have less to no strings attached to use their code, and copyleft requires you to retain the same licensing terms meaning if you publish under GPLv3 then someone using/ modifying your code needs to also publish under GPLv3. Copyleft licenses ensure that open source code stays open source.
  
  In very basic terms - GPL means that any modifications you make to a code base and distribute to public, you need to keep the license as GPL and open source all your modifications.
  Once cloud started becoming a thing, the cloud vendors went "Well ackchyually🤓, the code changes we're making are hosted on OUR server so we're not technically distributing them to the public. So fuck you we have no obligation to make them open source".
  Which is why AGPL exists so even server side code needs to be public. Since the application in question here is a backend service, it'll always be used server side and so any forks need to be open source.
- as should be
- Only really nice when not CLA is required and every contributor retains their copyright. Ente doesn't seem to require a CLA.
  Otherwise it allows the owner to just take the changes from their contributors and change the license at a later date.
  
  edit: the two issues i raised in this comment had both already been addressed.
  this was the developer's reply on matrix:
  We do have a CLA: https://cla-assistant.io/ente-io/ente
  We will update the iOS app to offer you an option to point to your self hosted instance (so that you can save yourself the trouble of building it): https://github.com/ente-io/ente/discussions/504
  The portion of the document that deals with authentication has been outdated, my bad. We've adopted SRP to fix the concerns that were pointed out: https://ente.io/blog/ente-adopts-secure-remote-passwords/
  
  That's complicated to do correctly. Normally, for the server to verify the user has the correct password, it needs to know or receive the password, at which point it could decrypt all the user's files. They'd need to implement something like SRP.
  
  That’s complicated to do correctly. Normally, for the server to verify the user has the correct password, it needs to know or receive the password, at which point it could decrypt all the user’s files. They’d need to implement something like SRP.
  What I proposed is that the server does not know the password (of course), but that it knows a thing derived from it (lets call it the loginSecret) which the client can send to obtain the encryptedMasterKey. This can be derived in a similar fashion to the keyEncryptionKey (eg, they could be different outputs of an HKDF). The downside to the server knowing something derived from the passphrase is that it enables the server to do an offline brute force of it, but in any system like this where the server is storing something encrypted using [something derived from] the passphrase the server already has that ability.
  Is there any downside to what I suggested, vs the current design?
  And is there some reason I'm missing which would justify adding the complexity of SRP, vs what I proposed above?
  The only reason I can think of would be to protect against a scenario where an attacker has somehow obtained the user's loginSecret from the server but has not obtained their encryptedMasterKey: in that case they could use it to request the encryptedMasterKey, and then could make offline guesses at the passphrase using that. But, they could also just use the loginSecret for their offline brute-force. And, using SRP, the server still must also store something the user has derived from the password (which is equivalent to the loginSecret in my simpler scheme) and obtaining that thing still gives the adversary an offline brute-force opportunity. So, I don't think SRP provides any benefit here.
  
  That sounds kind of like CWE-836.
  
  It is, but in this case I think it isn't actually a weakness for the reasons I explained.
  
  They’d need to implement something like SRP.
  Update: I contacted the developers to bring my comment to their attention and it turns out they have already implemented SRP to address this problem (but they haven't updated their architecture document about it yet).
  
  Ente doesn’t seem to require a CLA.
  It turns out, they do have a CLA (with full copyright assignment 😢).

56 comments