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

Reply via email to