Live data from Hacker News

Linus' reply on Git and SHA-1 collision

marc.info

261–270 of 273 posts

Re: Linus' reply on Git and SHA-1 collision

#261
post #256

Earlier quoted context omitted.

Gentoos emerge and FreeBSD port are package managers that preferably build from source. At least emerge also accepts git sources, with tags and commit specifiers. I haven't used bsd in a while on a prod system, but I'd not be surprised if port gained the same functionality - after all whether you're pulling a tarball and use a checksum for integrity checking or hand the task off to git makes exactly no difference at…

First, portage and ports are OS-supplied mechanism for installing software. They are nothing like pip or gems or npm, which only can install things written in their respective languages of choice and fail miserably for modules touching any library external to them (unless you manually ensure the library's and compiler toolchain's presence, that is). Second, ports and portage have support for and networks of mirror se…

Gems can be used to installing anything. It often build java, go, C, C++ and I think I heard it could do rust once, but generally anything in faster languages to create faster versions of the implementation of the functionality for a given gem.

I bring that up to highlight some of the wrong assumptions you make. You make several needless assumptions and use those to draw funny distinctions between things. I am not even sure of the point anymore.

likely any of these systems could be used in a variety of environments for a variety of purposes.

Re: Linus' reply on Git and SHA-1 collision

#262
post #261
post #256

Earlier quoted context omitted.

First, portage and ports are OS-supplied mechanism for installing software. They are nothing like pip or gems or npm, which only can install things written in their respective languages of choice and fail miserably for modules touching any library external to them (unless you manually ensure the library's and compiler toolchain's presence, that is). Second, ports and portage have support for and networks of mirror se…

Gems can be used to installing anything. It often build java, go, C, C++ and I think I heard it could do rust once, but generally anything in faster languages to create faster versions of the implementation of the functionality for a given gem. I bring that up to highlight some of the wrong assumptions you make. You make several needless assumptions and use those to draw funny distinctions between things. I am not ev…

You can do anything, including Rust, yeah. You can also distribute pre compiled stuff.

Re: Linus' reply on Git and SHA-1 collision

#263

Earlier quoted context omitted.

I don't like the living-on-the-edge-attitude that Linus and others here promote regarding Sha1 in git. First, attacks only get faster over time. What costs millions today is likely to be achievable on commodity hardware in the coming years. Second, attacks only get more flexible over time. A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]. Third, devising an update strategy an…

"On the edge" "A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]" so they'd have at least years to fix it were they using md5? He says they'll migrate, but it's no reason to go crazy. If anything, calmness of this sort is what we need more of (this industry, anyway... we go crazy about stuff way too much).

As someone who has done "security" full time before - there's nothing worse than the "Security By Jumping Up And Down Like An Excited Monkey" policy.

Fix what's broken, no doubt. But stay rational and look at the problem from all perspectives.

Re: Linus' reply on Git and SHA-1 collision

#264
post #141

Earlier quoted context omitted.

Erm... Which ones?

Almost all of them: Npm: https://docs.npmjs.com/cli/install Bundler: https://bundler.io/git.html Homebrew: https://github.com/Homebrew/brew

The ones that actually matter are more like apt or yum.

Re: Linus' reply on Git and SHA-1 collision

#265
post #113

There is not mutch risk now, but git should be able to switch to another and longer hash. Truncating another hash to 40 chars does not "fix" the problem. It just move it into another place. Another possibility, but this is a hack to keep key length to 40 chars, would be to change key encoding from hex encoding to base64. In 40 chars you could encode 240 bits instead of 160. It is preferable to get rid of the hard cod…

The problem isn't the length of the text representation of the hash, it's the length of the actual binary representation of the hash.

Re: Linus' reply on Git and SHA-1 collision

#266
post #113

There is not mutch risk now, but git should be able to switch to another and longer hash. Truncating another hash to 40 chars does not "fix" the problem. It just move it into another place. Another possibility, but this is a hack to keep key length to 40 chars, would be to change key encoding from hex encoding to base64. In 40 chars you could encode 240 bits instead of 160. It is preferable to get rid of the hard cod…

The problem isn't the length of the text representation of the hash, it's the length of the actual binary representation of the hash.

The comment to whitch Linus respond reports that there are 40 constants in many places in the git code. The bit size of a SHA1 hash is 160 bits which holds in 20 bytes. In hexadecimal, the length is 40chars. So the problem reported in the initial comment was the text length, not the bit length.

Of course there is probably 20 hardcoded in many places too. So in this case the bit length is an issue too. You are right. Switching to base64 encoding would not solve the hardcoded bit length if any.

Using file hashes as file identifier doesn't look like a good idea as suggested here https://valerieaurora.org/hash.html because hash lifetime are short. The system should support changing the hash every year. The work required to compute hashes increases too.

Re: Linus' reply on Git and SHA-1 collision

#267

Earlier quoted context omitted.

Haha you reminded me of the old riddle about how British engineers decided where to place armor on their bombers, because, "if they put it everywhere the plane wouldn't get off the ground!"

Specifically, during the war the engineers took a Bayesian approach and put armor on the bombers in locations where bombers which came back did not have damage. Reason being that hits in those sections of the planes were more likely than not resulting in fatalities. Smart thinking.

Funny thing is, they used all this advanced math to reach the same conclusion the 5 years old child would come to: armor should be put around engine and ammunition storage. Too much education sometimes makes you really stupid.

Re: Linus' reply on Git and SHA-1 collision

#268
post #235

Earlier quoted context omitted.

Where did it get it from?

From github, the first time only. Not every single time.

Isn't getting it from GitHub the first time vulnerable to attack? Consider when you're scaling up or replacing a failed host.

Re: Linus' reply on Git and SHA-1 collision

#269
post #56

Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…

>1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. This is a big lie. When the -S flag is used, git signs the SHA-1 of the commit. Moreover HTTPS does not provide any form of authentication due to the extremely broken CA model. NSA could simply ask any CA to give them a cert for github for example. Not to mention that https would only authenticate that you are talking to the github se…

Fully agree to everything you said, one point:

> Didn't Git v2.0 break backwards compatibility?

No, it did not.

Re: Linus' reply on Git and SHA-1 collision

#270
post #236
post #194

Earlier quoted context omitted.

You can always break append only logs, the point is, it's detectable.

What do you mean by detectable in the context of Git-as-append-only-log?

Mirrors that pull down the version with rewritten history will not be able to run a fast-forward (because they will contain commits that are not in the upstream version), and will loudly complain.
Post reply on HN