Recent comments posted to this site:

encryption=shared is now supported
Comment by http://joey.kitenet.net/ Sun Apr 29 18:04:13 2012

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.

BTW re your Tweet.. I was so happy to be able to use 'c i a' in Crypto.hs. :)
Comment by http://joey.kitenet.net/ Sun Apr 29 02:41:38 2012

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.

Comment by http://joey.kitenet.net/ Sun Apr 29 02:39:20 2012

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

  1. Download Ghc 7.4.
  2. Run sudo cabal install git-annex --bindir=$HOME/bin.
  3. 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).
  4. 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:

  1. cabal unpack crypto-4.2.4
  2. cd Crypto-4.2.4
  3. patch -p1 < crypto-4.2.4-ghc-7.4.patch
  4. 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.)

Comment by http://joey.kitenet.net/ Tue Apr 24 21:14:15 2012

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!

Comment by http://joey.kitenet.net/ Mon Apr 23 14:35:39 2012

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.

Previous discussion

Comment by http://joey.kitenet.net/ Mon Apr 23 14:29:03 2012

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.

Comment by http://christian.amsuess.com/chrysn Mon Apr 23 14:14:28 2012
Comments on this page are closed.