On Wed, Oct 19, 2016 at 2:36 AM, Aldo Nicolas Bruno <ovenpa...@pizzahack.eu> wrote:
> Better question can be, how fossil manage collisions? > Fossil rejects new artifacts with matching hashes, working on the assumption that it already has the blob. The only way someone could hope to exploit this for malicious purposes is: 1. Discover some fossil user has created a commit with an artifact having a given hash X. 2. Quickly create another artifact with that same hash. 3. Push it to other copies of the same repository before the original fossil user is able to push his copy. In both the cases of git and fossil, it seems to me that hash collisions (deliberate or coincidental) are a race condition. Whoever pushes to other repositories first wins. Given that it is impossible to predict exactly how one will solve a given problem (and thus what its hash would be) in advance, the speed of fossil's default auto sync, the fact that no one has yet demonstrated an effective real time attack, and the fact that sha1 is not being used for security but for reliability, sha1 isn't an issue. Even if someone found an effective real time attack that could generate a collision, they then have the problem of not just finding a collision, but a collision that will be close enough to the original that the primary functionality wasn't broken (in the case of tracking source code, arguably the most common case). Really, from this POV, fossil and git are both just fine. It's far more likely that someone will compromise a server with a weak password and completely replace the good repo with a bad repo, or just host a fork that looks legit and get people to pull from that instead. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
