Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new hash algorithm for Git

lwn.net

Post reply on HN
Print view View original

81–90 of 240 posts

Re: A new hash algorithm for Git

#81

Post by wongarsu »

donatj wrote: post #71

Excuse my ignorance, but couldn’t they just add a SHA256 hash to commit objects (or some new commit-verify object) of the entire trees current concatenated content, leave everything else SHA1 and get the same benefit without rewriting the entire thing from the ground up? Git could even do that as part of the git gc step slowly over time - tag commits with a secondary hash. Rewriting the whole thing including every gi…

You can't change past commits to add that hash (without changing all commit hashes), so this method could only protect new commits. For any existing repo this would lead to a very weird security model: We admit that sha1 hashes are broken, and only guarantee that commits made by git versions newer than git x.x.x are safe from after-the-fact modification (or alternatively only commits made after date X).

Re: A new hash algorithm for Git

#82

Post by SAI_Peregrinus »

sandGorgon wrote: post #59
freddie_mercury wrote: post #7

Earlier quoted context omitted.

Why would they support it? The article clearly states it is nowhere close to being useful yet. It is untested, unstable code that can only write to repositories and not read them. "Much of the work to implement the SHA‑256 transition has been done, but it remains in a relatively unstable state and most of it is not even being actively tested yet. In mid-January, carlson posted the first part of this transition code,…

actually - i might have worded it confusingly. For smaller projects (like my own), can i move to sha-256 with no expectation of backward compatibility today ?

"First, it contains the pieces necessary to set up repositories and write _but not read_ extensions.objectFormat. In other words, you can create a SHA‑256 repository, but will be unable to read it. "

If you want it to be write-only, sure, go ahead!

Re: A new hash algorithm for Git

#84

Post by upofadown »

anaisbetts wrote: post #9

I don't understand the practical attack vector for breaking SHA1s in Git. Not only are objects checksummed by SHA1, they also encode the length . Finding a SHA1 collision is plausible, but finding a SHA1 collision that both lets you do something Nefarious, and is the length you need, seems really really unlikely

To make the collision work you need to produce two different files, both with some randomish looking junk in them. So if you can do that in a way where you can substitute one of the files for the other without getting caught then you are almost for sure smart enough to also figure out a way to make the lengths the same.

Re: A new hash algorithm for Git

#86

Post by u801e »

rocqua wrote: post #55
GlitchMr wrote: post #24

I wonder if it would make sense to use `concat(sha1, sha256)` hash algorithm. This wouldn't change the prefixes while improving strength of an algorithm (by including SHA256 in a hash).

There is a downside that this would mean commit-prefixes remain sensitive to collisions. Hence anyone checking out a commit by a hash-prefix would still be vulnerable. Not a dealbreaker by far, but still a slight mark against this solution.

Does git have code to detect whether a hash prefix is ambiguous? I know that if you use a short prefix (which is more likely to be shared by multiple objects), git will output an error message staying that the object reference is ambiguous IIRC.

Re: A new hash algorithm for Git

#87

Post by nullc »

wolfgke wrote: post #58
nullc wrote: post #30

Earlier quoted context omitted.

> Git's performance-oriented ethos Than sha256 will likely be preferable in the long run: It's faster with SHA-NI than blake3. If you're not developing on a system with sha-ni, get with the program. Zen2 is freeking awesome. :)

> Zen2 is freeking awesome. :) SHA-NI was introduced with the Intel Goldmont microarchitecture.

Yes, but Goldmont is not particularly awesome. :) Presumably goldmont would be a downgrade for many people.

(On AMD the first generation zen have sha-ni, FWIW)

Re: A new hash algorithm for Git

#88

Post by majewsky »

velox_io wrote: post #68
majewsky wrote: post #62

Earlier quoted context omitted.

This question is exactly what a major portion of the article covers.

It isn't the easiest article to read, plus they over complicate things by talking about things such as truncating SHA2 hashes. I don't see why changing the hashing algorithm is so problematic, hence the reason why I asked the question. Converting a repository to SHA2 should be straight forward (the only issue is everyone's tooling), you could also run the repositories side-by-side. I'm genuinely interested as I think…

> the only issue is everyone's tooling

Exactly! If you've ever worked in a corporate environment, you know the fun of having to support 10-year-old versions of your favorite cutting-edge software.

Post reply on HN