See also: https://groups.google.com/forum/#!topic/binary-transparency/f-BI4o8HZW0
interestingly, these settings cause a failure when cloning https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware as noted in https://bugs.debian.org/743227
If anywhere was a place to look for evidence of binary tampering, i’d expect repos of firmware blobs to be a spot to look. so, yikes.
And make sure you have this in ~/.gitconfig:
# for $deity's sake, check that anything we're getting is complete and sane on a regular basis
# https://groups.google.com/forum/#!topic/binary-transparency/f-BI4o8HZW0
[transfer]
fsckobjects = true
[fetch]
fsckobjects = true
[receive]
fsckObjects = true
Re: severity of the trigger: the problem with firmware repository is zero-padding the mode (I really hope this doesn’t give you enough entropy for creating SHA1 collisions), and there are tools that do that by mistake when generating git repositories without using git itself.
So, this is a good reminder that git sometimes defaults to speed over safety, but not a definite sign of an ongoing compromise of linux-firmware repository. (Of course, there might be an ongoing compromise that is not visible to this specific check — I just say the issue reported is not strong evidence in favour of it).
This is a good point, and I wonder, is git still fundamentally vulnerable to sha1 hash collisions? If so, there’s little defense against that and this won’t catch it.
I think git verifies if an object is vulnerable to a collision similar in its structure to the published one, and there is definitely work being done to migrate to another hash function, but I think it is still not complete.
Note that the best undetectable attack would be taking over repository to replace a preexisting (non-attacker-controlled) object with a different one with the same length and hash. This is harder than the published attack, but combinatorially definitely possible.
You could also just push an extra malicious commit with false author identity and no signature, and hope some maintainer would mistakenly pull it and commit on top of it. Much simple, and for blobs it can be quite effective.