Thanks for taking the time to explain... Sorry to nitpick, but I&#x27;m trying to get things clear.<p>your original comment pointing to the commit said<p>&gt; And SeaFile has additionally modified the default Django components making it more insecure<p>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 <i>&quot;partially</i> mitigated the vulnerability&quot; here? is there still some gap that they&#x27;ve missed?<p>I&#x27;m not underestimating the vulnerability, or the fact that it was there in the first place. Just trying to get a full(er) picture.<p>I&#x27;ve had a read through this, and some other places where insecurity of Seafile is exposed&#x2F;discussed&#x2F;fixed. I agree that the overall impression I&#x27;m getting is that they&#x27;re not security experts, and security could have definitely been better designed or taken into account in the first place.<p>I still think they&#x27;re trying to do their best, and fix problems and improve. I hope for their and their users&#x27; 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&#x27;s always more that can be done, but I&#x27;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&#x27;s their aim, even if they are some times misguided.<p>disclaimed: I&#x27;m not even a user of Seafile, let alone know much about its codebase. It&#x27;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.