On 26.02.2017 18:26, Paul Hammant wrote: > Why don't y'all take the same tactic as Git does - SHA1 the contents of the > file *and a prepended a type/length field* ?.
And when the hash-colliding files happen to have the same type and length, as in the published collision... Ah, of course, Git is immune to that because it uses magic and pixie dust as well. > That and a tool to back convert SHA1s for existing repos. > > Linus weighed in again: > https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL > Svn is more likely to be used as a store for larger binaries, ... because Git sucks rocks at storing anything but small text files. > that need to > be non-repudiable than Git is, even if that is still an edge case. Give me a break from Linus' yammering about Git, especially the after-the-fact rationalization of the design. At least on this list. Please? The bottom line is that any data storage system that uses lossy content-based indexing is vulnerable to hash collisions. And both Subversion and Git developers were well aware of that when the vulnerable features were designed. For normal, day-to-day usage, SHA-1 collisions are no more likely now than they were a week ago. So as of today, a malicious user with huge computing resources and write access to your repository can make part of it inaccessible. I bet it's cheaper and easier to crack your server and 'sudo rm -fr /'. -- Brane
