Re: SHA-1 collision in repository?

Philip Martin <philip_at_codematters.co.uk> writes:

> svn cat http://svn.apache.org/repos/asf/subversion/trunk/INSTALL@1826165 > f1
> (for i in `seq 0 8712`;do echo -n $i;done && echo -n 11111) > f1
> svnadmin create repo
> svnmucc -mm -U file://`pwd`/repo put f1 f
> svnmucc -mm -U file://`pwd`/repo put f2 2
> svnmucc -mm -U file://`pwd`/repo put f1 f

Oops again! All three commits should be to destination 'f'.

  svn cat http://svn.apache.org/repos/asf/subversion/trunk/INSTALL@1826165 > f1
  (for i in `seq 0 8712`;do echo -n $i;done && echo -n 11111) > f2
  svnadmin create repo
  svnmucc -mm -U file://`pwd`/repo put f1 f
  svnmucc -mm -U file://`pwd`/repo put f2 f
  svnmucc -mm -U file://`pwd`/repo put f1 f

The cause of the bug, as identified by Melissa, is that the wrong
expanded size if computed -- it gets set to the size of the delta in the
protorev file. The svn_stream_t that is producing the fulltext works in
16K chunks, so the total amout of fulltext goes up in steps: 16K, 32K,
48K, etc. If one of those steps happens to match the erroneous expanded
size the stream treats that as the end of the fulltext. The stream then
finalizes the MD5 checksum for the partial fulltext and the MD5 checksum
failure occurs.

For most commits the protorev delta is not a multiple of 16K and so the
erroneous expanded size does not match any of the fulltext steps.
Eventually the stream reaches EOF and gets a short read less than 16K.
The function svn_stream_contents_same2 recognises the short read as EOF
and ends the comparison between the two streams, however the stream
itself has not finalized the checksum because of the length mismatch.
This means we did not verify the MD5 checksum for the protorev fulltext
but we did verify that the protorev fulltext matches the fulltext in the
repository.

-- 
Philip