4 ms·
Is SHA-1 being used in a security-critical way in git, though? I tend to agree with the points made towards the end of the article. If someone malicious can ma
by red_admiral 4y ago
Is SHA-1 being used in a security-critical way in git, though? I tend to agree with the points made towards the end of the article.
If someone malicious can make commits to your repo, you have a much worse problem than a possible hash collision.
Most languages these days have a built-in hashtable type, and they use some kind of non-security-critical hash function, albeit usually with a random seed, that's a lot weaker than SHA-1 - often you only need something like 32-64 bits of output in the first place as no-one allocates more than 2^64 buckets as far as I know. From a security perspective that's even worse than MD5!
I'd argue (and so does the article, in part) that the use of SHA-1 in git is closer to the use of a hash in a hashtable than to the use of a cryptographic checksum - using SHA-1 for subresource integrity on the web is an obvious security risk (luckily, it's not allowed there) but I can't see an obvious attack on git's use that doesn't also assume you can do much worse things.
- haileys 4y ago> If someone malicious can make commits to your repo, you have a much worse problem than a possible hash collision. This is exactly how GitHub works though: all repositories in a fork network share a single underlying repository, only the ref namespaces are separated.
- wildfire 4y agoI am skeptical that is actually the case though, there are so many use-cases where you have to think through the consequences too carefully: - what happens when the source repository rewrites all the commits (to remove one); should the forks also be re-written? - what happens when the source repository disappears? _All_ of the problems go away when you actually do a "git clone" of the source repository and have your own objects. More storage, yes, but way fewer corner cases to think through.
- deleted 4y ago[deleted]