On Thu, Feb 23, 2017 at 09:50:12AM -0800, Marc Simpson wrote: > This may be of interest to some here, especially in light of previous > SHA-1 related discussions on list: > > https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html >
Also, Here's a related discussion from git mailing list: https://marc.info/?t=148786884600001&r=1&w=2 Somebody tried those 2 colliding pdf's on a git repository: https://github.com/joeyh/supercollider Seems that Git can store both of them, I beleive it calculate the sha1 on a combination of the filename and the content or something like that. So I was curious and I tried to put them on a fossil repository. Here what I got (with repo-cksum enabled): ---------------------------------- $ ls bad.pdf good.pdf $ sha1sum bad.pdf good.pdf d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a bad.pdf d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a good.pdf $ fossil add bad.pdf ADDED bad.pdf $ fossil add good.pdf ADDED good.pdf $ fossil commit [***] Current default user: mgagnon vim "./ci-comment-A70B84D400D2.txt" ./bad.pdf contains binary data. Use --no-warnings or the "binary-glob" setting to disable this warning. Commit anyhow (a=all/y/N)? a New_Version: 510b26ef49be508003304840a9ea18894007ad51 ERROR: [good.pdf] is different on disk compared to the repository NOTICE: Repository version of [good.pdf] stored in [file-3a8b62456795ffdb] working checkout does not match what would have ended up in the repository: 2106b982989e5604ec91523ddd81c879 versus a388ff244a318ee5904ba276b754d84a --------------------------------- Seems that repo-cksum give an extra protection against this kind of collision. (but don't let the file goes in...) Then, I tried with repo-cksum disabled. 1- I add good.pdf and commit. 2- I add bad.pdf and commit (it succeed) 3- I check with "fossil ui" and both files share the same content (good.pdf) At least, if a file with a certain sha1 hash exist on a repo, a malicious file with the same sha1 hash should never goes in. I'm not an expert in encryption and security: I agree that the possibility of sha1 collision is not a good thing, but it's probably not the end of the world and it doesn't make fossil un-usable. side note: A collision is a lot easier to produce on a file like a pdf than on a source file. "That's why pdf's are the classic model for showing these attacks: it's easy to insert garbage in the middle of a pdf that is invisible." -- git mailing list citation Regards, -- Martin G. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users