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

31–40 of 59 posts

Re: Git hash function transition plan

#31

Post by oconnor663 »

stouset wrote: post #20
lgierth wrote: post #15

Earlier quoted context omitted.

You can lock it down to specific hash functions no problem.

If I’ve learned anything from being in this field it’s that: 1) many if not most implementations will support lots of algorithms by default, and 2) as a result, approximately zero users will lock it down

Yeah that's exactly what I'm worried about. The nature of the beast makes it tricky to define a safe default.

Re: Git hash function transition plan

#32

Post by stevekemp »

jrochkind1 wrote: post #25
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…

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

Github "releases" - as listed on the repository index - are solely based on the tags of the repository. So yes, pushing a tag does create a release.

See here for documentation:

https://help.github.com/articles/about-releases/

Re: Git hash function transition plan

#33

Post by rblatz »

abritinthebay wrote: post #26
rjzzleep wrote: post #7

Earlier quoted context omitted.

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.

Correct, your token authority should specify which algorithms are valid, and your clients should self configure via a secure back channel to only accept the algorithms your token authority issues.

Re: Git hash function transition plan

#35

Post by derekmhewitt »

Can someone explain why they would transition to a new hash function and not a block chain based system of tracking? If one of the goals of introducing a stronger hash function is signage of individual commits it seems like a block chain would be ideal.

Re: Git hash function transition plan

#36

Post by anton_gogolev »

NewHash is a terrible name - on par with Xbox One [X] and iPad New. Googling stuff will be hard, and good luck explaining to less technical-savvy users what is this all about.

Plus, in 100 years, when SHA-256 is compromised, what would be the name of a new new format?

Re: Git hash function transition plan

#37

Post by milkey_mouse »

derekmhewitt wrote: post #35

Can someone explain why they would transition to a new hash function and not a block chain based system of tracking? If one of the goals of introducing a stronger hash function is signage of individual commits it seems like a block chain would be ideal.

Chains of Git commits are already a blockchain - at least, already a DAG, and to be more specific, they are both Merkle trees. Internally, each commit contains the hash of the previous commit it was based on:

    $ git cat-file -p HEAD
    tree e013f4d121199d60b70043f525aef4a7e641b5f6
    parent 152bbb43b30ced1b32e9ed6f5ba2ac448de725b6
    author Linus Torvalds  1510512373 -0800
    committer Linus Torvalds  1510512373 -0800

    Linux 4.14
You can even GPG sign each commit if you want to ensure authenticity. The other aspects of cryptocurrency blockchains don't really apply here: we don't need a single "true chain," in fact that's the point of branching.

(Kids these days with their blockchains...)

Re: Git hash function transition plan

#38

Post by 0T-T0 »

derekmhewitt wrote: post #35

Can someone explain why they would transition to a new hash function and not a block chain based system of tracking? If one of the goals of introducing a stronger hash function is signage of individual commits it seems like a block chain would be ideal.

git already is a hash linked datastore with the ability to sign your 'transactions'. The doc just points out that SHA1 is not a reliable hash to address objects anymore.

Re: Git hash function transition plan

#39

Post by MaxfordAndSons »

anton_gogolev wrote: post #36

NewHash is a terrible name - on par with Xbox One [X] and iPad New. Googling stuff will be hard, and good luck explaining to less technical-savvy users what is this all about. Plus, in 100 years, when SHA-256 is compromised, what would be the name of a new new format?

I was under the impression that it's just a placeholder until the actual new hash function was decided on.

Also the whole point of this transition plan is that it will be a completely optional, per local repository, transition. So less technically savvy users won't have to worry about it in the first place.

Re: Git hash function transition plan

#40

Post by Ixio »

anton_gogolev wrote: post #36

NewHash is a terrible name - on par with Xbox One [X] and iPad New. Googling stuff will be hard, and good luck explaining to less technical-savvy users what is this all about. Plus, in 100 years, when SHA-256 is compromised, what would be the name of a new new format?

Can someone explain the name? It does not look like a good name. Or is NewHash just a placeholder name for the git project because the haven't made a final decision on a new hash function? (It's hard to google and find out)
Post reply on HN