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

41–50 of 59 posts

Re: Git hash function transition plan

#41

Post by bsimpson »

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…

Tags are also how the code review tool Phabricator sends diffs to CircleCI for testing. If you have that integration enabled, you quickly end up with more GitHub Releases than your project has commits.

Re: Git hash function transition plan

#42

Post by hdhzy »

Ixio wrote: post #40
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)

https://github.com/git/git/blob/master/Documentation/technic...

Re: Git hash function transition plan

#43

Post by bjackman »

So it says the protocol won't be extended initially, only the repo format. I'm trying to figure out the implications of that. IIUC this basically boils down to: can we make sure that when you have a signed tag (i.e. a hash signed with GPG), the content of your repo is truly the same as what the signer intended, and not a collision generated by a bad actor.

It says that there will be a new format for signed objects, i.e. you will now be able to sign tags with NewHash. But if the format is not extended, does that mean you can't get push or fetch those objects? If so then I believe this is just foundational work with no immediate functional impact, right?

(Not shitting on it btw, it's obviously still a Good Idea!)

Re: Git hash function transition plan

#44

Post by hdhzy »

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.

> ...it seems like a block chain would be ideal

If I could get just 1 satoshi every time I see this suggestion...

Re: Git hash function transition plan

#45

Post by masklinn »

bsimpson wrote: post #41
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…

Tags are also how the code review tool Phabricator sends diffs to CircleCI for testing. If you have that integration enabled, you quickly end up with more GitHub Releases than your project has commits.

Been there, done that, it's really not a good idea.

Re: Git hash function transition plan

#47

Post by joseluisq »

> In early 2005, around the time that Git was written, Xiaoyun Wang, > Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1 > collisions in 2^69 operations. In August they published details. > Luckily, no practical demonstrations of a collision in full SHA-1 were > published until 10 years later, in 2017.

> The hash function NewHash to replace SHA-1 should be stronger than > SHA-1 was: we would like it to be trustworthy and useful in practice > for at least 10 years.

Re: Git hash function transition plan

#48

Post by brlewis »

scrollaway wrote: post #24
finnthehuman wrote: post #21

Earlier quoted context omitted.

> 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?

Point being that one shouldn't cargo-cult workflow from github.

The point is phrased using an old pop culture reference: https://en.wikipedia.org/wiki/Smith_and_Dale#.22Dr._Kronkhei...

Re: Git hash function transition plan

#49

Post by acdha »

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

3) the users who do lock it down will be harangued about not being compatible with less secure versions barring a major incident

Re: Git hash function transition plan

#50

Post by jrochkind1 »

stevekemp wrote: post #32
jrochkind1 wrote: post #25

Earlier quoted context omitted.

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/

All releases are tags, not all tags are releases. Have you used the feature?

> 1. On GitHub, navigate to the main page of the repository.

> 2. Under your repository name, click Releases.

> 3. Click Draft a new release.

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

Pushing a tag does not create a release. You can have lots of tags that are not releases. You have to choose to create a release, as a separate step. All your releases are tagged though, yes (as they should be, using github and it's release feature or not, to identify the state of the repo from which the release was built).

Post reply on HN