Thanks for taking the time to explain... Sorry to nitpick, but I'm trying to get things clear.
your original comment pointing to the commit said
> And SeaFile has additionally modified the default Django components making it more insecure
So I was under the impression that this commit was making things worse, not better. Thanks for clarifying that this was already fixed in this commit, rather than introduce a vulnerability. It looks like they added the hashed password on the diff to mitigate this issue - unless I am missing something here? Can you explain why they "partially mitigated the vulnerability" here? is there still some gap that they've missed?
I'm not underestimating the vulnerability, or the fact that it was there in the first place. Just trying to get a full(er) picture.
I've had a read through this, and some other places where insecurity of Seafile is exposed/discussed/fixed. I agree that the overall impression I'm getting is that they're not security experts, and security could have definitely been better designed or taken into account in the first place.
I still think they're trying to do their best, and fix problems and improve. I hope for their and their users' sake that they can get some security-dedicated contributors (mostly to prevent bad things in the first place rather than fixing them later on). There's always more that can be done, but I'd like to give them the benefit of the doubt here and have faith that things will be better in the long run. Having a (robustly) secure, open-source dropbox replacement is a good thing. I think that's their aim, even if they are some times misguided.
disclaimed: I'm not even a user of Seafile, let alone know much about its codebase. It's the first time I hear about it. I was just curious about the security aspects of their product in light of some criticism here and on github etc.