comment

1 files changed, 29 insertions, 0 deletions

diff --git a/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_2_52a1800537f1244ad6cf417c5f25ebe0._comment b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_2_52a1800537f1244ad6cf417c5f25ebe0._comment
new file mode 100644
index 000000000..07fa48544
--- /dev/null
+++ b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_2_52a1800537f1244ad6cf417c5f25ebe0._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-06-06T15:38:24Z"
+ content="""
+Your remote has chunking enabled, so git-annex first tries generating a
+HMAC for a chunked key. When decrypting the content fails for some reason,
+it falls back to trying the HMAC for an unchunked key. This is done because
+chunking can be enabled after some content has been uploaded to a remote,
+so it always tries the unchunked location just in case.
+
+It looks like gpg is successfully decrypting the hybrid encryption key
+that's embedded in your git repository. That is the first, successful
+call tp gpg in your log.
+
+The "bad key" error then comes when gpg is asked to use the hybrid
+encryption key to decrypt the content. This seems to indicate it's not
+using the same hybrid encryption key that was used to encrypt it.
+
+The fact that it was able to generate the right HMAC key to download the
+content though, indicates that it did get the right hybrid encryption key
+(since half of that key is used to generate the HMAC).
+
+So hmm, I don't understand what is going on.
+
+Are you able to retrieve the same file successfully when the rclone.conf
+is configured to use the Amazon Cloud Drive? (Assuming that the content of
+the file is still present over there.)
+"""]]