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

51–59 of 59 posts

Re: Git hash function transition plan

#54

Post by mathw »

bjackman wrote: post #43

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…

It explains this further rather later in the document.

There's a compatibility mode, where it understands a translation between SHA-1 named objects and NewHash named objects, and translates them at the boundary - i.e. during a pull or a push.

Obviously you're at risk to some extent of flaws in SHA-1 being exploited in your remote, although presumably if the translation layer detects the SHA-1 of something didn't change but the NewHash did then it'll scream.

It does seem this is a temporary situation though, as it mentions in one small sentence that for the final transition stage they envisage the protocol also supporting NewHash, so they can throw away all SHA-1 metadata everywhere. What they don't address in that plan is how the protocol gets extended, but they do clearly rely on that happening for the full transition to take place.

Re: Git hash function transition plan

#55

Post by jwilk »

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.

It's written an asciidoc, which GitHub can render too. It's a matter of changing the extension or adding vim modeline.

Re: Git hash function transition plan

#57

Post by yes_or_gnome »

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…

Based on my own research, it appears that the first git tag was created before the first git commit.

The first tag (?) points to a tree.

  $ git cat-file -p v2.6.11-tree
  object c39ae07f393806ccf406ef966e9a15afc43cc36a
  type tree
  tag v2.6.11-tree

  This is the 2.6.11 tree object.

  NOTE! There's no commit for this, since it happened before I started with git.
  Eventually we'll import some sort of history, and that should tie this tree
  object up to a real commit. In the meantime, this acts as an anchor point for
  doing diffs etc under git.
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.2.4 (GNU/Linux)

  iD8DBQBCeV/eF3YsRnbiHLsRAl+SAKCVp8lVXwpUhMEvy8N5jVBd16UCmACeOtP6
  KLMHist5yj0sw1E4hDTyQa0=
  =/bIK
  -----END PGP SIGNATURE-----
First commit

  $ git cat-file -p v2.6.12-rc2
  object 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
  type commit
  tag v2.6.12-rc2

  Linux v2.6.12-rc2 release
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.2.4 (GNU/Linux)

  iD8DBQBCbW8ZF3YsRnbiHLsRAgFRAKCq/TkuDaEombFABkPqYgGCgWN2lQCcC0qc
  wznDbFU45A54dZC8RZ5JxyE=
  =ESRP
  -----END PGP SIGNATURE-----
Unfortunately, I don't think I can confirm my suspicion using git alone. Maybe if I look at some mailing lists around July/August 2005 I could get a more accurate confirmation.

This is due to the fact that those tags pre-date the tagger header which came a short while later.

  $ git cat-file -p v2.6.13
  object 02b3e4e2d71b6058ec11cc01c72ac651eb3ded2b
  type commit
  tag v2.6.13
  tagger Linus Torvalds  1125272548 -0700

  Linux 2.6.13 release
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.1 (GNU/Linux)

  iD8DBQBDEkvwF3YsRnbiHLsRAp5tAKCEK1XmOropxvWp+k9eiTcafNMXXACcDAVb
  +hOwdKI+bi84SSNNSGnSXGg=
  =cnNS
  -----END PGP SIGNATURE-----
Edit:

Just to reenforce the "First Commit" claim, here's the rev-list for the commit and the commit contents. (Notice it has no "parent" commit.

  $ git rev-list 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
  1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

  $ git dump 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
  tree 0bba044c4ce775e45a88a51686b5d9f90697ea9d
  author Linus Torvalds  1113690036 -0700
  committer Linus Torvalds  1113690036 -0700

  Linux-2.6.12-rc2

  Initial git repository build. I'm not bothering with the full history,
  even though we have it. We can create a separate "historical" git
  archive of that later if we want to, and in the meantime it's about
  3.2GB when imported into git - space that would just make the early
  git days unnecessarily complicated, when we don't have a lot of good
  infrastructure for it.

  Let it rip!

Re: Git hash function transition plan

#58

Post by scrollaway »

brlewis wrote: post #48
scrollaway wrote: post #24

Earlier quoted context omitted.

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

It's not cargo-culting, it's not from github, and it's not even a workflow. If that was the point, it's a terrible one to make. I genuinely don't understand how people found that comment insightful, or anything short of trolling/hostile, but whatever.

Re: Git hash function transition plan

#59

Post by abritinthebay »

rblatz wrote: post #33
abritinthebay wrote: post #26

Earlier quoted context omitted.

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.

Exactly! JWT is a much misunderstood system it seems. Though it doesn’t exactly help itself by being quite complex
Post reply on HN