2017-02-23 20:43:15 +00:00
|
|
|
[The first SHA1 collision](https://shattered.io/) was announced today,
|
|
|
|
|
produced by an identical-prefix collision attack.
|
|
|
|
|
|
|
|
|
|
After looking into it all day, it does not appear to impact git's security
|
2017-02-23 21:11:46 +00:00
|
|
|
immediately, except for targeted attacks against specific projects by
|
|
|
|
|
very wealthy attackers. But we're well past the time when it seemed ok that git
|
2017-02-23 20:43:15 +00:00
|
|
|
uses SHA1. If this gets improved into a chosen-prefix collision
|
|
|
|
|
attack, git will start to be rather insecure.
|
|
|
|
|
|
2017-02-23 23:06:06 +00:00
|
|
|
Projects that store binary files in git, that might be worth $100k for an
|
|
|
|
|
attacker to backdoor **should** be concerned by the SHA1 collisions.
|
|
|
|
|
A good example of such a project is
|
|
|
|
|
<git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git>.
|
2017-02-24 04:28:15 +00:00
|
|
|
|
2017-02-23 23:06:06 +00:00
|
|
|
Using git-annex (with a suitable backend like SHA256) and signed commits
|
2017-02-24 04:28:15 +00:00
|
|
|
together is a good way to secure such repositories.
|
2017-02-23 23:06:06 +00:00
|
|
|
|
2017-02-24 04:28:15 +00:00
|
|
|
Update 12:25 am: However, there are some ways to embed SHA1-colliding data
|
|
|
|
|
in the names of git-annex keys. That makes git-annex with signed
|
|
|
|
|
commits be no more secure than git with signed commits. I am working
|
|
|
|
|
to fix git-annex to not use keys that have such problems.
|
