Re: Files with identical SHA1 breaks the repo

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
Received on 2017-02-26 19:29:38 CET