CODEWITHSUNDEEP
gitversion-controlversioning
joar
joar

Reputation: 15897

What is best practice for keeping secrets out of a git repository?

Problem

Consider this file tree as my development repository.

 - foo/
   - .git/
     - [...]
   - bar/
     - backupclient.py
   - supersecretstoragecredentials.ini

For development, supersecretstoragecredentials.ini needs to be filled in with valid credentials - while I still have to keep a clean version of it in the repository so that other users can easily set their credentials.

Possible solutions

  1. .gitignore supersecretstoragecredentials.ini and create a supersecretstoragecredentials.ini-example,
    1. instruct the user to copy supersecretstoragecredentials.ini-example to supersecretstoragecredentials.ini.
  2. Add an overriding config file location in backup.py which is ignored by git, e.g. supersecretstoragecredentials_local.ini.

As kan pointed out, these two solutions are similar but not entirely the same, workflow-wise.

are there any other alternatives? Does git possess some kind of functionality to assist with this kind issues?

Upvotes: 14

Views: 4138

Answers (5)

dexter
dexter

Reputation: 13583

Check in the supersecretstoragecredentials.ini file with some placeholder values and then

git update-index --assume-unchanged supersecretstoragecredentials.ini

Git will not track future changes to this file.

You can reset this using

git update-index --no-assume-unchanged supersecretstoragecredentials.ini

Upvotes: 13

Stephen Souness
Stephen Souness

Reputation: 272

Something that I am trialling at the moment is git-secrets.

https://github.com/awslabs/git-secrets

It hooks into the git commit process and checks for patterns that look like credentials that should not be checked in.

You have to ensure that it is installed on each developer's system and configured for each git repository. This can be achieved easily enough if you integrate a check into the build process.

Upvotes: 1

Aristotle Pagaltzis
Aristotle Pagaltzis

Reputation: 117949

In my experience, after having tried all options listed in your question and in the answers so far, your #2 option has proven the simplest and cleanest. It solves the problem reliably, with the least magic, and is easiest to understand. It is boring in the best way.

Upvotes: 1

kan
kan

Reputation: 28951

I use your solution (your two solutions are the same, only file names differ). Do you have any issues with it? What kind of functionality would you expect?

Also, there is a more interesting solution

git update-index --assume-unchanged supersecretstoragecredentials.ini

Hopefully it's what you want. However it would fail if the upstream changes the file and you are pulling the change (not completely sure is it good or bad).

Upvotes: 3

VonC
VonC

Reputation: 1323653

What you are describing in Option 1 is basically covered by the smudge step of a content filter driver.

filter driver

You have the two options presented in the "How to work on a drop-in library?" question.

the smudge script would take your supersecretstoragecredentials.ini-example (versioned), copy it as a supersecretstoragecredentials.ini (not versioned, ignored by Git), and fill its values from another source.

But beside the technical aspect of how you will implement your policy, the main measure is to make sure your secret values aren't store in a Git repo at all, but are comming from another referential.

Upvotes: 5

Related Questions