Recent comments posted to this site:
I got a good laugh out of it :-)
Storing the key unencrypted would make things easier.. I think at least for my use-cases I don't require another layer of protection on top of the ssh keys that provide access to the encrypted remotes themselves.
The encryption uses a symmetric cipher that is stored in the git repository already. It's just stored encrypted to the various gpg keys that have been configured to use it. It would certianly be possible to store the symmetric cipher unencrypted in the git repo.
I don't see your idea of gpg-options saving any work. It would still require you to do key distribution and run commands in each repo to set it up.
Thinking about this more, I think minimally git-annex could support a
remote.<name>.gpg-options
or
remote.<name>.gpg-keyring
for options to be passed to gpg. I'm not sure how automatically setting it to $ANNEX_ROOT/.gnupg/.. would work.
I need to read the encryption code to fully understand it, but I also wonder if there is not also a way to just bypass gpg entirely and store the remote-encryption keys locally in plain text.
I got the following error message trying to install git-annex:
cabal: cannot configure git-annex-3.20120418. It requires base >=4.5 && <5
For the dependency on base >=4.5 && <5 there are these packages: base-4.5.0.0.
However none of them are available.
base-4.5.0.0 was excluded because of the top level dependency base -any
These are the steps I performed to make it work
- Download Ghc 7.4.
- Run
sudo cabal install git-annex --bindir=$HOME/bin
. - Compilation of the Crypto-4.2.4 dependency failed since it's not updated to work with Ghc 7.4. You need to patch SHA2.hs (steps below).
- Run
sudo cabal install git-annex --bindir=$HOME/bin
a second time.
The steps I did to patch the SHA2.hs file in Crypto-4.2.4:
cabal unpack crypto-4.2.4
cd Crypto-4.2.4
patch -p1 < crypto-4.2.4-ghc-7.4.patch
sudo cabal install
.
PS: I used this patchfile. Then I did the last step a third time.
To get to a specific version of a file, you need to have a tag or a branch that includes that version of the file. Check out the branch and git annex get $file
.
(Of course, even without a tag or branch, old file versions are retained, unless dropped with unused
/dropunused
.
So you could even git checkout $COMMITID
.)
I'm not currently planning to support sharedRepository perms on special remotes. I suppose I could be convinced otherwise, it's perhaps doable for the ones you mention (rsync might be tricky). (bup special remote already supports it of course.)
thanks for the use case!
You handle conflicts in annexed files the same as you would handle them in other binary files checked into git.
For example, you might choose to git rm
or git add
the file to resolve the conflict.
thanks, that's great. will there be a way to have sharedRepository work for shared remotes (rsync, directory) too, or is that better taken care of by acls?
@not thought of shared repos: we're having our family photo archive spread over our laptops, and backed up on our home storage server and on an rsync+encryption off-site server, with everyone naturally having their own accounts on all systems -- just if you need a use case.