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

Linus on Git and SHA-1

plus.google.com

Post reply on HN
Print view View original

121–130 of 187 posts

Re: Linus on Git and SHA-1

#121

Post by ageofwant »

astrodust wrote: post #120
yeukhon wrote: post #115

Earlier quoted context omitted.

Well, open source software like Linux kernel has many obvious bugs for years go without notice. But his point is still extremely fair. There may be code no one really actively updating, but to even able to add random odd crud in the source code is really really really really hard. The effort is not worth it for any reasonable attackers. One would rather exploit an existing zero day or just infect network and wait to…

The kernel, and OpenSSH to name another project, is full of random crud nobody noticed. Everyone does their best to review patches and ensure things are sane when going in, but there's a lot of change in projects at scale, and sometimes the standards one patch wrangler has are different from another. Mistakes happen. If at-patch time is your only code review, you've got problems. If your code base is too huge to look…

And context is important as well. Worrying about sha-exploits in an environment like this is like wondering whether you watered the plants while the house burns down. The security-theater troupe wails like there's no tomorrow when their buttons get pushed. As Linus, said, given the context and the risk, its of almost no consequence.

Re: Linus on Git and SHA-1

#122

Post by infinity0 »

kupiakos wrote: post #98
infinity0 wrote: post #93

Earlier quoted context omitted.

Why go through all the effort of securing kernel.org etc etc etc when a simple s/SHA1/SHA512/g on git would suffice? (Ignoring the non-git infrastructure there, for the purposes of this argument.) Not just for him, but for everyone in the world who can't download directly from kernel.org? What's the point of GPG signing tags and commits and adding these as git features, when SHA1 pointers make it pointless? If the cr…

> when a simple s/SHA1/SHA512/g on git would suffice? That's ignoring a huge amount of changes that have to be made to have this work properly. Hardcoded constants must be changed. Backwards compatibility needs to be maintained for Git to be a viable product. Scripts that depend on the current length/format of SHA1 hashes would be broken if everything were changed all of a sudden. That would be much, much worse than…

All git repos have "repositoryversionformat", you can bump it. And nobody is going to complain about having to do a fresh clone, given what just happened.

"Not having security eggs in one basket" is exactly irrelevant here. Upgrading the hash does not make the other parts of the system weaker, and should have been done years ago. Yes, SHA2 will also become weak eventually - so then you bump it again. The point is to choose the best one for that time of history, which he has been resisting doing for years, based on bullshit pseudo-arguments about "trust".

No, git uses hashes in the same way that most other security system use hashes. The "trust" comes at a different point of the system. No hashes by themselves are "trusted" anywhere by any system. Git is not special in this regard. I repeat, Linus is talking horseshit and this horsehit argument is unfortunately getting repeated and spread around because of his position in the community.

I said the use of GPG is pointless, not SHA1 pointers, especially given his "trust" arguments. To exaggerate slightly, just to show you the point: it's like locking up a crappy lock (SHA1) inside a really secure safe (GPG). But this crappy lock is what opens up the real safe where your actual money is kept (the tree objects). And then we have Linus talking shit on the side saying the keys are not so important, but what he really gets security from is his trust in the delivery company that ships the safe around.

Re: Linus on Git and SHA-1

#123

Post by stinos »

leoh wrote: post #111
maxander wrote: post #96

I don't really get the threat model here. If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Is there anything nefarious they could accomplish through hash collisions that couldn't be done simply by editing commit history?

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice

Unless I'm misunderstanding how this would work in practice (I assume commits being added under my name or existing commits being modified?), I'm abolutely not buying that though. Way too general, no? I would likely notice something like that, but I know enough colleagues who are just as likely to not notice. Mostly because they don't fully grasp git so they're just like 'hmm, thing says I'm behind, ha I know the fix is pull, yes I'm a git wizard' and just pull then continue working without even checking what got changed.

Re: Linus on Git and SHA-1

#124

Post by btbuilder »

leoh wrote: post #111
maxander wrote: post #96

I don't really get the threat model here. If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Is there anything nefarious they could accomplish through hash collisions that couldn't be done simply by editing commit history?

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

How about very subtle in with the noise. Like this attempt to backdoor Linux in 2003:

https://lwn.net/Articles/57135/

Hard to get a collision though I'm guessing.

Re: Linus on Git and SHA-1

#125

