In my Using PDM posts, I mentioned that I was rebuilding the backup tools for my blog. Using such tools requires that I keep a couple of my passwords, the ones I use for databases, in plain text, which is clearly not ideal, especially not if I want to use GIT to manage them.

Enter git secret. Git Secret stores anything you've marked as "secret" in a hidden directory under your project, encrypted with your Gnu Privacy Guard public key, and which in turn can only be decrypted with your private key. By combining a folder for your secrets in your project with .gitignore and Git Secret, you have a much better chance of storing secrets with your project that are safe from prying eyes.

The first thing to do is install it. I just downloaded the Debian package, but there are several methods.

Important: You must have a global .gitconfig file with your [user] block filled out, both name and email.

Once it's installed, cd to any project that has a .git folder and has secrets you want to store. With those, you can initialize the secrets folder:

$ git secret init
$ git secret tell -m

The second command tells Git Secret to use the email address on record in your .gitconfig file, and to look in your gpg key collection for the key associated with that email address.

I kept my configuration secrets in a folder named config, so hiding them from git and adding them to my secrets was as simple as:

$ echo 'config/*' >> .gitignore
$ git secret add config/blog-backups.yaml
$ git secret hide

The file I wanted to keep secret is now complimented by a new file, config/blog-backups.yaml.secret. If you're ignoring the folder, you must explicitly add this file to the files you want git to track:

$ git add config/blog-backups.yaml.secret

You can now safely commit your secrets to your repository.

To get them back, you can check out the repo and restore the secreted files:

$ git secret reveal

This will decrypt all the secreted files in your repo, provided that you have the same email address and GPG key as before.

Git Secret still seem fraught with the kind of risks taken when you fail to completely automate secrets management. You could forget to ignore an important configuration file, or you could lose the secret keys needed to get them back. But it's a big improvement over not storing your secrets in a repo at all, leaving them to get out-of-sync with the project.