Re: SHA1 collisions found

On 2017-02-25 00:05:34, Jakub Narębski wrote:

W dniu 24.02.2017 o 23:53, Santiago Torres pisze:

quoted

On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:

quoted

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.

quoted

[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 
<https://svn.haxx.se/dev/archive-2017-02/0142.shtml>.

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 [off-list ref] - 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 |-------------+