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?
yaourt on archlinux
Linus' reply on Git and SHA-1 collision
161–170 of 273 posts
Re: Linus' reply on Git and SHA-1 collision
#162Correct me if I'm wrong, but if you're letting untrusted people push to your git repositories, you're pretty much screwed anyway. Given a case where someone with permission to push gets compromised and a malicious actor can pull this sha-1 attack off, aren't there bigger problems at hand? The history will be there and detectable or if they're rewriting history, usually that's pretty noticeable too. I may be totally m…
You can sign commits and tags. If you do this you can still offer some guarantees about your repo even if non-trusted people are able to access it (say, if you host your repo on github but don't necessarily trust them or something similar). If I have Linus's public key I can fetch the kernel from anywhere and just make sure to validate the signature of the tag I want to use for instance.
If you were able to forge commits with the same SHA-1 you might theoretically be able to rewrite the history without invalidating the signatures, which would be a problem. We're not there yet though, but it's one step closer.
Re: Linus' reply on Git and SHA-1 collision
#163Earlier quoted context omitted.
I often see the suggestion that storing the length of the file too helps secure against hash collisions because it adds the additional requirement that both files be the same length, but every single MD5 and SHA1 collision I've seen are between values of the same length anyway! Where does this myth come from?
It's not a myth. It is obvious that you can find collisions with this constraint. When you make a collision attack such as this, you start with 2 inputs and have a target size, i.e. with a specific size of the padded data, then you simply iterate over paddings (of the same size), and when you find a collision, it will be of the correct size. But it does add an extra constraint, and it prevent attacks that rely on ran…
I can agree it strictly limits the type of attacks that can be done, but it doesn't appear to be any practical increase in security. It's like arguing for adding another step in the manufacturing process of bulletproof armor to add a few extra atoms to the armor's thickness. Sure it theoretically adds some protection against some 0.000...1% of bullets that would have just barely had enough force to get through, but it wouldn't have made a difference to any single previously observed successful attack of a similar nature. The fact that someone would argue that this increase in defense is good enough to obviate the need of switching to a different type of stronger defense seems to imply a misunderstanding of hashing.
Re: Linus' reply on Git and SHA-1 collision
#164Earlier quoted context omitted.
I am told the gun is also quite good at shooting ground troops. A relative of mine had an A-10 stay with his group most of the night. Every time the enemy decided to go after them the A-10 came back and made them rethink their actions.
The A-10 delivers rounds at a rate that the individual shots are indistinguishable to the the human ear. Another story that I've heard is that a B-1 flying at operational altitude (200 ft above ground level, mach 2) was often as effective as dropping munitions.
The B-1 can not even reach Mach 1 at such a lot altitude. It's maximal operating velocity (at any altitude) is Mach 1.25.
People tend to really underestimate how much harder it is to go faster once you reach 0.90 or so, especially at low altitudes.
Re: Linus' reply on Git and SHA-1 collision
#165Pertinent 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…
Not entirely true, it relies on SHA-1 for security when you use PGP signatures. That makes it possible to fetch git repositories from untrusted sources if you can validate the signatures.
I don't really see how HTTPS is relevant here either, I clone most of my repositories over SSH for instance. And you can use git over plain HTTP too.
Re: Linus' reply on Git and SHA-1 collision
#166Earlier quoted context omitted.
From a custom package you have built? Did you know that RPMs and DEBs don't grow on magical trees, but are built?
So, the problem still stands, theoretically. Not only do you likely need to populate your host with packages not from your host. But also, your host will also still be connect to a public net, even if only indirectly (e.g. private net), and hence potentially manipulated.
No, you misunderstood what is actually the problem here. Pulling under
deployment some code from random resource from the internets that can go down
or get deleted at a whim and you can't easily move to just some other mirror
and you don't even control when the thing will be up back, that's the problem.
Not the trust you need to put to use the code (this is still there,
obviously). And the very same comment applies to third-party package
repositories, like PPAs in Ubuntu.
Not to mention that with pre-built binary packages your deployment speed and repeatability get significantly better, as you don't need to rebuild the artifacts every single time.
Re: Linus' reply on Git and SHA-1 collision
#167Earlier quoted context omitted.
Don't forget the extra computation cost with a more complex hash.
Which is largely irrelevant on desktops. Nobody's using git on embedded devices, so hash computational cost shouldn't be the deciding factor. Maybe people storing BLOBs will notice.
There are blobs in the kernel and speed was a very important motivation when kernel switched to git.
Re: Linus' reply on Git and SHA-1 collision
#168Earlier quoted context omitted.
Moore's law still holds, and is expected to hold true until at least 2025 (see wikipedia). I don't think it will be done by then, but that is just guess work.
How much faster is a cpu from 2012 and a cpu from today when you compare them by single thread performance @ 3 ghz.
Single thread performance is completely irrelevant to Moore's law.
Re: Linus' reply on Git and SHA-1 collision
#169Correct me if I'm wrong, but if you're letting untrusted people push to your git repositories, you're pretty much screwed anyway. Given a case where someone with permission to push gets compromised and a malicious actor can pull this sha-1 attack off, aren't there bigger problems at hand? The history will be there and detectable or if they're rewriting history, usually that's pretty noticeable too. I may be totally m…
What if there's a deep-cover operative for KGB/NSA/... who's already a respected kernel contributor? That's not implausible - those agencies already have people with the relevant skills. Hell, the NSA openly contributed SELinux.
Now suppose they've contributed a commit that collides with another one that puts a backdoor in, and they use this very selectively, MitMing git clones made by high-value targets. If anyone were to compare one of those clones against the real kernel repository then that would burn their operative, sure. But how likely is it that anyone would ever do that?
Re: Linus' reply on Git and SHA-1 collision
#170Earlier quoted context omitted.
> There is no way to securely deploy a package directly from the internet. Fetching a file from the internet and verifying it against a hash or signature is the only way to securely deploy a package from the internet. This is exactly one of the use cases theses cryptographic primitives are built for. Don't blame the users when they utilize the tools the way they are supposed to be, blame the tools when they fail when…
apt-get can (and do) check signatures of repos But yeah, you could put an unverified repos to be used
Git has tag signing, surely there's a way to clone a specific tag and check the signature against a specific GPG key fingerprint?