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 |-------------+