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

Git hash function transition plan

github.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Git hash function transition plan

#21

Post by finnthehuman »

scrollaway wrote: post #18
cdancette wrote: post #13

Torvald's on signing commits : http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

He makes excellent points on tags; the one I hadn't considered before is that tags indeed can be separated from the tree, which makes them a unique asset in a git tree. The problem with that however is how we use tags today . Creating a tag in the modern lingua franca of git means creating a new version. If you push that tag to Github or Gitlab or what have you, a handy "release" will be created for you. If you're si…

>The problem with that however is how we use tags today.

"Doctor, it hurts when I cargo-cult workflow from GitHub..."

Re: Git hash function transition plan

#23

Post by CobrastanJorji »

The main downside to switching the hash function is that, when explaining why developers should stop worrying about hash conflicts, we'll need to calculate a new analogy to replace the standard, 180 bit "every member of your programming team being attacked and killed by wolves in unrelated incidents on the same night" scenario.

Re: Git hash function transition plan

#24

Post by scrollaway »

finnthehuman wrote: post #21
scrollaway wrote: post #18

Earlier quoted context omitted.

He makes excellent points on tags; the one I hadn't considered before is that tags indeed can be separated from the tree, which makes them a unique asset in a git tree. The problem with that however is how we use tags today . Creating a tag in the modern lingua franca of git means creating a new version. If you push that tag to Github or Gitlab or what have you, a handy "release" will be created for you. If you're si…

> The problem with that however is how we use tags today. "Doctor, it hurts when I cargo-cult workflow from GitHub..."

Do you have a point?

Re: Git hash function transition plan

#25

Post by jrochkind1 »

scrollaway wrote: post #18
cdancette wrote: post #13

Torvald's on signing commits : http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

He makes excellent points on tags; the one I hadn't considered before is that tags indeed can be separated from the tree, which makes them a unique asset in a git tree. The problem with that however is how we use tags today . Creating a tag in the modern lingua franca of git means creating a new version. If you push that tag to Github or Gitlab or what have you, a handy "release" will be created for you. If you're si…

pushing a tag to github-hosted repo certainly does not automatically create a 'release'.

Re: Git hash function transition plan

#26

Post by abritinthebay »

rjzzleep wrote: post #7
benjaminjackman wrote: post #3

Only have time to skim it, I didn't see anyplace, so might be a good time to suggest multihash: https://multiformats.io/multihash/ Having git to use that could be a great opportunity to standardize on a de facto hash function encoding standard. What would be the best way to suggest that (if it hasn't been already, though I am guessing it likely has).

Wasn't there an issue with JWT that was summarized as this: "This is a good idea, but it doesn't solve the underlying problem: attackers control the choice of algorithm" ? Here's another quote from the Wireguard paper[1]: "Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update" […

That’s only true of JWT if you allow your server to accept all algorithms.

You don’t actually have to.

Re: Git hash function transition plan

#27

Post by abritinthebay »

finnthehuman wrote: post #21
scrollaway wrote: post #18

Earlier quoted context omitted.

He makes excellent points on tags; the one I hadn't considered before is that tags indeed can be separated from the tree, which makes them a unique asset in a git tree. The problem with that however is how we use tags today . Creating a tag in the modern lingua franca of git means creating a new version. If you push that tag to Github or Gitlab or what have you, a handy "release" will be created for you. If you're si…

> The problem with that however is how we use tags today. "Doctor, it hurts when I cargo-cult workflow from GitHub..."

Hardly. It’s a workflow - that’s all. One that works exceedingly well for millions of people.

Re: Git hash function transition plan

#28

Post by deathanatos »

CobrastanJorji wrote: post #23

The main downside to switching the hash function is that, when explaining why developers should stop worrying about hash conflicts, we'll need to calculate a new analogy to replace the standard, 180 bit "every member of your programming team being attacked and killed by wolves in unrelated incidents on the same night" scenario.

That analogy presumes that the hash function's output is uniformly random; when you know how to manipulate it s.t. its output is not random, then obviously it doesn't hold.

The question of accidental collisions is still relevant, even with SHA-256, and the answer is still the same: it's so vanishingly improbable that it is assumed to be impossible.

Re: Git hash function transition plan

#30

Post by nayuki »

styfle wrote: post #22

This doesn’t render very well on mobile. I wish the Git team would write their docs as a .md so GitHub could render as HTML with word wrap in all its glory.

Here is a rich text version of the same document: https://www.kernel.org/pub/software/scm/git/docs/technical/h...
Post reply on HN