updates
This commit is contained in:
parent
969da82b5c
commit
4cad401629
2 changed files with 10 additions and 6 deletions
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue