On Mon, Feb 27, 2017 at 1:02 PM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > > I always though git's use of SHA hashes was to identify commits and > detect random bit flips, not to provide any measure of security. >
As somebody said in Twitter recently (and Linus to some degree in his post), it is, except when it isn't. git supports gpg signatures on tags and commits. The only thing that binds these signatures to the information being signed are sha1 hashes and file sizes, and Google has already demonstrated the ability to manipulate hashes without changing file size. Those hashes apply to blobs and trees, and doing a collision on either lets you modify the contents of the tree. Now, if every commit is being carefully reviewed (via git diff/etc) then the chances of leaking the data needed to make collisions less expensive into the repo is low, as long as you're talking exclusively about text files (which is all we store in the tree). If you go storing pdfs or images/etc in a repo I'm less confident that you could detect attempts to sneak easy-to-collide data into a repo. So, this isn't a reason to panic, but it is a reason for concern. People have been talking about sha-1 collisions for a while. Commit signatures are not the only way to secure the Gentoo repository, but they seem like one of the most convenient to use, assuming we could trust them. I've always seen sha1 brought up as one of the biggest reasons not to. -- Rich
