[sourcd]

> As far as I know, git-remote-dropbox is the only safe way to host a Git repository on Dropbox.

I've another hackish method that's good enough for a single developer, plus it's encrypted.

I've got a truecrypt file container that resides in Dropbox. I mount it as read-write when I want to push. On the rest of my machines, its mounted as read-only. Even if the container is 100GB, it takes 10 seconds to sync daily commits - because of block encryption & syncing. This won't work with Google / MS / Amazon drive etc. because they upload the entire container on each incremental change.

[dividuum]

This feels dangerous. While I'm not sure, I don't think changes to a truecrypted filesystem are guaranteed to be atomic. I'm pretty sure there's no guarantee that the filesystem is consistent every time Dropbox starts syncing. You probably end up with a partially correct file system on the ro-side, which might end in kernel panics if you're unlucky. Also it's not two-way as the git-remote-dropbox solution offers.

[sourcd]

Hence the word "hackish". Though as long as TC containers are read-only, Dropbox syncs them all right.

[heavenlyhash]

Uh, this is also dangerous to your security. The truecrypt docs contain very large warnings about this[1]: someone who can see your disk at multiple versions may be able to drastically weaken your security. If you had keys in those truecrypt files, you should rotate them; if you had secrets, consider them compromised.

Truecrypt uses XTS mode, which is Not Great -- it only exists because someone was trying to hammer ciphers into fitting nicely with fixed sized disk sectors, and it makes a number of serious compromises to do so. [2] has a good discussion of this. You do not want to combine XTS with sharing multiple versions of the ciphertext.

tl;dr you've seen the penguin pictures? As [2] cleverly says, you're pretty much doing that to yourself by sharing multiple versions of the file.

There's also significantly more powerful attacks that can be mounted by an adversary that can feed you corrupted blocks which will allow them to permanently compromise your key, or perform other hijinks like manipulating your content without setting off warning bells. Dropbox, or someone that compromises dropbox, is in that position, by nature of the service they're providing. These issues are rooted in the fact that XTS is not an authenticated cipher -- this leads to such an endemic category of subtle problems that it's been nicknamed "The Cryptographic Doom Principle" [3].

So yeah. If your life depends on it... don't store a truecrypt volume in dropbox.

-----

[1] I found a mirror at http://andryou.com/truecrypt/docs/how-to-back-up-securely.ph... -- and I'll quote, in case that too vanishes:

  > IMPORTANT: If you store the backup volume in any location that
  > an adversary can repeatedly access (for example, on a device kept
  > in a bank’s safe deposit box), you should repeat all of the above
  > steps (including the step 1) each time you want to back up the
  > volume

... where "step 1" is "Create a new TrueCrypt volume".

[2] http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

[3] http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...

[sourcd]

This is good information & thanks for the links.