On Feb 23, 2017 15:12, "Martin Gagnon" <eme...@gmail.com> wrote:
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. Or more correctly, "a *subsequent* file with the same sha1 hash..." If you happened to commit the Trojan file first, the "good" commit would have been the one to fail. 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
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
