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

171–180 of 240 posts

Re: A new hash algorithm for Git

#171

Post by hinkley »

gouggoug wrote: post #146
kazinator wrote: post #114

> There is, of course, a way to unambiguously give a hash value in the new Git code, and they can even be mixed on the command line; this example comes from the transition document: git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256} > For a Git user interface this is relatively straightforward and concise No, it isn't. It's a complete and utter user interface clusterfuck. Just say no to this insanity.

> For a Git user interface this is relatively straightforward and concise You forgot to include the end of that sentence, that acknowledges your issue with it: > , but one can still imagine that users might tire of it relatively quickly.

I've had this argument at work.

"Tire of it quickly" and "have an immediate gag reflex" are two completely different categories of negative reaction.

It's hard to see the sunset when you're down in the muck, and eventually 'less bad' starts to look like progress to you. It's a trap and you should be aware of it.

Re: A new hash algorithm for Git

#172

Post by wyoung2 »

bmn__ wrote: post #111
ericfrederich wrote: post #93

I'll have to update my program which generates vanity hashes. I do enjoy starting projects with an obligatory "Initial Commit" with a deadbeef SHA-1

I like to start a repo with an "empty" commit, that is to say its tree is the magic 4b825dc. https://news.ycombinator.com/item?id=18342763 I wonder if it would still be practically possible to manipulate the commit id.

Wow! I wouldn't have guessed that Git had that vulnerability. Fossil solves it easily: creating a new repo involves generating a random project code (a nonce) which goes into the hash of the first commit, so that even two identical commit sequences won't produce identical blockchains.

Fossil lets you force the project ID on creating the repo, but the capability only exists for special purposes.

Re: A new hash algorithm for Git

#173

Post by pornel »

sunil_saini wrote: post #135

The above article suggests that Sha-1 collision is infeasible because attacker has to come up with code that not only generate same hash but also benefit him. But can't he just add some malicious code and add some random text in comments to produce same hash?

"produce same (specific) hash" is a pre-image attack, which is very very hard. So hard, that even MD5 isn't broken for pre-image, and there's only a theoretical pre-image attack against MD4.

We know only collision attacks which is "produce 2 files with the same hash, but you can't control what hash". So you can't target any existing repo. You need to use social engineering to get one of your special files into a repo.

Re: A new hash algorithm for Git

#174

Post by apeace »

SQLite wrote: post #161
seniorsassycat wrote: post #143

Earlier quoted context omitted.

The way I read the fossil's authors comments, old commits continue to use sha1 hashes. A repository will be vulnerable to sha1 collision attacks as long as there is an object in the repository that has not been hashed with the new algorithm. For example, floppy.c could be replaced in a repo with file with the same sha1 hash as long as the last commit that modifies floppy.c used a sha1 hash. Right?

