document updated 12 years ago, on Sep 24, 2012
Git and Duplicity
This page describes how to use Duplicity with Git to encrypt your repository whenever it's sent to specific remote servers. This allows you to store confidential information on untrusted third-party servers.
Because Duplicity is based on the rsync algorithm, we use bandwidth efficiently.
ignore the term "backups"
Duplicity is a backup-oriented program. Backups implies multiple copies, especially when Duplicity starts talking about incremental and full backups. However, even though CryptGit uses Duplicity, there is no† duplication of information. CryptGit's job is to create ONE copy of the repo remotely, not multiple copies. (at least, not unless you specifically ask it to)
† Okay, there is a small amount of duplication, but it's <5% of the data, and it's only done when it's really necessary.
a second local copy
CryptGit creates a second copy of your repo locally, under ~/.cache/cryptgit/. This is a "staging area", where things get pushed to before being synced to the encrypted remote. Although the second copy seems like it might be unnecessary, it really is. Without it, you would have no control over which branches get synced to the encrypted remote. More importantly, any history alterations made on other unencrypted repos would get forcibly imported to your current one, which is very undesirable, and violates many Git workflows.
This second local copy can be deleted if you want (to save space), at the expense of increased network bandwidth later. (note: the second local copy MUST be present when staging changes that will be sent to the encrypted remote)
similar projects
CryptGit is similar to github.com/shadowhand/git-encrypt and sourceforge.net/projects/gitcrypt/. However, the Git maintainer says to avoid these because they encrypt all files in the local /.git/ directory too, which makes it impossible for Git to do delta-compression. CryptGit leaves all local files unencrypted, and only encrypts files just before they're sent over the wire.
CryptGit — a stand-alone utility that automates all of this
It will have two main modes of operation:
- --all mode — ALL local branches get synced to the remote side. The upside of this is that you don't need to make a second copy of the repo locally.
- partial mode (default) — Only specific branches/versions that you want get pushed to the remote side. The downside is that this requires making a second copy of the repo on a local disk.
In partial mode, the second copy would probably be stored in ~/.cache/cryptgit/.../.
--all mode is dangerous, and really isn't suitable when you have more than one repository that syncs to the encrypted remote. This is because every cryptgit pull is really like a git push --force on one side and git fetch --force; git reset --hard FETCH_HEAD on the other — if another unencrypted remote made some major alterations to history, then those changes will be made locally too (and without any warning). As such, if you want to use the --all flag, then you also have to specify the --force flag to have any effect.
(temporary) things that don't need to be backed up
THings that aren't present when you do a git clone --bare: