From ca671b4e1004bfcdb28c7de15d5936e90b6e7682 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 6 Jun 2017 12:20:51 -0400 Subject: comment --- ...ent_2_52a1800537f1244ad6cf417c5f25ebe0._comment | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_2_52a1800537f1244ad6cf417c5f25ebe0._comment (limited to 'doc') 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.) +"""]] -- cgit v1.2.3