21–30 of 31 posts
Of course you'll need to include that sensitive data in the script, though the first few characters of AWS credentials should be unique enough.
I thought about setting up something similar for networking. If a packet contains my password in cleartext then pop up a warning allowing/denying (denying would have to force the connect to close, I guess). Might be too much overhead though.
Rather than store passwords or sensitive config data in a file I'll usually try to store them in an environment variable. Heroku has a little guide on this: http://docs.heroku.com/config-vars
I use a similar strategy: http://trevorturk.com/2009/06/25/config-vars-and-heroku/ ...this kind of thing doesn't have to be Heroku-specific, though.
There is a business opportunity here. Managing credentials and secrets is (passwords, private certs, etc) is hard. Making that process turnkey, secure and easy would be useful.
You can use any number of very low-barrier strategies to solve this. One that was mentioned a few times in this thread is to use environment variables. Personally I just put a {whatever}.yml or similar in my project tree somewhere and throw it in .gitignore.
I can't imagine a process that starts with "go to westorecredentials.com and sign up..." being any easier. Willing to be surprised :)
Thank you, kabuks, so much for noticing this. I have changed my S3 key pair and am getting to cleaning up my git commits.
My God ! But thanks so much.
There is a "message" button on each github user page. I just sent this to a few people (including someone who had forked one of my projects and added their S3 keys to a config file): Noticed you have your Amazon S3 keys out in the open on github. You might want to remove those config files from your repository as described in the thread here: http://news.ycombinator.com/item?id=1574211 -Pete
There is a "message" button on each github user page. I just sent this to a few people (including someone who had forked one of my projects and added their S3 keys to a config file): Noticed you have your Amazon S3 keys out in the open on github. You might want to remove those config files from your repository as described in the thread here: http://news.ycombinator.com/item?id=1574211 -Pete
Remove and change at Amazon, as the values could still be floating around in fetches, caches, archives, indexes, etc. for a while.
There is a business opportunity here. Managing credentials and secrets is (passwords, private certs, etc) is hard. Making that process turnkey, secure and easy would be useful.
I'm not sure it's that hard. You can use any number of very low-barrier strategies to solve this. One that was mentioned a few times in this thread is to use environment variables. Personally I just put a {whatever}.yml or similar in my project tree somewhere and throw it in .gitignore. I can't imagine a process that starts with "go to westorecredentials.com and sign up..." being any easier. Willing to be surprised :…
Here's my solution - github 'extends' git somehow, so files can be marked private. Then, unless you have commit rights to that repo, you can't see the file's contents. So a public http checkouts lacks the secret password.
And because it's git, someone you give commit rights to is someone you trust. People you don't trust can just make their own repo.
Earlier quoted context omitted.
I'm not sure it's that hard. You can use any number of very low-barrier strategies to solve this. One that was mentioned a few times in this thread is to use environment variables. Personally I just put a {whatever}.yml or similar in my project tree somewhere and throw it in .gitignore. I can't imagine a process that starts with "go to westorecredentials.com and sign up..." being any easier. Willing to be surprised :…
People are advocating not saving settings to source control. F-that, I want to be able to clone my repo and run the project without scp-ing an additional file around. A file, that by all rights should be part of the project. Here's my solution - github 'extends' git somehow, so files can be marked private. Then, unless you have commit rights to that repo, you can't see the file's contents. So a public http checkouts…
Earlier quoted context omitted.
People are advocating not saving settings to source control. F-that, I want to be able to clone my repo and run the project without scp-ing an additional file around. A file, that by all rights should be part of the project. Here's my solution - github 'extends' git somehow, so files can be marked private. Then, unless you have commit rights to that repo, you can't see the file's contents. So a public http checkouts…
That sounds like too much software to me. What's with the aversion to scp? You only have to do it once per box you set up... There's something to be said for having GitHub do everything 1000% for you, but there's also something to the unix philosophy that would suggest git is good at the version control thing, and scp is good for the configuration-file-moving thing.