Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The beginning of Git supporting other hash algorithms

github.com

Post reply on HN
Print view View original

61–70 of 128 posts

Re: The beginning of Git supporting other hash algorithms

#61

Post by tedunangst »

dahart wrote: post #22
zoren wrote: post #10

Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.

That's exactly what this change is. You mean why wasn't it that way before the change? Maybe because it wasn't ever needed before? Git's been good with only sha-1 for 12 years. Think about the flip side of your question... what were the alternatives 12 years ago, or 5 years ago? And why would someone write code for alternatives that aren't expected to be used and maybe don't exist? In my experience, generalizing ahea…

Even totally ignoring that SHA2 was a thing, anybody looking around would have noticed that MD4 was broken, MD5 was broken, and it would be unlikely that the hash of today would stand forever.

Re: The beginning of Git supporting other hash algorithms

#62

Post by tedunangst »

jlgaddis wrote: post #15
nuntius wrote: post #13

Earlier quoted context omitted.

Backwards compat requires that both old and new hashes work at the same time. A simple typedef is unlikely to handle all the semantics and space needed for such a change... It is often hard to generalize when N=1. Now that the N=1 use case is established and we are moving towards N=2, it is painfully obvious to all that a better abstraction is needed. Typedef or no, we would still need a full audit of the code to fin…

Perhaps you haven't read Linus' comments where he stated (more than a decade ago) that the usage of SHA1 here isn't for "security"? (Hint: that's why GPG signing commits is an option.)

Well, if SHA1 isn't for security, there's no reason to switch away from it today.

Re: The beginning of Git supporting other hash algorithms

#63

Post by hn_throwaway_99 »

loeg wrote: post #59
hn_throwaway_99 wrote: post #52

Earlier quoted context omitted.

It was, see comment from bk2204 above: > Yes, this is correct. The struct object_id changes don't actually change the hash. What they do, however, is allow us to remove a lot of the hard-coded instances of 20 and 40 (SHA-1 length in bytes and hex, respectively) in the codebase.

No. We're talking about zoren's hypothetical case where git used a typedef from the beginning, instead of littering char[20]s all over the tree. My prior comment was explaining why jffry's complaint is nonsensical (a typedef does not prevent moving from a single hash model to a multiple simultaneous hash model).

Hmm, not sure where there disagreement is, that's exactly what I'm saying. Obviously it wasn't done from the beginning, but the code is now changing from the char[20]s everywhere to the typedef precisely to be able support multiple hash functions.

Re: The beginning of Git supporting other hash algorithms

#64

Post by cormacrelf »

AlexCoventry wrote: post #53
pyed wrote: post #3

Earlier quoted context omitted.

Probably newer versions will commit only using a new hash algorithm, while completely able to deal with the old one

I don't have a good solution to this, but that sounds like it risks the same sort of crypto downgrade vulnerabilities which TLS cipher negotiation enabled.

Except if you drop SHA-1 support from a repository (goal #2 in the RFC on the top comment). Then your downgrades would only apply to new repos, and that's not really a vulnerability as there's no pre-existing trust; all the vectors available to you when you can create collisions are based on people not noticing changes.

It'd be like disabling TLS 1.0 and 1.1 on your server; a repo owner could just choose to do that. I guess the point stands if, like TLS downgrades, on the whole people don't specifically choose to do it and there are lots of vulnerable repos out there for a long time. Then it falls on GitHub/etc. to force repos to migrate fully.

Re: The beginning of Git supporting other hash algorithms

#65

Post by weinzierl »

bk2204 wrote: post #9

I'm the person who's been working on this conversion for some time. This series of commits is actually the sixth, and there will be several more coming. (I just posted the seventh to the list, and I have two more mostly complete.) The current transition plan is being discussed here: https://public-inbox.org/git/CA+dhYEViN4-boZLN+5QJyE7RtX+q6a...

Did you make any measurements or back of the envelope calculations what the real world performance impact of this change is.

I don't expect anything horrible, but still curious.

EDIT: After skimming OP I found a few answers.

The message from the The Keccak Team [1] is especially interesting. Summary is that we don't have to worry about performance degradation because of the hash calculation itself. There is a palette of functions which are considered to have a "security level [...] appropriate for your application" and are considerably faster than SHA1.

[1] https://public-inbox.org/git/91a34c5b-7844-3db2-cf29-411df5b...

Re: The beginning of Git supporting other hash algorithms

#66

Post by cormacrelf »

scrollaway wrote: post #19
jlgaddis wrote: post #15

Earlier quoted context omitted.

Perhaps you haven't read Linus' comments where he stated (more than a decade ago) that the usage of SHA1 here isn't for "security"? (Hint: that's why GPG signing commits is an option.)

