I’ve worked on many projects where sensitive information is stored in a git repository. This includes SSH keys, SSL private keys, API keys, passwords, and client secrets. This practice is easily labelled Not Good.
You might be thinking, “Why should I worry? Our GitHub repository is private, and only our team can access the secrets!”
A private repository on GitHub or GitLab may seem like a safe storage area, since access is limited to a small set of specified parties. However, many teams don’t think twice about allowing third party services to access these private repositories. Once you’ve enabled access, these services now have permission to read your secrets. Even if the service isn’t malicious, thereis the chance that there is a vulnerability in the services that could be exploited to expose the files. Or perhaps there is a configuration flaw in your build server which grants everyone on the internet read access to your projects.
Storing secrets in our repositories is alluring because of its convenience, and I found myself recently tempted by this practice. I spent time investigating solutions to the secret storage problem and came across three easily incorporated projects:
I currently use BlackBox, as it was the first solution I discovered. However, I will be migrating to git-crypt because it offers a superior workflow with little user involvement.
BlackBox
BlackBox was created by Stack Overflow, initially to support secret storage for use by Puppet. Unlike the other two solutions I’ll discuss, BlackBox is the only one that supports a multiple version control systems.
Protected files are encrypted with the public keys of all trusted users. If access needs to be revoked, delete the public key and re-encrypt the files.
BlackBox can encrypt and decrypt individual files. If you are using Puppet, you can also encrypt/decrypt individual strings.
I recommend BlackBox for developers who do not use git or work with a variety of version control systems.
git-secret
git-secret is a bash script based on gpg. git-secret allows you to encrypt individual files for storage inside of a git repository. git-secret provides commands to encrypt secret files before pushing to the server and to decrypt them for local use.
Protected files are encrypted with the public keys of all trusted users. If access needs to be revoked, delete the public key and re-encrypt the files. They will no longer be able to decrypt the secrets.
You can install git-secret with apt, yum, and brew.
git-crypt
git-crypt is a program that operates similarly to git-secret. Files that should be encrypted by git-crypt are tracked in the .gitattributes file, similarly to git-lfs.
Access permissions can be managed by adding individual gpg keys, similarly to git-secret. git-crypt also allows you to export a symmetric key which can be provided to collaborators.
Aside from an initial unlock command that needs to be used after cloning the repository, git-crypt encryption and decryption operations happen transparently. I find this workflow to be superior to git-secret and BlackBox.
You can install git-crypt through brew if you are on OSX. Otherwise you can manually compile git-crypt for your system.
Thanks for sharing Phillip.
Are you still using git-crypt?
Cheers
Benn
Yes, I use it for my personal configuration files and recommend it when my clients are sharing secrets through a git repository.
How do you remove a user in git-crypt?
Thanks for the overview. Quick thing, the link to git-crypt is broken, looks like there is some weird html character escaping going on there.
Thanks for pointing that out, I’ve fixed the links.
One note that all these encryptions are not for encrypting entire git repository and commits, they’re only good for encrypting some specific secret files that you might have in your repository!
I just want to point out that git-crypt is installable with apt, in all current Debian distributions and derivates thereof