git encrypt/decrypt remote repository files while push/pull

Question

Is it possible to automatically encrypt files via 'git push' before transferring to a remote repository? And automatically decode them while 'git pull'.

I.e, if I have some remote server with shared access with git repository there, and I don't want our project to be stolen without a permission... Maybe there is some special git-hooks before push and after pull?

Answer 1

How to secure public and private remote assets using git-crypt.

• Transparent to all git clients and services (eg. GitHub, BitBucket, etc).
• Linux, OSX and Windows support.
• Asset level encryption (see VonC's answer).
• AES-256 cipher.
  
  

Create your 256 bit private key (RETAIN AND PROTECT THIS KEY)

sudo apt install git-crypt 
mkdir key; cd key;
git init; git-crypt init
git-crypt export-key ~/crypt.key

Push a file called .gitattributes to each repo's root directory.
It should contain one asset pattern per file, directory or type you wish to encrypt:

docs/doc.txt  filter=git-crypt diff=git-crypt
js/**         filter=git-crypt diff=git-crypt
*.java        filter=git-crypt diff=git-crypt
src/cpp/*.h   filter=git-crypt diff=git-crypt

Encrypt assets in each repo:

cd repo-root-directory
git-crypt unlock ~/crypt.key
git-crypt status -f
Push (from command line or git client)

Continue your git workflow as usual.

• Run git-crypt unlock ~/crypt.key once on any new clones of these secured repos.
• You may wish to purge old unencrypted commit histories on all branches and tags.
• If you use a git client, it must fully support git filters and diffs.
  
  
  

Answer 2

Yes and no.

You could try to depend on hook but that supposes they are installed at the remote locations, and that is not always reliable.

Another way to achieve almost the same effect would be by using a smudge/clean attribute filter driver, but not for a full repo.

^{(Source: Pro Git book: Customizing Git - Git Attributes)}

That way the smudge script is able decode the files, while the clean script would encode them.
Again, that could work for a few sensitive files, not for a full repo.

Off course, those scripts would not be in the repository itself, and would be managed/communicated by another way.

As Alkaline points out in the comments, that idea does not scale for a repo, as the main git maintainer Junio C. Hamano comments back in 2009:

As the sole raison d'etre of diff.textconv is to allow potentially lossy conversion (e.g. msword-to-text) applied to the preimage and postimage pair of contents (that are supposed to be "clean") before giving a textual diff to human consumption.

The above config may appear to work, but if you really want an encrypted repository, you should be using an encrypting filesystem.
That would give an added benefit that the work tree associated with your repository would also be encrypted.

---

Even though it does not scale to a full repo, the idea was implemented (3 years later in 2013) with git-crypt, as detailed in Dominic Cerisano's answer.
git-crypt uses a content filter driver (implemented in cpp, with commands.cpp setting up your .gitattributes with the relevant smudge and clean filter commands).
As any content filter driver, you can then limit the application of git-crypt to the set of files you want, in the same .gitattributes file:

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt

As mentioned in the README:

git-crypt relies on git filters, which were not designed with encryption in mind.

As such, git-crypt is not the best tool for encrypting most or all of the files in a repository.
Where git-crypt really shines is where most of your repository is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt.

For encrypting an entire repository, consider using a system like git-remote-gcrypt instead.

(see more at spwhitton/ tech/ code/ git-remote-gcrypt, from Sean Whitton)

Answer 3

You can take a look at this project: https://github.com/shadowhand/git-encrypt

UPDATE: This above project is deprecated and recommends using https://github.com/AGWA/git-crypt

Answer 4

There are two ways to do this.

One is to use a project like git-crypt, http://www.agwa.name/projects/git-crypt/ which adds in fiters to pull and push process, or set up the filters manually as described here https://gist.github.com/shadowhand/873637

Another way if you are working in a linux environment, is to use ecryptfs. For this scenario, in base of your project directory you could, for example, create two directories

project/encrypted_src

project/src

Then from the root of the project directory you would mount using the command

sudo mount -t ecryptfs encrypted_src src

entering a pass-phrase and accepting the defaults when prompted. At this point, files placed in src/ will be encrypted into encrypted_src/ on the fly. When you are finished just

sudo umount src

and only the encrypted files remain. Essentially files are committed and pushed from encrypted_src/ and edited in src. As long as everyone uses the same pass-phrase (or mounts with the same key) the repo can be shared among developers. Also you can get fancier. You can encrypt file names as well as just file contents, or encrypt different folders in a repo with different pass-phrases or keys. The last feature is nice if you have configuration files with sensitive access information that individual groups (dev, test, production) will want to maintain privately.

That said, though, be aware that once you start encrypting stuff. You loose a lot of the advantages of source control like being able to see diffs between various commits. If you have a project of any size the ability to review commits will be invaluable. If you expect bugs, at some point or another, the ability to analyse and find their point of introduction by back tracking through commit history will also be invaluable. So secure your server first and then use encryption only where in makes sense to protect sensitive info in source control. Just my 2 cents.

Answer 5

There are Tahoe-LAFS hooks provided by git-annex, which admittedly might be more complicated than you need.