mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2014-08-12 15:39:27 -04:00
commit c963563602
2 changed files with 26 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

14
doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment Normal file
View file

@ -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.
"""]]

12
doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment Normal file
View file

@ -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.
"""]]