5 ms·
> Git is described as not being crypto Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto l
by alinajaf 13y ago
> Git is described as not being crypto
Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto like this doesn't strike me as "inventing your own crypto".
> people assume it is resistant to malicious attack
Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.
I think your argument stems from the fact that SHA1 is deemed insecure and therefore anything associated with it must also be insecure. As I said in the previous thread, git doesn't use SHA1 to make any of the guarantees that cryptography is typically used to make.
It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.
- haberman 13y ago> It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem. I have evidence that people in practice use it to protect against just this sort of thing: https://news.ycombinator.com/item?id=7003900 https://news.ycombinator.com/item?id=7003900
- Perseids 13y ago> Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem. Write access to your filesystem is a threat git is supposed to be secure against (more precisely: the filesystem of your git server) as Haberman has pointed out. Another incident this was relevant is the kernel.org hack: http://www.linuxfoundation.org/news-media/blogs/browse/2011/08/cracking-kernelorg http://www.linuxfoundation.org/news-media/blogs/browse/2011/... Furthermore, the signed tags are completely worthless if you assume second preimage resistance of sha1 to be broken. Imagine I sit between kernel.org and your computer. When you download the next Linus blessed Linux release I manipulate some of the files to contain some backdoor while still having the same sha1. As you will certainly not check every file manually for bogus content you happily compile and run the manipulated kernel and I have access to your PC via my planted backdoor.