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

51–60 of 128 posts

Re: The beginning of Git supporting other hash algorithms

#51

Post by jlgaddis »

ufmace wrote: post #41
CydeWeys wrote: post #8

Earlier quoted context omitted.

I think backwards incompatibility would be acceptable. Add read support for the new format to git, but then don't have widespread repositories using the new format until some period of time later. By the time they do become commonplace, everyone should already be running a version of git supporting them. It's not exactly hard to upgrade git in most situations anyway, just a simple invocation of: $ sudo $PKG_MGR upgra…

Well, it's not hard to update the command-line git client on Unix-y systems with package management. The trouble will be with the hundreds/thousands of other programs that use Git in various ways and are essential to development workflows in various places. Github themselves, Microsoft and Jetbrains IDEs, etc.

I would assume that most other stuff uses libgit2 (except maybe the Microsoft stuff). Is that not a safe assumption?

Re: The beginning of Git supporting other hash algorithms

#52

Post by hn_throwaway_99 »

loeg wrote: post #34
jffry wrote: post #12

Earlier quoted context omitted.

If you have a repo with a lot of GPG signed commits, or you just don't want to change all your commit IDs (because you reference them in other places), then it'd be very valuable to be able to have a repo that's mixed old and new hashes. Also your Git binary, if compiled with only the One True Hash™, wouldn't be able to work with older repos at all because the hashes it's calculating are now different. (Edit: Another…

The one typedef could have just been changed from char[20] to 'struct objectid' to support multiple hash types.

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.

Re: The beginning of Git supporting other hash algorithms

#53

Post by AlexCoventry »

pyed wrote: post #3
VMG wrote: post #2

Is there some explainer on how the support will look like in the end? I'm curious to know how multiple hash algorithms will be supported in parallel.

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.

Re: The beginning of Git supporting other hash algorithms

#54

Post by eklitzke »

CydeWeys wrote: post #49
ufmace wrote: post #41

Earlier quoted context omitted.

Well, it's not hard to update the command-line git client on Unix-y systems with package management. The trouble will be with the hundreds/thousands of other programs that use Git in various ways and are essential to development workflows in various places. Github themselves, Microsoft and Jetbrains IDEs, etc.

There's two potentially mitigating factors at play here: I suspect a lot of the tools you mentioned also already treat hashes as strings, not as 160 bit numeric types. The entire front-end JS for GitHub, for example, just uses strings. That's what I'd do if I were writing IDE integrations and such too. Secondly, the new format will likely still be a 160-bit numeric type, just calculated using a different hash algorit…

Just using the first 160 bits of a new hash function was proposed at one point, but it's not part of the current plan. The new plan is to introduce full SHA3-256 hashes (which are 256 bits in size). More information here: https://docs.google.com/document/d/18hYAQCTsDgaFUo-VJGhT0Uqy...

(Of course, CLI and frontend tools could still truncate display output to 40 hex characters, but internally full size hashes will be used.)

Re: The beginning of Git supporting other hash algorithms

#55

Post by foldr »

Y_Y wrote: post #20
irontoby wrote: post #11

Why don't you ask Linus, I'm sure he will calmly and respectfully explain the answer while apologizing for the trouble :)

I feel like Linus (and others) have earned the right to be assholes on the mailing lists. He's demonstrated good judgement and made huge contributions, if he doesn't feel the need to be nice i don't think he should have to.

No-one has the right to be an asshole.

Re: The beginning of Git supporting other hash algorithms

#56

Post by dahart »

loeg wrote: post #35
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…

> what were the alternatives 12 years ago, or 5 years ago? SHA-2. > And why would someone write code for alternatives that aren't expected to be used and maybe don't exist? Well, the real question is why someone picked SHA-1 over SHA-2 in 2005 when attacks that reduced its strength were already being demonstrated.

Linus has explained why he picked SHA-1. I'm not Linus, and I'm not defending his choice, but he has said repeatedly that git's hash is primarily for indexing and error correction, and not primarily for security. Clearly he felt like SHA-1 was "good enough". And if you have something that's "good enough" there are reasons not to write code for alternatives you're not going to use.

Re: The beginning of Git supporting other hash algorithms

#57

Post by CydeWeys »

eklitzke wrote: post #54
CydeWeys wrote: post #49

Earlier quoted context omitted.

There's two potentially mitigating factors at play here: I suspect a lot of the tools you mentioned also already treat hashes as strings, not as 160 bit numeric types. The entire front-end JS for GitHub, for example, just uses strings. That's what I'd do if I were writing IDE integrations and such too. Secondly, the new format will likely still be a 160-bit numeric type, just calculated using a different hash algorit…

Just using the first 160 bits of a new hash function was proposed at one point, but it's not part of the current plan. The new plan is to introduce full SHA3-256 hashes (which are 256 bits in size). More information here: https://docs.google.com/document/d/18hYAQCTsDgaFUo-VJGhT0Uqy... (Of course, CLI and frontend tools could still truncate display output to 40 hex characters, but internally full size hashes will be u…

Woah, that's disorienting to be linked to a bluedoc unexpectedly like that, considering I'm not on my work account. I ever recognize one of the authors.

Re: The beginning of Git supporting other hash algorithms

#58

Post by rurban »

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.

Re: The beginning of Git supporting other hash algorithms

#59

Post by loeg »

hn_throwaway_99 wrote: post #52
loeg wrote: post #34

Earlier quoted context omitted.

The one typedef could have just been changed from char[20] to 'struct objectid' to support multiple hash types.

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

Re: The beginning of Git supporting other hash algorithms

#60

Post by rocqua »

IncRnd wrote: post #50
rocqua wrote: post #31

Earlier quoted context omitted.

The threat models in which 64 bits of security (by birthday attack on 128bit hashes) is insufficient are really limited.

That is misleading, since a birthday attack is not required. The security strength of hashes is not measured by the length of the hashes. md5 was first "broken" in 1995. As of 10 years ago, a collision attack took only a few seconds. Plus, there are a _number_ of other attacks on the hash.

The argument I replied to concerned best-case for length. I.e. a perfect hash at 128 bits delivers 64 bits of security against collisions. (Note the 'perfect' part)

64 bits of security is good enough against most non-nation state actors.

Obviously, MD5 (and sha-1) aren't anywhere near perfect hashes. And obviously, you need to look at more than length when judging a hash.

Basically my point was that md5's hash length isn't a big problem.

Post reply on HN