Are people actually using Seafile? I found it interesting back then, and participated in this discussion but dismissed it as the author didn't really seem to take it serious. His statement:
"I don't quite understand why using a single IV for the whole library is vulnerable to known-plaintext attacks."
That might be an acceptable response if you're trying to build a secure system and don't fully understand your tools yet, not many people do, but it should be followed with an eager question on how to improve. Instead he follows up with:
"I know it's better to use different IV and key for each file/block. But that would greatly increase complexity."
As if that's an excuse. And besides, solutions had been suggested and it's not that complex. Finally he just states that the security improvements are not scheduled.
I do, but I don't use the encrypted libraries. I found it to be way faster than OwnCloud and stayed with it afterwards. No idea whether this changed since.
But I agree that they don't take security as serious as they should. I reported an issue with a deterministically named world readable cache directory (https://forum.seafile-server.org/t/security-security-issue-a...) and suggested that they move it inside the Seafile data directory, as this would allow to run multiple installations beside each other and also prevent races where a different user creates the directory, before Seafile does. The suggestion was dismissed as “/tmp is standard, so we will not change this”.
I solved this issue on my box using SystemD's PrivateTmp feature.
I actually use SeaFile for some clients (since OwnCloud doesn't do client side encryption at all), after Wuala shut down last year. I actually was disappointed by the security and features too (https://forum.seafile-server.org/t/encryption-the-pro-added-...), you cannot securely share sub trees/dirs like in Wuala (with their Cryptree).
Is there a better FOS alternative?
The Wuala service did had a lot's of deadlocks, either on server or the client side, and customer service was not done secure: please send over the log files (included file names) or the client storage block, etc...
In Peergos we are using exactly the cryptree data structure from wuala for our encrypted filesystem on top of ipfs. https://github.com/ianopolous/Peergos
Seafile offers things that other projects don't (most notably delta sync, which is a long-standing issue of contention on the OwnCloud repository). And with respect to encryption, I am storing everything synced inside of Veracrypt volumes (one of the Truecrypt successors), and so I'm not too worried about Seafile's lack of encryption features.
"I don't quite understand why using a single IV for the whole library is vulnerable to known-plaintext attacks."
That might be an acceptable response if you're trying to build a secure system and don't fully understand your tools yet, not many people do, but it should be followed with an eager question on how to improve. Instead he follows up with:
"I know it's better to use different IV and key for each file/block. But that would greatly increase complexity."
As if that's an excuse. And besides, solutions had been suggested and it's not that complex. Finally he just states that the security improvements are not scheduled.