[deleted]
They really don't. You can read them from environment variables (which would be set by your platform eg. heroku) or you could set up a vagrant instance with the necessary services to develop locally.
Why Deleting Sensitive Information from GitHub Doesn't Save You
21–30 of 91 posts
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#22Millions of emails for developers and no one harvesting this info thought it wise to obfuscate it in some way?
Emails are part of commits, which are hashed as part of normal git operations. There's no way to make repositories public and not make emails public.
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#23Earlier quoted context omitted.
I've always wondered the proper way to deal with this, and this makes total sense. How would you typically set such an environment variable? In bash init?
It depends on language. In node, you can set environment variables in the code with process.env and Python with os.environ and then use those to specify the values on the command line. In fact, even services like Heroku will let you edit these from their web-based client.
That's really more of an implementation detail though. You'll want a file to specify these environment variables, so you can actually have services start on boot, so that means you need a config file (whether it's used for setting the environ, or read directly by the application is the implementation detail). What's really needed is to correctly separate and secure important configuration options outside of source, and designing for that from the beginning. Using environment variables in a way forces this, which is good, but it doesn't help if there's just a startup script that specifies those variables and it gets accidentally committed to the repo.
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#24There's a fairly straight forward pattern for keeping sensitive credentials out of github. It comes straight from http://12factor.net/config store configuration data in the environment.
What I do for most projects is keep the tree containing the working directory in a directory that has some other items that don't belong on github (like the project brief, my emacs bookmarks file, random notes related to the project etc. ) and in that directory there is a .credentials file containing a set of export statements somewhat like:
export AWS_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXX
export AWS_SECRET_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
export AWS_USER_ID=############
Then at startup the app goes looking for it's config in the environment. This does create issues for some environments ( solving this for docker is trivial ) but you can usually pass environment variables to whatever is executing your code reasonably securely. Now it's not perfect, and environments can sometimes be revealed externally if an attacker is determined and clever and focused on your app for some reason.
But it does give you a hygienic procedure that keeps your credentials that are equivalent to an open draw on your bank account out of public repositories.
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#25Always use environment variables. They are probably the best way to safeguard your API keys.
I've always wondered the proper way to deal with this, and this makes total sense. How would you typically set such an environment variable? In bash init?
Environment variables can work well for development but I wouldn't put them in .bashrc or .bash_profile; if you are like me, you like to store your dot files somewhere public. I typically leave them in an encrypted file on dev systems, but this only solves the accidental over the shoulder problem. Production systems require another level of security altogether.
Typically, I've seen services run in restricted user accounts with limited system access, reading passwords out of an encrypted file. This file is stored in some obscure location on the box to which that user account is the only one with read permissions to.
Keep in mind, every system has weaknesses and I am still interested in listening to others' approaches.
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#26[deleted]
> "API keys [...] need to be in your committed code"
No they don't.
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#27I think this problem is widespread enough and there are enough idiots out there(me included),that there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted.
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#28There's a fairly straight forward pattern for keeping sensitive credentials out of github. It comes straight from http://12factor.net/config store configuration data in the environment. What I do for most projects is keep the tree containing the working directory in a directory that has some other items that don't belong on github (like the project brief, my emacs bookmarks file, random notes related to the project e…
I use the `dotenv`[1] package with Node.js and it does exactly the same thing: environment variable definitions that you can store elsewhere in a dead-simple format.
To be fair, I think they just copied the `foreman` tool from Heroku. However, it works great. Most projects don't need anything more than a flat hierarchy of secret keys and values.
Writing your own parser for a `.env` file is a piece of cake, even in shell language.
Adding `etcd` is better, but it's too much work for a small project.
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#29I think this problem is widespread enough and there are enough idiots out there(me included),that there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted.
> there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted.
Sure, just enumerate any and all possible types of sensitive data, the format they may be in, regex / matching functions to account for them (supported across 20+ programming languages) and I'm sure Github will have that done asap.
Alternatively, don't commit passwords/API-keys/sensitive-info to your repo.
Re: Why Deleting Sensitive Information from GitHub Doesn't Save You
#30I think this problem is widespread enough and there are enough idiots out there(me included),that there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted.
> there should be a feature request for Github to provide a prompt in case Github detects sensitive information in the code hosted. Sure, just enumerate any and all possible types of sensitive data, the format they may be in, regex / matching functions to account for them (supported across 20+ programming languages) and I'm sure Github will have that done asap. Alternatively, don't commit passwords/API-keys/sensitive…
> Alternatively, don't commit passwords/API-keys/sensitive-info to your repo.
This is, of course, the right answer.
However, it's frustrating that several frameworks make this very easy to get wrong. Anything that has an application.yml, database.yml, or similar configuration file that normally lives within the same directory as the source code, and which is intended to contain credentials, means that lots of people will make that mistake.
It's one of the fundamental errors that you see so often in web frameworks like Rails, this whole idea of mixing application code and configuration files into one big tree. I don't know how this practice caught on, but it has, and it so frequently causes mistakes, both big ones like accidentally publishing credentials, and simply frustrating ones like confusing the difference between application code and configuration in ways that make it more difficult to have multiple local configurations and updating the application code independently.