On Wed, Sep 16, 2015 at 3:01 AM, Scott Robison <[email protected]> wrote:
> cryptographic security, it was designed to take a blob of data and create > a pseudo-random looking string of 40 hex digits that would be highly > unlikely to collide with anything being done by anyone else. > To add to that - a collision is not a problem so long as it doesn't happen in the same context. If 2 independent repos end up with the same hash for 2 distinct blobs, _no big deal_. Nothing evil happens there. Even if one were to try to feed "that other" blob into "the other" repo, the R-card calculation (done using md5) would then change, invalidating any checkins. I do see your points about interested parties trying to create a collision, > but even if they managed that, simply gaining commit access to the master > repository as mentioned the other day would not be adequate; the > maliciously modified artifact would be rejected by fossil (as I understand > it) as a duplicate / already received artifact. > Even if they locally inject it, the R-card calculation would see it, as it is (i will naively assert) "impossible" that both the sha1 and md5 could both be made to match in a collision of a non-empty blob. (The empty-blob case is an interesting one, though, if only intellectually.) > Again, I concede your point about bad actors trying to create deliberate > collisions, but even in so doing there is far more to do than just "push an > update". > +1. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
