On 2017-02-25 00:05:34, Jakub Narębski wrote: > W dniu 24.02.2017 o 23:53, Santiago Torres pisze: > > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > > > I have just read on ArsTechnica[1] that while Git repository could > > > be corrupted (though this would require attackers to spend great > > > amount of resources creating their own collision, while as said > > > elsewhere in this thread allegedly easy to detect), putting two > > > proof-of-concept different PDFs with same size and SHA-1 actually > > > *breaks* Subversion. Repository can become corrupt, and stop > > > accepting new commits. > > > > From what I understood in the thread[1], it was the combination of > > svn + git-svn together. I think Arstechnica may be a little bit > > sensationalistic here. > > > [1] https://bugs.webkit.org/show_bug.cgi?id=168774#c27 > > Thanks for the link. It looks like the problem was with svn itself > (couldn't checkout, couldn't sync), but repository is recovered now, > though not protected against the problem occurring again. > > Well, anyone with Subversion installed (so not me) can check it for > himself/herself... though better do this with separate svnroot. I tested this yesterday by adding the two PDF files to a Subversion repository, and found that it wasn't able to clone ("checkout" in svn speak) the repository after the two files had been committed. I posted the results to the svn-dev mailing list, the thread is at . It seems as it only breaks the working copy because the pristine copies are identified with a SHA1 sum, but the FSFS repository backend seems to cope with it. Regards, Øyvind +-| Øyvind A. Holm - N 60.37604° E 5.33339° |-+ | OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc | | Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 | +------------| 41517b2c-fae7-11e6-9521-db5caa6d21d3 |-------------+