Hacker News Reader

Comment by lambda | Hacker News Reader

Another good habit to be in is never checking any kind of credentials into source control; even if it's some private personal project, just don't be tempted to check in your credentials to source control, because at some point you may find some portion of that that's useful that you import into a public project, accidentally preserving full history.

Sorry to the OP, hope that Amazon reverses those charges once you tell them what happened.

View on HN

We know we shouldn't be committing password or personal key. But shit happens and it does happen very frequently, even top notched people do.

What we need is not to say "don't it", because no shit we shouldn't be doing that. instead we need defense mechanism. It would be helpful and interesting if git or hg has a plugin that detects when some credentials is leaking through and warn users "hey you better check this shit out" before doing a real commit.

The other thing is "don't commit key into a private repository". Don't chef and puppet users usually do that? How are people backing up their keys?

For rails, the Figaro gem is really helpful for managing environment variables, which is a good place to store credentials (the config file for Figaro is then added to .gitignore)

But how do you back up this set of environment variables. Yes, in practice I also use ignore file to prevent sensitive things leak into repository and I usually generate password dynamically on the fly or through some script.

Here's a handy GREP to find AccessKey/SecretKey pairs: grep -RP '(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9])' * grep -RP '(?<![A-Za-z0-9/+=])[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=])' *

source: http://blogs.aws.amazon.com/security/post/Tx1XG3FX6VMU6O5/A-...

This would be neat for a pre-commit hook.

What's the best way to handle api keys without storing them in a repository? A separate configuration file?

I've saved api keys to a repository, but only ones with no payment information attached and read only access. Mainly because I couldn't think of a better way at the time.

Usally in environment variables rather than a config file.

for example https://devcenter.heroku.com/articles/config-vars

This is very convenient on Heroku, but on my own servers, I have to use a post-deploy hook to copy a file that has all of my API keys to the server. That works great, except I now have a separate file to manage outside of source control, it's not under its own source control, and it's difficult to share amongst my team.

Anyone have any suggestions?

I've had some luck with having a separate repo. I'll have a "public" (even if it's not public) with all of the usual source code, and a "private" repo, with passwords, fabric files, run scripts, etc.

Works well on teams, where the subset of developers that don't need to do actual deployments don't need the private repo anyway.

Reply on news.ycombinator.com