move wishlist item out out of bug list

2 files changed, 0 insertions, 48 deletions

diff --git a/doc/bugs/git_annex_get___60__file__62___should_verify_file_hash.mdwn b/doc/bugs/git_annex_get___60__file__62___should_verify_file_hash.mdwn
deleted file mode 100644
index f680729ac..000000000
--- a/doc/bugs/git_annex_get___60__file__62___should_verify_file_hash.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-### Please describe the problem.
-git annex get fileName-  should perform a hash check on the file content before adding to the local repository
-
-
-### What steps will reproduce the problem?
-Two scenarios:
-1) Malicious user and owner of repository being pulled from can edit his/her local .git/annex/objects directory 
-to alter the file content. For src code, this could be to insert a bug, insert a backdoor, or for example 
-to replace an image file artifact for a website, with a pornographic image.
-The user pulling the file content with "git annex get fileName"  might not be aware of the file contents 
-until they actually examine the file or perform an fsck or commit locally. 
-In the meantime a kiddy porn image could be sitting in their repository or a src code backdoor can get incorporated and deployed etc.
-2) a file could also simply get corrupted during download. An inherent hash check during the 'annex get' would
-point out the problem immediately.
-To reproduce:  create repoNum1, and clone it to create repoNum2. manual edit/replace content in repoNum1/.git/annex/objects/...
-then perform a 'git annex get <fileName>' from repoNum2 on the file that has been manipulated 
-
-
-### What version of git-annex are you using? On what operating system?
-3.2012112ubuntu2 on running linux mint 
-
-
-### Please provide any additional information below.
-
-Aside: Thanks Joey - this is fantastic work you are doing. You have really improved git. The ability to checkout 
-an entire tree - but selectively get only the content actually needed is a real killer feature.
-Kudos and again many many thanks
-M.
-
-
-# End of transcript or log.
-"""]]
diff --git a/doc/bugs/git_annex_get___60__file__62___should_verify_file_hash/comment_1_650e01a04104120ef1db4ff16fedc4f1._comment b/doc/bugs/git_annex_get___60__file__62___should_verify_file_hash/comment_1_650e01a04104120ef1db4ff16fedc4f1._comment
deleted file mode 100644
index 621e01d6f..000000000
--- a/doc/bugs/git_annex_get___60__file__62___should_verify_file_hash/comment_1_650e01a04104120ef1db4ff16fedc4f1._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.87"
- subject="comment 1"
- date="2013-12-15T19:38:48Z"
- content="""
-If you don't trust a remote repository, then you should either
-
-a) Not use that repository at all, because its malicious owner could put any evil file he wants in it with an entirely correct hash.
-
-b) Make it a gcrypt remote so all content stored on it is encrypted. Decrypting it will include validating that you get out what you originally put in.
-
-So these scenarios are not good arguments for validating every file after it's downloaded.
-
-If it were possible to do a rolling checksum as part of the download, rather than needing to pull the entire file back off disk and checksum it, I'd do so. But it's generally not; for example when git-annex is downloading a file using rsync it may resume part way through a previous interrupted download, and rsync is storing the file to disk, not streaming it to git-annex.
-"""]]