How to version control config files pragmatically?

Question

Suppose we have a config file with sensitive passwords. I'd like to version control the whole project, including the config file as well, but I don't want to share my passwords.
That could be good, if this config file:

password=secret
foo=bar

becomes

password=*
foo=bar

and the other users of the vcs could also set up the password on they own. To ignoring the file isn't a good approach, the developers should be aware, if the config file changes.

Example:

Local version: password=own_secret foo=bar

config file in vcs:

password=*
foo=bar

Then suddenly, the config file changes:

password=*
foo=bar
baz=foo

And the local version would become for each developer:

password=own_secret
foo=bar
baz=foo

This is my solution. How could I achieve this behaviour? How do you store your config files? Is there a way to do that, or should I hack something?

Answer 1

In my projects I use a directory that holds these kinds of files but it's not uploaded to server, so my db config file is in that directory and it is configured for server where the project is placed. If someone changes config file he will change server config file and anyone updating revision will see changes in that file and will need to manually change his local config.

I don't see a way of doing it rather than that. If you find a different approach please share.

Answer 2

Have a separate file with ONLY the secrets in, that isn't under version control?

Or ideally, do away with passwords entirely use openssh, or similar, and do public/private key authentication for each user.

Answer 3

I'm used to make a txt file of it with the structure of the configfile. And after that I'll make a copy and change the extension and let my version control system ignore this file(s).

So when you make changes in the config file, just update the txt version of it. That's the only option I can think of which is logic as well (in my eyes)

Answer 4

Not sure how your config is implemented, but having hierarchical overides is how I would handle this.

You have a main config that contains common config plus dummy username/password (or leave these out altogether). Each developer then creates a local override.config (or whatever) with their specific username/password. The main config goes under source control, the developer (or machine) local overrides do not.

I've done this in .NET but not PHP so I don't know how easy this would be I'm afraid.

Answer 5

What about a pre-commit hook to blank out sensitive fields? This assumes you're comfortable sending the file over the network in the first place, of course.

Update for the other end of the problem:
To handle updates, you'd either want to force a manual merge of the sensitive files, or modify the local build process to overwrite the sensitive lines with contents from a local/private/ignored file.

Answer 6

I had something similar to this although I don't know if it would work for you. I had a directory that contained files that contained passwords. This directory was not version controlled. The files were named after the applications which used them and in the config files, I 'sourced' the appropriate password file at the point it was needed. This would demand that your config parser can handle sourcing.

Answer 7

Create a local overrides file that contains the user specific info as PHP variables.

For instance create a file called local_overrides.php which contains the following:

$local_password = 'qUzaEAFK13uK2KHy';

Then in the file that includes your DB password do something like this

$overrides = 'local_overrides.php';

if (file_exists($overrides)) {
   #include_once($overrides);
   $db_password = $local_password;
} else {
   // perform appropriate action: set default? echo error message? log error?    
   $db_password = 'l1m1t3d!'
}

The local overrides file would never has to be seen by source control.

Answer 8

Instead of version-controlling the actual configuration file, you could put a template or defaults file in version control, and a script that would ask for DB information and credential to generate the real config file, which would be excluded from (i.e. ignored by) version control. On checkout, developers could run this script to get a working environment. This script could also be invoked as part of any installation process that your application uses.

Also see my answer to a similar question.