From 5eeacd84e571451f033e86ad3b5ef6db1b811cfa Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Tue, 12 Aug 2014 18:58:49 +0000 Subject: Added a comment --- .../comment_3_b2774d265de303143523607053811d23._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment diff --git a/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment b/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment new file mode 100644 index 000000000..b2bcd87eb --- /dev/null +++ b/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 3" + date="2014-08-12T18:58:49Z" + content=""" +I think that to support this, the annex.largefiles preferred content expression would need to be supplimented with checks not available in the normal preferred content language. + +In general, it's important that preferred content expressions be able to be evaluated without having the file content locally available, and it needs to be possible for a repository to evaluate the preferred content of a sibling repository and know if its sibling wants a file. These things would be defeated by any mime-based expressions. So such expressions should only be available in annex.largefiles and not in other preferred content expressions. + +Calling out to `file` or some other external program could work. Although speed can be important. If the assistant is seeing a file frequently change, it's not ideal for it to be repeatedly running `file` on it. There does not seem to be a pure haskell MIME type checking library available at present. +"""]] -- cgit v1.2.3 From db51cac7fd96fb04ef132182ccc613dcd8cad47f Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Tue, 12 Aug 2014 19:37:56 +0000 Subject: Added a comment --- .../comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment diff --git a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment b/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment new file mode 100644 index 000000000..57d5ee0cf --- /dev/null +++ b/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-12T19:37:56Z" + content=""" +This is not gpg trying to decrypt some file from the S3 remote. It is trying to decrypt the creds that embedcreds=yes caused to be stored in the git repo. + +I was able to reproduce this using your command line, with the S3 env vars set while running initremote, and then unset for the copy, which causes git-annex to try to get the creds from the git repo, and decrypt them. + +However, since encryption=shared, the encryption key is stored in the git repo, so there is no point at all in encrypting the creds, also stored in the git repo with that key. So `initremote` doesn't. The creds are simply stored base-64 encoded. + +I have fixed this. I will now move this thread to bugs so I can close it. +"""]] -- cgit v1.2.3