This commit is contained in:
Joey Hess 2017-02-24 00:28:15 -04:00
parent 969da82b5c
commit 4cad401629
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
2 changed files with 10 additions and 6 deletions

View file

@ -11,9 +11,11 @@ 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>.
Using git-annex (with a suitable backend like SHA256) and signed commits
together is a good way to secure such repositories.
git-annex's SHA1 backend is already documented as only being
"for those who want a checksum but are not concerned about
security", so no changes needed here.
Using git-annex (with a suitable backend like SHA256) and signed commits
together is a good way to secure such repositories.
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.

View file

@ -30,5 +30,7 @@ A few other potential problems:
* It might be possible to embed colliding data in a specially constructed
key name with an extra field in it, eg "SHA256-cXXXXXXXXXXXXXXX-...".
Need to review the code and see if such extra fields are allowed.
Update: All fields are numeric, but could contain arbitrary data
after the number. (fixed now)
after the number. This has been fixed; git-annex refuses to parse
such fields, so it won't work with files that try to exploit this.