Stefan Fuhrmann wrote on Mon, Apr 17, 2017 at 22:17:46 +0200:
> On 30.03.2017 21:38, Daniel Shahaf wrote:
> >Let's use jira or moinmoin to track all the different issues that need
> >looking into? I count at least fsfs, fsx, svnadmin load, libsvn_wc, and
> >zhakov's change that Bert mentioned.
> What is the problem with 'svnadmin load'?
It's not possible to load a dumpfile that contains a sha1 collision:
% wget https://shattered.it/static/shattered-1.pdf https://shattered.it/static/shattered-2.pdf
% svnadmin create r
% svn co file://$PWD/r wc
% cd wc
wc% cp ../shattered-* .
wc% svn add *
wc% svn ci -madd
wc% cd ../
% svnadmin create r2
% svnadmin dump -r > dump
% svnadmin load r2 < dump
<<< Started new transaction, based on original revision 1
* editing path : shattered-1.pdf ... done.
* editing path : shattered-2.pdf ...svnadmin: E200014: Checksum mismatch for '/shattered-2.pdf':
zsh: exit 1 svnadmin load r2 < dump
That's with 1.9.5. Is it fixed on trunk now? I'm not sure whether
r1785754 addresses that.
Incidentally: the error code added in r1785754 is misspelled:
SVN_ERR_FS_AMBIUGOUS_CHECKSUM_REP should be
Not only in the error message, also in the code.
> It uses SHA1 and MD5 to verify that the data is valid
> but will not detect intended changes that transformed
> the dump stream from one valid / consistent state to
> another. Apart from that, the FS backend should now
> handle collisions just fine.
> With FSFS and FSX fixed in /trunk (FSX not with the
> backport IMO), there is only the wc issue left. Not sure
> how much efficiency we want to sacrifice there. For
> instance, switching between branches will become
> expensive again.
> -- Stefan^2.
Received on 2017-04-18 02:59:53 CEST