4

I'm developing an open source project on my own and I'm hosting the code on GitHub.

I wish to have a full version up there but with a fake password or API key having the good one on my local copy without risk of accidentally publishing it.

If I use .gitignore on the config file it won't upload, right? I want it uploaded but without my real password or API key.

Later I might want to add more things to the same config file and upload a new version but again with fake passwords.

How can I do it safely? Thank you.

aalku
  • 2,860
  • 2
  • 23
  • 44
  • 1
    Possible duplicate of [What's the easiest way to deal with project configuration files?](https://stackoverflow.com/questions/6782017/whats-the-easiest-way-to-deal-with-project-configuration-files) – phd Apr 20 '18 at 19:33
  • I'm not sure it's the same scenario. It's not the same sharing a password by accident with a co-worker than making it public on the Internet. Maybe someone give me an advice with that in mind. But I'll study the answers, of course. Thank you. – aalku Apr 20 '18 at 19:41
  • 1
    You might be also interested in looking into setting git hooks, so that whenever you would be comitting a line which contains a key you would get a warning. As in prevemt comitting lines containing'//password' or 'TODO' – pijemcolu Apr 20 '18 at 19:42
  • Related tool: [ThoughtWorks' Talisman](https://github.com/thoughtworks/talisman). – jub0bs Apr 20 '18 at 20:53
  • 1
    Another related tool https://github.com/awslabs/git-secrets – Shivankar Apr 21 '18 at 06:43

1 Answers1

1

Using environment variables

One standard solution to this problem is loading secrets from environment variables. Depending on what language you use on what operating system, this looks something like

Config.DBPASSWORD = ENV('dbpassword')

Then in any of your environments (dev or prod) you set the necessary environment variables accordingly. On Linux this is somewhat easier but also possible on Windows.

Using configs per environment with templates

Another common approach is if you store a config for your dev environment with fake/useless secrets (ie. a useless password for the local database which only runs on localhost and doesn't have any sane data anyway), and you store a production config template (eg. config.production.php). Upon deployment, you write the actual production secrets into the template via your deploy script. Again, you can safely check in all files into version control. Make sure though that the password checked in as the dev one is really useless for anybody having access. For example if you have production data in the local dev database (a very bad practice anyway!), you should not have this password in the repository, even if the database is not accessible from outside of localhost.

You can also combine these methods if you want.

Gabor Lengyel
  • 14,129
  • 4
  • 32
  • 59
  • First option is good for my scenario. It's not a password but a public API key what I want to protect now so being for localhost only is not an option. I am using Java with Spring Boot so I think I can have a fake key and override it on command line at startup. – aalku Apr 20 '18 at 19:46
  • @aalku Well, you can use template configs for dev too, which you rename to the actual config (not checked in) and insert secrets during setting up the dev environment. But yeah, environment variables are probably easier then. :) – Gabor Lengyel Apr 20 '18 at 21:17