secrets.yml, application.yml, and everything credentials/keys

[nbantatua]

From where we left off at 4d5b36b, can we settle for best practice approach for handling credentials/keys?

again, my pitch would be:

• Take every kind of credentials/keys as sensitive, hence, avoid hardcoding any, especially in environment config files & initializers
• Check in secrets.yml as part of the repo.
• Use application.yml as well, but do not include in repo
• All sensitive credentials set from application.yml are to be set from secrets.yml
• Use Rails.application.secrets in calling these credentials
• Refrain from using ENV
• Check-in secrets.yml.sample and application.yml.sample in repo to provide other devs the necessary key names for credentials(and/or even provide actual dev environment credentials/keys)

[rstacruz]

application.yml shouldn't exist unless you're using figaro, afaik.

checking in secrets.yml.example is redundant if you're checking in secrets.yml already.

also, all proudcloud projects i stumbled onto have .yml files checked in

[rstacruz]

also it was probably @victorsolis or @jasontorres who started the "check in secrets.yml" trend so i'll leave that to them haha.

[nbantatua]

I agree.

[victorsolis]

Wasn't me lol. But that should only be done for private repos.

[rstacruz]

commiting secrets.yml is okay for me.

it does seem fundamentally wrong. for private repositories, though, you might as well consider the entire code repository as a company secret, anyway. moving those secret credentials (api tokens) away into somewhere else (possibly less secure like evernote) can be simply thought of as an exercise in security through obscurity.

also it's very convenient not needing to update secrets.yml whenever it needs to change.

[nbantatua]

if that's the agreed case, we're good.