Merge branch 'master' of ssh://git-annex.branchable.com

5 files changed, 68 insertions, 0 deletions

diff --git a/doc/bugs/encryption_key_is_surprising.mdwn b/doc/bugs/encryption_key_is_surprising.mdwn
new file mode 100644
index 000000000..80dea87e5
--- /dev/null
+++ b/doc/bugs/encryption_key_is_surprising.mdwn
@@ -0,0 +1,20 @@
+Crypto.hs seems to imply that the cipher key it's acting upon is 512 bytes long. Because of a probable programming mistake the key that's actually used is a bit surprising. The random key is generated by this snippet in Utility/Gpg.hs:
+
+    {- Creates a block of high-quality random data suitable to use as a cipher.
+     - It is armored, to avoid newlines, since gpg only reads ciphers up to the
+     - first newline. -}
+    genRandom :: Int -> IO String
+    genRandom size = readStrict
+        [ Params "--gen-random --armor"
+        , Param $ show randomquality
+        , Param $ show size
+        ]
+      where
+        -- 1 is /dev/urandom; 2 is /dev/random
+        randomquality = 1 :: Int
+
+This lets GPG generate the randomness and by passing armor, it avoids newlines. However, this base64 encoding is never undone on the way to Crypto.hs. Hence what cipherPassphrase and cipherHmac do is dropping or skipping the first 256 bytes of the base64 value. Base64, with its 6 bit per byte encoding, causes the Hmac function to operate on 192 bytes instead of 256 bytes. The key used by GPG will be larger. Some assertions that the resulting functions really operate on strings of the right length would've been helpful. Also GPG and HMAC get tested, the encryption/decryption part are not tested AFAICS.
+
+The encryption wiki page could have had more information. Enough code (sadly in Python, not reusing the Haskell code) to operate on the resulting files can be found in [this Gist](https://gist.github.com/pkern/5078559).
+
+-- Philipp Kern
diff --git a/doc/bugs/encryption_key_is_surprising/comment_1_5b172830ac31d51a1687bc8b1db489f9._comment b/doc/bugs/encryption_key_is_surprising/comment_1_5b172830ac31d51a1687bc8b1db489f9._comment
new file mode 100644
index 000000000..04854b3a4
--- /dev/null
+++ b/doc/bugs/encryption_key_is_surprising/comment_1_5b172830ac31d51a1687bc8b1db489f9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-04T00:04:53Z"
+ content="""
+My first concern is if this means it's insecure. Luckily it seems not; HMAC SHA1 needs only 64 bytes of entropy, which are more than provided in the 256 bytes of base64 provided. As long as both gpg and the HMAC code use the full provided key (and not just the first 64 bytes of it, say), we're ok. And as far as I can tell, both do fully consume and use the key.
+
+So, I don't feel the need to change the code, aside from some minor improvements to variable names.
+"""]]
diff --git a/doc/bugs/git-annex_dropunused_has_no_effect/comment_1_66b581eb7111a9e98c6406ec75b899cf._comment b/doc/bugs/git-annex_dropunused_has_no_effect/comment_1_66b581eb7111a9e98c6406ec75b899cf._comment
new file mode 100644
index 000000000..0624eb27c
--- /dev/null
+++ b/doc/bugs/git-annex_dropunused_has_no_effect/comment_1_66b581eb7111a9e98c6406ec75b899cf._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~arand"
+ nickname="arand"
+ subject="comment 1"
+ date="2013-03-03T22:34:27Z"
+ content="""
+Vhat kind of annex is this (direct/indirect, on what filesystem, etc.)?
+
+Also what version of git-annex?
+
+I know that direct mode didn't support dropunused, at least before, and on earlier versions of annex switching back to indirect after deleting things in direct didn't work either for dropunused, if I recall correctly.
+"""]]
diff --git a/doc/bugs/git-annex_dropunused_has_no_effect/comment_2_11c46cd2087511c3d22b7ce7c149b3e9._comment b/doc/bugs/git-annex_dropunused_has_no_effect/comment_2_11c46cd2087511c3d22b7ce7c149b3e9._comment
new file mode 100644
index 000000000..22a8a0c4f
--- /dev/null
+++ b/doc/bugs/git-annex_dropunused_has_no_effect/comment_2_11c46cd2087511c3d22b7ce7c149b3e9._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 2"
+ date="2013-03-03T22:43:41Z"
+ content="""
+It's a ZFS filesystem, using indirect mode.  Here are my version numbers:
+
+    Vulcan:~/src/fpco $ git annex version
+    git-annex version: 4.20130227
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+
+"""]]
diff --git a/doc/bugs/git-annex_dropunused_has_no_effect/comment_3_b1c3d8c6ec4b20727aaa9c4b746531b0._comment b/doc/bugs/git-annex_dropunused_has_no_effect/comment_3_b1c3d8c6ec4b20727aaa9c4b746531b0._comment
new file mode 100644
index 000000000..b1c2ce085
--- /dev/null
+++ b/doc/bugs/git-annex_dropunused_has_no_effect/comment_3_b1c3d8c6ec4b20727aaa9c4b746531b0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-03-03T23:56:17Z"
+ content="""
+dropunused will do nothing if the number provided to drop is not listed in `.git/annex/unused`
+
+The file should be generated when you run `git annex unused`
+"""]]