Post by posterboy »

leoh wrote: post #111
maxander wrote: post #96

I don't really get the threat model here. If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Is there anything nefarious they could accomplish through hash collisions that couldn't be done simply by editing commit history?

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

>If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

Just as they noticed the intrusion on kernel.org servers after how long?

edit:

> If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right?

Sure, that's always true, in the worst case. Perfect security doesn't exist. But does it need to be an attacker? Couldn't it just happen that an important bugfix isn't recorded because the hash collides?

Re: Linus on Git and SHA-1

#127

Post by Dylan16807 »

posterboy wrote: post #125
leoh wrote: post #111

Earlier quoted context omitted.

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

>If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice. Just as they noticed the intrusion on kernel.org servers after how long? edit: > If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Sure, that's always true, in the worst case. Perfect security doesn't exist. But does it need to be an attack…

> Just as they noticed the intrusion on kernel.org servers after how long?

It doesn't work retroactively. That crud needs to be there in the initial commit when it's accepted by multiple people.

> Couldn't it just happen that an important bugfix isn't recorded because the hash collides?

The hashes will never collide if there's no attacker. And that bugfix would have to have a blob of crud in the 'good' version, which would stick out like a sore thumb.

Re: Linus on Git and SHA-1

#128

Post by colin_fraizer »

grzm wrote: post #65
colin_fraizer wrote: post #60

Earlier quoted context omitted.

A generally reasonable guideline, but in this case, I am actually criticizing the tribalism that makes people rise to that bait. It similarly leads to the discussion of how "I can't believe Linus is trying to defend SHA-1 when The Tribe already knows it is cryptographically 'bad'."

If you are taking the view that you're expecting downvotes to prove the point that people who are trying to uphold community standards are doing so blindly or ignorantly, you'll very likely think you're proven correct when you do receive downvotes. Can you blame them? You're explicitly flaunting the guidelines they choose to abide by while telling them they're wrong to do so in your special case .

Again: exactly my point. Most people care way more about "community" than about "truth". They are all-too-happy to throw out the Git baby with the crypto-SHA-1 bathwater so they can enjoy that warm feeling of being part of The Community. (Yes, I mean them as 'sneer caps'.)

This is why Barack Obama campaigned on his opposition to gay marriage (in favor civil unions). Not that he was wrong on that issue, simply dishonest. [I know no one who believed his statements in opposition to SSM.]

Oh, no, the Groupthink Club won't consider my ideas! (In fairness, HN is less groupthink-y and more open than most fora to examination of ideas on their merits.)

Re: Linus on Git and SHA-1

#129

Post by Dylan16807 »

bascule wrote: post #114
pvg wrote: post #107

Earlier quoted context omitted.

Why would you do that? Even if you don't know exactly what you want, are wrong about whether it's the basis of 'trust', for the purposes of writing git, you'd just take SHA-1. Nothing terrible is going to happen if it's both overkill and you aren't really building a secure system. You seem to be arguing, if I'm understanding you right, that you should only use a cryptographically strong hash iff you need all its prop…

I am likewise perplexed why "cryptographic hash functions are unnecessary in the absence of an attacker" is such a difficult concept for you to grasp. It is not an "odd angle". It is literally the very purpose for which they were created in the first place: to defend against attacks (preimage, collision) If there are no attackers, the cryptography buys you nothing and merely makes the system slower. Again, to go back…

> I am likewise perplexed why "cryptographic hash functions are unnecessary in the absence of an attacker" is such a difficult concept for you to grasp.

Because you can't seem to tell the difference between "unnecessary" and "shouldn't be done".

If I build a shed then using larger screws on the door might be unnecessary but it only costs me .2% more and I know it won't fall over.

Using a recent SHA function might be overkill in a non-crypto context but it's high-quality and fast. And there's existing libraries for whatever language you want. Why the hell would anyone use CRC128? I've never even heard of it before.

It's a good hash choice, no matter how unnecessary.

Re: Linus on Git and SHA-1

#130

Post by Kubuxu »

joatmon-snoo wrote: post #105
snakeanus wrote: post #64

Earlier quoted context omitted.

They did break backwards compatibility with git v2.0 but sadly they did not bother to change the hash function.

What backwards compatibility was broken?

Little bits in CLI interface https://blogs.atlassian.com/2014/06/happened-git-2-0-full-go...
Post reply on HN