Surely two files with the same hash was always a posibility, not matter what the hash function is?
Barry > On 24 Feb 2017, at 16:55, Mark Phippard <markp...@gmail.com> wrote: > > Someone may want to jump in here: > > https://news.ycombinator.com/item?id=13725093 > > Mark > > >> On Feb 24, 2017, at 5:51 AM, Stefan Sperling <s...@apache.org> wrote: >> >>> On Thu, Feb 23, 2017 at 09:02:28PM +0100, Øyvind A. Holm wrote: >>> Earlier today, the first known SHA1 collision was presented: >>> >>> >>> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html >>> http://shattered.io/ >>> >>> It turns out that adding these two PDF files to a svn repository makes >>> it impossible to checkout the repository properly if both files exist in >>> the repo. This script demonstrates what happens: >> >> As a workaround, disable rep-sharing and the error goes away. >> >> [[[ >> #!/bin/sh >> >> if test -e repo -o -e wc1 -o -e wc2; then >> echo repo, wc1 or wc2 already exist >&2 >> exit 1 >> fi >> svnadmin create repo >> sed -i -e 's/# enable-rep-sharing = true/enable-rep-sharing = false/' >> repo/db/fsfs.conf >> svn co file://$(pwd)/repo wc1 >> cd wc1 >> wget https://shattered.it/static/shattered-1.pdf >> wget https://shattered.it/static/shattered-2.pdf >> svn add *.pdf >> svn ci -m "Add files with identical SHA1" >> cd .. >> svn co file://$(pwd)/repo wc2 >> ]]] >> >> A (bin) shattered-1.pdf >> A (bin) shattered-2.pdf >> Adding (bin) shattered-1.pdf >> Adding (bin) shattered-2.pdf >> Transmitting file data ..done >> Committing transaction... >> Committed revision 1. >> A wc2/shattered-1.pdf >> A wc2/shattered-2.pdf >> Checked out revision 1.
