Git hash function transition plan
github.com
Git hash function transition plan
1–10 of 59 posts
Re: Git hash function transition plan
#2So, 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?
Re: Git hash function transition plan
#3Only 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).
Re: Git hash function transition plan
#4Only 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).
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 every hash/MAC/public key payload carry an algorithm ID is the right design for every protocol (it's not), though for git it is.
Re: Git hash function transition plan
#5Previous discussion: https://news.ycombinator.com/item?id=13906804
Re: Git hash function transition plan
#6Only 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 protocol.
Re: Git hash function transition plan
#7Only 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"
Re: Git hash function transition plan
#8Only 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).
But does not solve the problem. Multihashes are not unique identifiers of a message, which is what git mostly uses hashes for. Now, instead of a single unique identifier, you have N possible ones, where N is the number of hash implementations your multihash library has. And it is not possible to convert between two hash types without having the original message.
Re: Git hash function transition plan
#9Only 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).
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 from day one. To that end it’s easier to do day one if everyone agrees to a standard set of numeric codes.
Multihash is the standard set of numeric codes for different algorithms I am aware of.
Unifying here might allow git objects to be served natively over IPFS.
Re: Git hash function transition plan
#10Funny, 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.