I use private repositories on GitHub, but I still don’t feel quite comfortable pushing sensitive data like
passwords, keys, and account information. Typically that information ends up just sitting on my local machine or in my
head ready for me to pull up as needed. It would be much better if that information was a bit more fault tolerant and,
even better, if I could follow similar workflows as the rest of my application code.
After some research I discovered gist 873637 which discusses using git’s clean and smudge filters to pass
files through openssl for decryption and encryption. The result is git’s indexes only containing encrypted file
contents in base64. Soon I found shadowhand/git-encrypt.
First, I did a one-time install of shadowhand/git-encrypt on my machine:
Next, I created a new repo and use gitcrypt init to set things up:
Now I just have to be sure to securely keep the salt and pass elsewhere for the next time I setup this repo. Other than
that, it’s ready for me to use like any other git repository.
A Practical Bit
Since I won’t frequently be setting up this repository, it’d probably be best if I could keep a reminder about what I’ll
need to do. So I update .gitattributes to exclude itself and README from encryption:
And include the necessary commands and reference in README:
So, my first commit looks like:
Under the Hood
Originally I was a bit curious and wanted to verify that it’s doing what I thought. So I created a simple test file:
After committing I can look at the raw index data to see what’s actually being stored:
As expected, README is readable, but top-secret.txt is not. I can manually verify my secret data is still there by
decoding it with my key:
With gitcrypt I can work with a repository and enjoy extra security on top of the redundancy and version control that
git provides. The only difference from my regular repos is I can’t really view my files from github.com (with the
convenient exception of README).