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 <markphip_at_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 <stsp_at_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.
Received on 2017-02-24 18:12:24 CET