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

Linus' reply on Git and SHA-1 collision

marc.info

Post reply on HN
Print view View original

201–210 of 273 posts

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

#201

Post by tokenizerrr »

_pmf_ wrote: post #196
throwaway7767 wrote: post #190

Earlier quoted context omitted.

> 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. Some security-focused developers sign git tags and/or commits, specifically to have things verifiable end-to-end and not having to trust HTTPS and all the middle men that entails. Would that not be a case where git relies on SHA1 for security? Someone could replace a tag or commit with a malicious version that verifies fine since it…

> Some security-focused developers sign git tags and/or commits, specifically to have things verifiable end-to-end and not having to trust HTTPS and all the middle men that entails. This is a completely orthogonal, separate layer of security that has nothing to do with this particular issue.

Maybe quote the second line as well?

> Would that not be a case where git relies on SHA1 for security? Someone could replace a tag or commit with a malicious version that verifies fine since it has the same hash the original developer signed.

What's your response to this? To me it seems like this would be a serious issue.

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

#202

Post by dozzie »

amingilani wrote: post #183
dozzie wrote: 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

And which of these are "package systems supplied by your operating system"?

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

#203

Post by dozzie »

yellowapple wrote: post #191
dozzie wrote: post #141

Earlier quoted context omitted.

Erm... Which ones?

Most language-specific ones do. OS-specific ones less commonly do; Chocolatey, for example, can (IIRC) install packages by running PowerShell scripts, which may or may not include pulling from GitHub.

> Most language-specific ones do.

Those are development tools, not deployment ones (even though they are used as such; programmers usually don't bother with learning what sysadmins do, so it's not a surprise).

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

#204

Post by Kubuxu »

almog wrote: post #4

Do you know if git objects' size header was designed to deal with a possible collision or does it serve another purpose as well? Just some context - git calculates an object's name by his content in the following way. Say we have a blob that represent a file who's content is 'Here be dragons', then the file name would be: printf "blob 17\0Here be dragons\!\n" | openssl sha1 # => a54eff8e0fa05c40cca0ab3851be5aa8058f20…

Also git compresses before hashing IIRC.

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

#205

Post by makomk »

Perseids wrote: post #149
uiri wrote: post #112

Earlier quoted context omitted.

Wow, Linus raises an entirely different issue which is that the PDF-based attack won't work on git at all . Due to length prefixing, it is extremely difficult to insert nonsense into the middle of a git object which is how this attack works on PDFs. Linus correctly notes that using the first forty bytes of SHA-256 is an option if an attack against git's use of SHA1 were developed. 1) Git doesn't rely on SHA-1 for sec…

> Wow, Linus raises an entirely different issue which is that the PDF-based attack can't and won't work on git at all. Due to length prefixing it is extremely difficult to insert some nonsense into the middle of a git object which is how this attack works on PDFs. Please note that the shattered-{1,2}.pdf files both have exactly the same length. And even with cleartext it is easy to pad passages so they contain the sa…

Indeed, they probably have to have the same length since the length is inserted into the final block as part of SHA-1 hashing and every block after the collision must be the same. I don't think it's even possible to create a MD5 collision between two documents of different length yet.

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

#206

Post by victorNicollet »

otabdeveloper wrote: post #108
euyyn wrote: post #91

Earlier quoted context omitted.

It's not so inconceivable, after seeing the PDF collision, to contribute to another project a commit whose hash has a collision with another malicious commit you keep up your sleeve. Not saying it's easy, but now it's on the horizon.

> Not saying it's easy, but now it's on the horizon. Not really. It's not a preimage attack. They spent several hundred dollars to find two random byte strings with the same SHA1 hash. There's still no way to SHA1-collide a specific byte string instead of random junk.

This is exactly what euyyn is saying: create two files with the same SHA1 (by adding bytes of gibberish to an unused section), commit one to the repository, and now you have an collision available.

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

#207

Post by [deleted] »

Perseids wrote: post #182
notfed wrote: 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…

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…

[deleted]

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

#208

Post by MereInterest »

hermitdev wrote: post #62
DiabloD3 wrote: post #31

Earlier quoted context omitted.

The A-10 isn't a plane, it's a gun with a plane wrapped around it. And it hunts tanks.

I'm sad that the AF wants to retire this plane. This plane was defined with one purpose: build a plane around this gun, that being a 30mm autocannon firing depleted uranium shells (not radioactive) that fires at such a rate that it retards the velocity of the plane carrying the gun, and would melt the gun if it fired from full to empty continuously. The plane was built for survivability. It can withstand an engine be…

As a side note, depleted uranium is certainly still radioactive. "Depleted" refers to the percentage of U-235, the isotope used for making nuclear weapons. Only about 0.7% of naturally occurring uranium is U-235, with the rest being mainly U-238. U-238 emits alpha particles, with a half life of about 4 billion years.

The radioactivity is unrelated to its use as bullets, which relies on its high density, but it is radioactive.

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

#209

Post by Xylakant »

dozzie wrote: post #141
amingilani wrote: post #138

Earlier quoted context omitted.

Package managers allow you to download from git repositories too. He'd suffer from the same attack vector.

Erm... Which ones?

getoos emerge can. A package definition contains a source URL and git urls (with branches and tags) are accepted sources.

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

#210

Post by _pmf_ »

tokenizerrr wrote: post #201
_pmf_ wrote: post #196

Earlier quoted context omitted.

> Some security-focused developers sign git tags and/or commits, specifically to have things verifiable end-to-end and not having to trust HTTPS and all the middle men that entails. This is a completely orthogonal, separate layer of security that has nothing to do with this particular issue.

Maybe quote the second line as well? > Would that not be a case where git relies on SHA1 for security? Someone could replace a tag or commit with a malicious version that verifies fine since it has the same hash the original developer signed. What's your response to this? To me it seems like this would be a serious issue.

You're right.
Post reply on HN