EX52: How to handle Secret keys when publishing code?

Python
#1

Hey!

I’ve been using Ex52 as a basis for a project and would like to upload the code to GitHub, so that I can share it and get feedback on it.

Now I have a new secret key assigned to app.secret_key and not the one from the book, however if I want to publish the code should I put something even different there? A place holder for a new key?

My guess is this is only relevant to protect from anyone entering a session that is running with that secret key. So I should most definitely have the published secret key be different than my local one. But is this enough to just put another key there? What’s best practice in this scenario?
Thanks for your help :slight_smile:

best,

Leon

#2

Yes, that is a major problem when you publish code, so there’s a few strategies people use:

Secrets Config Never Checked In

Don’t put the key directly in the app.py file (or wherever you use it). Instead, you create another module called…secrets.py or something. Now in that module, you can put testing keys that aren’t risky in any way, but honestly I would just never check that file in at all. To do that, add it to the .gitignore so you can never check it in:

# .gitignore contents
config/secrets.py

Now, put your keys in that file, something like this:

secret_app_key = 'asdfasdfsdfasdfasfasdf'
aws_key = 'asdfasdfasdfasdfasdf'

And so on, you can even create different secrets for different modes. Maybe you want production and testing keys:

import os

if 'PROD' in os.environ:
    secret_app_key = 'asdfasdfasdfasdfasdfasfasdf'
else:
    secret_app_key = 'TESTING KEY'

Then when you run it in production you have to add PROD to your environ in bash like this:

$ PROD=1 ./bin/app.py

Alright, now your secrets are safely in this other file that never touches your gits. When you deploy you have to put that file on your servers, so you’d keep it somewhere else safe (see the next section on that). Then, in your app.py do this:

import secrets

APP_KEY=secrets.secret_app_key

Now you can check all your code in except the sensitive stuff and you’re good to go. Can’t get your keys if they are never online.

The GPG Method

Problem is, you need to store this information somewhere, so while maybe you should never store it on github, you might want to put it on an AWS, Dropbox, or similar. Well, if you do store it somewhere, you’ll want to encrypt it with GnuPG. First, follow https://help.github.com/articles/generating-a-new-gpg-key/ to setup your GPG key if you haven’t. Then you can do this to encrypt the secrets:

gpg -r youremail@mail.com --encrypt secrets.py

That’ll create a file called secrets.py.gpg that is encrypted so that only you can open it with your private key. You can then safely put this secrets.py.gpg key on some kind of storage to get at it for deployment, and probably check it into github but I’d only do that if you are using a private repo.

WARNING: These instructions are mostly from memory so let me know if you find mistakes.

1 Like