348
Ente - Open sourcing our server
(ente.io)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 01 Mar 2024
348 points (97.8% liked)
Selfhosted
40749 readers
474 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
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:
here is my original comment
This would be nice, but, this repo includes an iOS app, and AGPL3 binaries cannot be distributed via Apple's App Store!
AGPL3 (without a special exception for Apple, like NextCloud's iOS app has) is incompatible with iOS due to the four paragraphs of the license which mention "Installation Information" (known as the anti-tivoization clause).
Only the copyright holder(s) are able to grant Apple permission to distribute binaries of AGPL3-licensed software to iOS users under non-AGPL3 terms.
Every seemingly-(A)GPL3 app on Apple's App Store has either copyright assignment so that a single entity has the sole right to distribute binaries in the App Store (eg, Signal messenger) or uses a modified license to carve out an Apple-specific exception to the anti-tivoization clause (eg, NextCloud). In my opinion, the first approach is faux free software, because anyone forking the software is not allowed to distribute it via the channel where the vast majority of users get their apps. (In either case, users aren't allowed to run their own modified versions themselves without agreeing to additional terms from Apple, which is part of what the anti-tivoization clause is meant to prevent.)
I definitely agree here! But if it's true that they're accepting contributions without a CLA, and they haven't added any iOS exception to their AGPL3 license, then they themselves would not be allowed to ship their own iOS app with 3rd party contributions to it! 😱 edit: it's possible this is the case and Apple just hasn't noticed yet, but that is not a sustainable situation if so.
If anyone reading this uses this software, especially on iOS, I highly recommend that you send the developers a link to this comment and encourage them to (after getting the consent of all copyright holders) add something akin to NextCloud's COPYING.iOS to their repository ASAP.
cc @ioslife@lemmy.ml @baduhai@sopuli.xyz @skariko@feddit.it
(i'm not a lawyer, this is not legal advice, lol)
edit: in case a dev actually sees this... skimming your architecture document it looks like when a user's email is compromised ("after you successfully verify your email"), the attacker is given the
encryptedMasterKey(encrypted withkeyEncryptionKey, which is derived from a passphrase) which lets them perform an offline brute-force attack on the passphrase. Wouldn't it make more sense to require the user to demonstrate knowledge of their passphrase to the server prior to giving them theencryptedMasterKey? For instance, when derivingkeyEncryptionKey, you could also derive another value which is stored on the server and which the client must present prior to receiving theirencryptedMasterKey. The server has the opportunity to do offline attacks on the passphrase either way, so it seems like there wouldn't be a downside to this change. tldr: you shouldn't let adversaries who have compromised a user's email account have the ability to attack the passphrase offline.(i'm not a cryptographer, but this is cryptography advice)
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 theencryptedMasterKey. This can be derived in a similar fashion to thekeyEncryptionKey(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
loginSecretfrom the server but has not obtained theirencryptedMasterKey: in that case they could use it to request theencryptedMasterKey, and then could make offline guesses at the passphrase using that. But, they could also just use theloginSecretfor 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 theloginSecretin 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.
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).
It turns out, they do have a CLA (with full copyright assignment 😢).