Just to be clear: Every time you modify a file, the new changes get put in using SHA3. In an older repository, any given commit might have some files identified using SHA1 (assuming they have not changed in 3 years) and others identified using SHA3. For example, the manifest of the latest SQLite check-in is see at ( https://www.sqlite.org/src/artifact/29a969d6b1709b80 ). You can see that most of the files have longer…

And if you are that concerned about this type of attack, it may be worth your time to simply start a new Fossil repository using the sha3-only hash policy (writing a script to replay commits into the new repo, so you don't lose history).

It seems like a problem very few people need to worry about and Fossil has made the right trade-offs.

Re: A new hash algorithm for Git

#175

Post by tjoff »

wyoung2 wrote: post #164
SQLite wrote: post #161

Earlier quoted context omitted.

Just to be clear: Every time you modify a file, the new changes get put in using SHA3. In an older repository, any given commit might have some files identified using SHA1 (assuming they have not changed in 3 years) and others identified using SHA3. For example, the manifest of the latest SQLite check-in is see at ( https://www.sqlite.org/src/artifact/29a969d6b1709b80 ). You can see that most of the files have longer…

> Furthermore, the evil.c file with the same SHA1 hash would need to be valid C code that does something evil while still yielding the same hash ...and also produce an innocent-looking diff! I mean, you could stuff a bunch of random bytes into a C comment to force the desired hash in the output using these documented attack techniques, but anyone inspecting the diffs between versions is likely to see such an explosio…

Many diff tools don't highlight whitespace-only changes. Or at least not in a clear manner.

Also, if something is replaced in the history how often do people go back and view diffs in old code? Hardly often enough to rely on it being spotted.

Re: A new hash algorithm for Git

#176

Post by Tyr42 »

seniorsassycat wrote: post #143
velcrovan wrote: post #131

Earlier quoted context omitted.

Fossil's main author is chiming in the discussion of this on Fossil's forums: ( https://fossil-scm.org/forum/forumpost/50a5bea5fb ) > That's appalling. Fossil's implementation doesn't require a conversion. “This is a key point, that I want to highlight. I'm sorry that it wasn't made more clear in the LWN posting nor in the HN discussion. “With Fossil, to begin using the new SHA3 hash algorithm, you just upgrade your…

The way I read the fossil's authors comments, old commits continue to use sha1 hashes. A repository will be vulnerable to sha1 collision attacks as long as there is an object in the repository that has not been hashed with the new algorithm. For example, floppy.c could be replaced in a repo with file with the same sha1 hash as long as the last commit that modifies floppy.c used a sha1 hash. Right?

They are also using "Hardened SHA1", which detects collision attacks, and assigns a longer id to commits which seem malicious, while being backwards compatible.

Re: A new hash algorithm for Git

#177

Post by allover »

kazinator wrote: post #160
allover wrote: post #147

Earlier quoted context omitted.

You are now ignoring the fact that in the initial quote you objected to was the intentionally tongue-in-cheek: > 'For a Git user interface this is relatively straightforward and concise'. It kinda looks like you missed the joke and are now doubling-down on your disagreement. The author does not think the proposed example is reasonable. You're in agreement.

Since git is something that I rely on for everyday use, and long-term data stroage, and its development is being threatened by the inclusion of moronic changes I completely disagree with, I'm completely unreceptive to jokes. This is no laughing matter.

I agree, things shouldn't be this bad.

But unless you're going to take this up with Linus, you're just yelling at your fellow disappointed spectators.

Re: A new hash algorithm for Git

#178

Post by allover »

hinkley wrote: post #169
allover wrote: post #147

Earlier quoted context omitted.

You are now ignoring the fact that in the initial quote you objected to was the intentionally tongue-in-cheek: > 'For a Git user interface this is relatively straightforward and concise'. It kinda looks like you missed the joke and are now doubling-down on your disagreement. The author does not think the proposed example is reasonable. You're in agreement.

And the responder makes a pretty unsubtle allusion to Lovecraft. Anyone who compares the git CLI to being driven insane by Elder Gods is not defending the git CLI.

Not sure if the HN thread or my comment has thrown you, but I'm replying to 'kazinator'.

I know he's not defending it.

What I said is that he (kazinator) is inadvertently attacking somebody that's also not defending it (the author).

Re: A new hash algorithm for Git

#179

Post by wyoung2 »

tjoff wrote: post #175
wyoung2 wrote: post #164

Earlier quoted context omitted.

> Furthermore, the evil.c file with the same SHA1 hash would need to be valid C code that does something evil while still yielding the same hash ...and also produce an innocent-looking diff! I mean, you could stuff a bunch of random bytes into a C comment to force the desired hash in the output using these documented attack techniques, but anyone inspecting the diffs between versions is likely to see such an explosio…

Many diff tools don't highlight whitespace-only changes. Or at least not in a clear manner. Also, if something is replaced in the history how often do people go back and view diffs in old code? Hardly often enough to rely on it being spotted.

It only takes one person to raise the flag.

Sure, many thousands of people doing blind "git clone && configure && sudo make install" could be burned by a problem like this, but someone would eventually do a diff and see the problem on any project big enough to have those thousands of trusting users in the first place.

I'm not excusing these SHA-1 weaknesses, only pointing out that it won't be trivial to apply them to program source code repos no matter how cheap the attacks get.

For instance, the demonstration case for SHAttered was a pair of PDFs: humans can't reasonably inspect those to find whatever noise had to be stuffed into them to achieve the result.

I also understand that these SHA-1 weaknesses have been used to attack X.509 certificates, but there again you have a case very unlike a software code repo, where the one doing the checking isn't another programmer but a program.

Re: A new hash algorithm for Git

#180

Post by ajkjk »

wyoung2 wrote: post #165
seniorsassycat wrote: post #143

Earlier quoted context omitted.

The way I read the fossil's authors comments, old commits continue to use sha1 hashes. A repository will be vulnerable to sha1 collision attacks as long as there is an object in the repository that has not been hashed with the new algorithm. For example, floppy.c could be replaced in a repo with file with the same sha1 hash as long as the last commit that modifies floppy.c used a sha1 hash. Right?

In addition to D. Richard Hipp's thoughts as HN user SQLite — author also of Fossil, so he oughtta know — I offer these: 1. Keep in mind that Fossil and Git are both applications of blockchain technology, which in this particular practical case means you must not only forge a single artifact's hash, you must also do it in a way that allows it to fit into the overall blockchain. 2. Fossil's sync protocol purposefully…

> applications of blockchain technology

Are we saying this now? More like blockchain is an application of git technology.

Post reply on HN