On git never store secrets

I see a bad use in the git world.

Posted on
2 minutes
425 words
Other languages: Français

Even if some projects encourage this behaviour. Be clear on that point: storing secrets on git always is a bad idea.

Remote git flow breaking

If you store a secret on git, you are supposed to store it encrypted (obviously).

To do a versioning you simply use a commit. As the encryption algorithm is non-deterministic (as it should be, it is not a hash), you end up with a blob of encrypted data which is entirely different from the previous commit. It makes impossible to do a compare and the full file is uploaded everytime.

Now, more funny. You want to do a git merge because 2 branches received separate updates on their secrets. As you have to compare 2 entirely different encrypted files, what advantages can offer any merge strategy from git. You definitely will end up screwing up your file and loose the contained secrets.

Local git flow breaking

You could say “this way I manage my secrets with the same flow as my code”. And I shall answer “Really ? Are you really sure on that ?”

So let’s have a look at your local flow, as I already explained that your remote flow is definitely dead.

  • You pull the repo
  • You integrate it into your VSCode or your terminal or any other IDE
  • You change something on the code
  • You commit
  • You pull and push

Okay, now for the secrets.

  • You pull the repo
  • You integrate it into your VSCode or your terminal or any other IDE
  • So far so good
  • Hopefully you installed the tool to decrypt your secrets file
  • You decrypt it (hoping the tool is integrated in your IDE)
  • You change something on it
  • You encrypt it with the same tool or another
  • You double-triple check that you did not leave the unencrypted file somewhere on your workspace
  • you commit with a drop on your forehead and a pain on your stomach
  • you pull
  • you try to figure out how to solve the conflict between your 2 blobs of encrypted file because a new commit on remote already altered the file
  • you commit again hoping you did not screw everything up
  • you push
  • you see afterwards that you commit the unencrypted file as well and secrets are now freely available on the remote
  • you desperately try to reset screwing up the git flow for the whole team
  • you cry

I’m not sure it is the same git flow.

As conclusion, store your secrets in storages made for that. For instance, Hashicorp Vault on your infrastructure and keepassXC locally.