Re: Files with identical SHA1 breaks the repo

On Fri, 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.
>

Note that while this does fix the error, but because of the sha1 storage
sharing in the working copy you actually do not get the correct files.
Both PDF's wind up being the same file, I imagine whichever one you receive
first is the one you get.

So not only does rep sharing need to be fixed, the WC pristine storage is
also broken by this.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/