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

11–20 of 59 posts

Re: Git hash function transition plan

#11

Post by benjaminjackman »

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" […

Sorry I wasn’t suggesting allowing any algorithm to be used just whichever one was chosen next it be encoded in a way that if it needs to be replaced again it could, and also if possible that numeric id for that algorithm be standardized beyond just git.

https://github.com/multiformats/multihash/blob/master/README...

Re: Git hash function transition plan

#12

Post by [deleted] »

pwagland wrote: post #2

So, this is the transition plan. Is there anywhere where we can find what progress has been made on the plan? As far as I can tell, it is only a plan at the moment? I also like the idea of a transition plan, but is there anywhere a proposed timeframe, for phasing out the non "post-transition" modes of operation? That is, as an organisation, is there anything that we can do with this now towards our future planning?

[deleted]

Re: Git hash function transition plan

#14

Post by a_t48 »

ris wrote: post #10

Funny, I always expected Git to transition by adding a stronger hash as a piece of metadata to each commit and continue using SHA-1 for the day-to-day identifier, seeing as most of the time Git doesn't actually go back and actually verify the whole commit chain unless you ask it to.

They actually considered the reverse (search for `Using hash functions in parallel`)

Re: Git hash function transition plan

#15

Post by lgierth »

oconnor663 wrote: post #6
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).

Something about multihash makes me worry it's a security risk. Like I worry that it encourages this mistake: 1. Define a new protocol with multihash somewhere in it. 2. Import a super convenient multihash library. 3. Verify all hashes with a simple library function. That sounds super natural and convenient to me, but if it means that you support MD4 by default, then you've introduced a downgrade attack into your prot…

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

Re: Git hash function transition plan

#16

Post by lgierth »

benjaminjackman wrote: post #9
cryptonector wrote: post #4

Earlier quoted context omitted.

Well-designed protocols generally include algorithm identifiers. It doesn't mean that upgrade will always be easy though. I really don't like given this a new name ("multihash"). We have a name already: algorithm agility. We should use that name. I also don't like this idea of having a standard for algorithm agility for hash functions (and another for encryption algorithms, and...). It's also not obvious that making…

Yeah this came out of the IPFS camp, might be sensible though to use the same numeric id numbers for the hashing algorithm ids though all other things being equal. Generally, and this is just my gut feeling, I think that for any hash code written to disk or stored in some way having an identifier for the hashing algorithm used is such a common bite you in the ass later thing that it makes sense to always just do it f…

> Generally, and this is just my gut feeling, I think that for any hash code written to disk or stored in some way having an identifier for the hashing algorithm used is such a common bite you in the ass later thing that it makes sense to always just do it from day one. To that end it’s easier to do day one if everyone agrees to a standard set of numeric codes.

Yes, that's the basic idea of all multiformats: "it's never gonna change" is considered harmful.

> Unifying here might allow git objects to be served natively over IPFS.

IPFS can already do that thanks to the CID format: https://github.com/ipld/cid

There's no good examples for Git specifically yet, but there's a good bunch of working code for transporting e.g. Ethereum and Zcash transaction blobs over IPFS. For Git it's in principle the same: import the raw object into IPFS, and starts addressing it with /ipfs/

Re: Git hash function transition plan

#17

Post by Piskvorrr »

pwagland wrote: post #2

So, this is the transition plan. Is there anywhere where we can find what progress has been made on the plan? As far as I can tell, it is only a plan at the moment? I also like the idea of a transition plan, but is there anywhere a proposed timeframe, for phasing out the non "post-transition" modes of operation? That is, as an organisation, is there anything that we can do with this now towards our future planning?

For something as widespread as Git, there is no "post-transition", I'm afraid: while maintained code will get migrated, old repositories will hang around Forever.

Note that Git is a protocol - all of its implementations will eventually need to change, and each repo using it as well. This is decentralized by the very purpose of Git.

Re: Git hash function transition plan

#18

Post by scrollaway »

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 signing all your commits for some security reason, you don't want that, aye?

So you'd want tags that are tracked separately and that's not easy to do. `git commit --sign` is going to include the signature in the commit, not create a separately-tracked tag with an appropriate name or whatever. It certainly sounds interesting, albeit unintuitive, and that summarizes git perfectly :)

Re: Git hash function transition plan

#19

Post by whyrusleeping »

benjaminjackman wrote: post #9
cryptonector wrote: post #4

Earlier quoted context omitted.

Well-designed protocols generally include algorithm identifiers. It doesn't mean that upgrade will always be easy though. I really don't like given this a new name ("multihash"). We have a name already: algorithm agility. We should use that name. I also don't like this idea of having a standard for algorithm agility for hash functions (and another for encryption algorithms, and...). It's also not obvious that making…

Yeah this came out of the IPFS camp, might be sensible though to use the same numeric id numbers for the hashing algorithm ids though all other things being equal. Generally, and this is just my gut feeling, I think that for any hash code written to disk or stored in some way having an identifier for the hashing algorithm used is such a common bite you in the ass later thing that it makes sense to always just do it f…

Just a quick note, while we still would really love to have git use multihash. You can already serve git objects natively over ipfs via: https://github.com/magik6k/git-remote-ipld

Which uses our new plugin system: https://github.com/ipfs/go-ipfs/blob/master/docs/plugins.md

Re: Git hash function transition plan

#20

Post by stouset »

lgierth wrote: post #15
oconnor663 wrote: post #6

Earlier quoted context omitted.

Something about multihash makes me worry it's a security risk. Like I worry that it encourages this mistake: 1. Define a new protocol with multihash somewhere in it. 2. Import a super convenient multihash library. 3. Verify all hashes with a simple library function. That sounds super natural and convenient to me, but if it means that you support MD4 by default, then you've introduced a downgrade attack into your prot…

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
Post reply on HN