updates

2 files changed, 9 insertions, 5 deletions

diff --git a/doc/devblog/day_449__SHA1_break_day.mdwn b/doc/devblog/day_449__SHA1_break_day.mdwn
index a5287ff7c..df7085602 100644
--- a/doc/devblog/day_449__SHA1_break_day.mdwn
+++ b/doc/devblog/day_449__SHA1_break_day.mdwn
@@ -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.
+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.
+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.
diff --git a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn
index 7acbfde13..dc3dccdc5 100644
--- a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn
+++ b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn
@@ -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.