Is there an encrypted version control system?

Question

I am looking for an encrypted version control system . Basically I would like to

• Have all files encrypted locally before sending to the ser

Answer 1

Variant A

Use a distributed VCS and transport changes direct between different clients over encrypted links. In this scenario is no attackable central server.

For example with mercurial you can use the internal web server, and connect the clients via VPN. Or you can bundle the change sets and distribute them with encrypted mails.

Variant B

You can export an encrypted hard drive partition over the network and mount it on the client side, and run the VCS on the client side. But this approach has lot's of problems, like:

• possible data loss when two different clients try to access the VCS at the same time
• the link itself must be secured against fraudulent write access (when the partition is shared via NFS it is very likely to end with a configuration where anyone can write to the shared partition, so even when there is no way for others to read the content, there is easily a hole to destroy the content)

There might be also other problems with variant B, so forget variant B.

Variant C

Like @Commodore Jaeger wrote, use a VCS on top of an encryption-aware network file system like AFS.

Answer 2

Similar to some comments above, a useful workaround may be to encrypt&zip the whole repository locally and synchronize it with the remote box. E.g. when using git, the whole repository is stored in directory '.git' within the project dir.

• zip/encrypt the whole project dir
• upload it to a server (unsure if handling .git alone is sufficient)
• before you continue working on the project download this archive
• decrypt/unpack and sync with git (locally)

This can be done with a simple shell line script more comfortable.

pro: You can use whatever encryption is appropriate as well as every VCS which supports local repositories.

cons: lacks obviously some VCS features when several people want to upload their code base (the merge situation) - although, perhaps, this could be fixed by avoiding overwrite remotely and merging locally (which introduces locking, this is where the nightmare starts)

Nevertheless, this solution is a hack, not a proper solution.

Answer 3

SVN have built-in support for transferring data securely. If you use svnserve, then you can access it securely using ssh. Alternatively you can access it through the apache server using https. This is detailed in the svn documentation.

Answer 4

Why not set up your repo (subversion, mercurial, whatever) on an encrypted filesystem, and use ssh only to connect?

Answer 5

Have you thought of using Duplicity? It's like rdiff-backup (delta backups) but encrypted? Not really version control - but maybe you want all the cool diff stuff but don't want to work with anyone else. Or, just push/pull from a local Truecrypt archive and rsync it to a remote location. rsync.net has a nice description of both - http://www.rsync.net/resources/howto/duplicity.html http://www.rsync.net/products/encrypted.html - apparently Truecrypt containers still rsync well.

Answer 6

You should encrypt the data pipe (ssl/ssh) instead, and secure the access to the server. Encrypting the data would force SVN to essentially treat everything as a binary file. It can't do any diff, so it can't store deltas. This defeats the purpose of a delta-based approach.
Your repository would get huge, very quickly. If you upload a file that's 100kb and then change 1 byte and checkin again, do that 8 more times (10 revs total), the repository would be storing 10 * 100kb, instead of 100kb + 9 little deltas (let's call it 101kb).

Update: @TheRook explains that it is possible to do deltas with encrypted repository. So it may be possible to do this. However, my initial advice stands: it's not worth the hassle, and you're better off with encrypting the ssl/ssh pipe and securing the server. i.e. "best practices".