When you GPG sign a commit, you just GPG sign its hash, you're not signing its diff alongside it.

That's what comes to mind every time someone brings up Linus' comments from way back when. If SHA-1 is insecure, then there is no way to have security. Forge an object, and GPG sign its commit, and you have broken the apparent security GPG signing was meant to bring. If SHA-1 was not meant for security, then security must have been a non-goal of Git.

The comments are brought up usually to explain why Linus didn't think much of it at the time, whereas they actually demonstrate the shift of thinking around what Git is meant to provide. Security is definitely a goal now, and the hash function is the critical piece of security infrastructure.

Re: The beginning of Git supporting other hash algorithms

#67

Post by dahart »

tedunangst wrote: post #61
dahart wrote: post #22

Earlier quoted context omitted.

That's exactly what this change is. You mean why wasn't it that way before the change? Maybe because it wasn't ever needed before? Git's been good with only sha-1 for 12 years. Think about the flip side of your question... what were the alternatives 12 years ago, or 5 years ago? And why would someone write code for alternatives that aren't expected to be used and maybe don't exist? In my experience, generalizing ahea…

Even totally ignoring that SHA2 was a thing, anybody looking around would have noticed that MD4 was broken, MD5 was broken, and it would be unlikely that the hash of today would stand forever.

Yes, true. Correct. That is still true, and applies to SHA-2 as well. And Linus was aware of exactly what you say, back in 2005.

My point was that the choice that was made was considered good enough for the purposes for which it was intended. In the context of the OP's comment, criticizing git for not making different code design choices doesn't mean that Linus was wrong, it may mean that the OP doesn't know and/or understand all the considerations Linus had. And Linus has said many times that the security of the hash is not the primary consideration in his design.

Git's choice of SHA-1 was not at the time predicated on having the single most unbreakable hash in existence, the hash's use is not for security purposes, and to talk with such incredulity about Linus' choice may be to misunderstand git's design requirements.

Re: The beginning of Git supporting other hash algorithms

#68

Post by lisper »

rurban wrote: post #58
bk2204 wrote: post #9

I'm the person who's been working on this conversion for some time. This series of commits is actually the sixth, and there will be several more coming. (I just posted the seventh to the list, and I have two more mostly complete.) The current transition plan is being discussed here: https://public-inbox.org/git/CA+dhYEViN4-boZLN+5QJyE7RtX+q6a...

I do like your hashname/nohash idea. If we could come up with a simple compression negotiation protocol also: zlib -> zstd. But this will be much harder, as hashes are internal only, and compression is in the protocol. kudos to brian m carlson to convince linus to use sha3-256 over sha256. this is really the only sane option we have.

> this is really the only sane option we have

Why?

Re: The beginning of Git supporting other hash algorithms

#69

Post by weinzierl »

rurban wrote: post #58
bk2204 wrote: post #9

I'm the person who's been working on this conversion for some time. This series of commits is actually the sixth, and there will be several more coming. (I just posted the seventh to the list, and I have two more mostly complete.) The current transition plan is being discussed here: https://public-inbox.org/git/CA+dhYEViN4-boZLN+5QJyE7RtX+q6a...

I do like your hashname/nohash idea. If we could come up with a simple compression negotiation protocol also: zlib -> zstd. But this will be much harder, as hashes are internal only, and compression is in the protocol. kudos to brian m carlson to convince linus to use sha3-256 over sha256. this is really the only sane option we have.

I don't understand what you mean by "hashes are internal only"? Aren't the sha1's everywhere right now. I mean not only in the protocol but also part of the UI and from there they even spread into bug trackers, documentation and so forth.

Re: The beginning of Git supporting other hash algorithms

#70

Post by hsivonen »

weinzierl wrote: post #65
bk2204 wrote: post #9

I'm the person who's been working on this conversion for some time. This series of commits is actually the sixth, and there will be several more coming. (I just posted the seventh to the list, and I have two more mostly complete.) The current transition plan is being discussed here: https://public-inbox.org/git/CA+dhYEViN4-boZLN+5QJyE7RtX+q6a...

Did you make any measurements or back of the envelope calculations what the real world performance impact of this change is. I don't expect anything horrible, but still curious. EDIT: After skimming OP I found a few answers. The message from the The Keccak Team [1] is especially interesting. Summary is that we don't have to worry about performance degradation because of the hash calculation itself. There is a palette…

If git changed to BLAKE2b, I'd expect a perf improvement over SHA-1.
Post reply on HN