5 ms·

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

by lambda 13y ago

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.

xur17 13y ago
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.
- grannyg00se 13y ago
  Usally in environment variables rather than a config file. for example https://devcenter.heroku.com/articles/config-vars https://devcenter.heroku.com/articles/config-vars
  - chaz 13y ago
    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?
    - ketralnis 13y ago
      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.
yeukhon 13y ago
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?
- dwaltrip 13y ago
  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)
  - yeukhon 13y ago
    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.
miles932 13y ago
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-safer-way-to-distribute-AWS-credentials-to-EC2 http://blogs.aws.amazon.com/security/post/Tx1XG3FX6VMU6O5/A-...
- steveklabnik 13y ago
  This would be neat for a pre-commit hook.

by lambda 13y ago

xur17 13y ago

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.

grannyg00se 13y ago
Usally in environment variables rather than a config file. for example https://devcenter.heroku.com/articles/config-vars https://devcenter.heroku.com/articles/config-vars
- chaz 13y ago
  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?
  - ketralnis 13y ago
    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.

yeukhon 13y ago

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?

dwaltrip 13y ago
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)
- yeukhon 13y ago
  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.

miles932 13y ago

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-safer-way-to-distribute-AWS-credentials-to-EC2 http://blogs.aws.amazon.com/security/post/Tx1XG3FX6VMU6O5/A-...

steveklabnik 13y ago
This would be neat for a pre-commit hook.