[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SHA-1 collision in repository?

From: Philip Martin <philip_at_codematters.co.uk>
Date: Sun, 04 Mar 2018 11:12:00 +0000

Stefan Sperling <stsp_at_elego.de> writes:

> Yes. And if the content differs, it must be rejected, because an FSFS
> repository can only store one content per SHA1 checksum.

To be accurate the server-side code can handle the files perfectly well
if rep-caching is disabled. One can retreive either file, dump/load
into another repository, etc.

# Import 2 files from shattered.io
svnadmin create repo1
echo [rep-sharing] >> repo1/db/fsfs.conf
echo enable-rep-sharing=false >> repo1/db/fsfs.conf
svn import -mm shattered-1.pdf file://`pwd`/repo1/f
svn import -mm shattered-2.pdf file://`pwd`/repo1/g

# dump/load
svnadmin create repo2
echo [rep-sharing] >> repo2/db/fsfs.conf
echo enable-rep-sharing=false >> repo2/db/fsfs.conf
svnadmin dump repo1 | svnadmin load repo2

# verify files have same SHA1 but different MD5
$ svnlook cat repo2 f | sha1sum
38762cf7f55934b34d179ae6a4c80cadccbb7f0a -
$ svnlook cat repo2 g | sha1sum
38762cf7f55934b34d179ae6a4c80cadccbb7f0a -
$ svnlook cat repo2 f | md5sum
ee4aa52b139d925f8d8884402b0a750c -
$ svnlook cat repo2 g | md5sum
5bd9d8cabc46041579a311230539b8d1 -

The on the client side the working copy code doesn't handle the files as
the pristines collide.

Received on 2018-03-04 12:12:16 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.