In this case, it is not merely sufficient to find a collision, but to find a collision that is also a valid Git commit, implements a vulnerability, and, ideally, is not immediately obvious at first glance it is a hack (i.e. having kilobytes of garbage data in the commit diff). This is much harder than just finding a random set of bytes that just happens to match the commit SHA-1.
Now, it could be that an organisation like the NSA is sufficiently ahead of public crypto technology that it is capable of not only finding a SHA-1 collision in feasible time, but is also able to craft a malicious Git commit with an identical SHA-1 to a legitimate commit. Inserting such a commit into the Linux source in an appropriate place might result in compromised kernels appearing in commercial products.
But... I kinda doubt anyone is that far ahead, and in any case, it seems extremely risky to try to play such a high-value advantage in a public repository. If someone happens to spot your faked commit, suddenly everyone knows what you are capable of.
So whilst Git would be more secure using SHA-512 or an equivalent, it's currently very unlikely that anyone has the practical capability and will to compromise the kernel's commit log.
also, i find it absolutely typical of the place that HN has become that my original post asking a reasonable, informed question with reference is voted down. you're a bunch of mindless fucking morons.
That said, it was not an unreasonable question to ask, and so I've up-voted you.
What doesn't help is calling everyone "mindless fucking morons" after only one or two down-votes. It's not constructive, and won't get you anywhere. Also: chill. Just because one or two individuals didn't like the tone of your original comment, doesn't mean everyone on HN is out to get you. Well, at least not before you insulted them.
> is their any real analysis
driving some of the downvotes (I did not vote myself).
http://www.schneier.com/blog/archives/2005/02/sha1_broken.ht...